Hey all, I've been part of pulling this initiative together and thought I'd just put together some of our early thoughts.
The primary purpose is to get the open source program managers from companies together. It turns out there are a bunch of challenges for companies who want to run open source projects effectively, and we discovered we had only rarely even shared our own experiences of doing so - let alone figured out how to improve things.
A roadmap for the group's work is still to be defined... at this point you should consider this an invite to get involved. But we imagine some of the outputs might include things like:
- shared best practices for running large open source programs well
- certain criteria or qualities that 'good' projects should aspire to (responsiveness to community, maintenance, test-coverage, clear licensing, etc)
- tooling & instrumentation that makes it easier for companies to reach and maintain those standards
- a directory of projects from members that meet some or all of those criteria
I don't want to imply that we're committing to do all of these, but perhaps these non-normative examples give a bit more colour to the sort of things we'll tackle.
If you're at all interested, please sign up. We hope to have a face-to-face workshop very soon to kick off the work and understand what members want to prioritize.
If I'm understanding the intent correctly, it sounds like the home page could use something like this:
"Does your company release open source projects? Would you like to
improve how you interact with the open source community to better manage
and run your projects? Join your peers at //TODO and collaborate on
practices, tools, and other ways to run a successful and effective open
source program."
Agreed. "What it looks like to release open source projects, how to shift ownership of projects from companies to the community, and how to make sure that open source projects remaining healthy and active" has been discussed for almost 20 years. I'm willing to give them the benefit of the doubt that they have something to contribute here, but why not hold the announcement until they actually say what they're going to say?
For open source in general, we absolutely agree... but company-run projects aren't always as successful - and yet we feel they can be a valuable part of the overall open source landscape.
If my company doesn't have anything open sourced but I would like to see how others do it to help pitch the idea, would I be welcome to join as an individual? Or should I just wait for the group's output?
I added some comments about the impetus for launching TODO, and why we approached it by not being prescriptive out of the gate. The list of possible projects is long, and our first order of business is prioritizing them.
We'll be contacting the interested companies (over 200 now) about an in-person workshop and the other discussion platforms we're using.
I agree with boucher. I have read every page on http://todogroup.org/ (don't worry, there were only a handful). There is nothing concrete about "talk openly, develop openly" other than the list of inaugural companies ("Box, Dropbox, Facebook, GitHub, Google, Khan Academy, Square, Stripe, Twitter, and Walmart Labs" from the blog post, though only some of those are listed on the official website).
I suppose that this is neutral at worst. I had the fleeting, whimsical thought that Apple and Samsung ought to both join.
I feel similarly. I have a vague idea for what the group is about, but not really any idea as to what the group will do or what participating in the group would mean. More information's due.
Thanks for the comments everyone, hopefully I can answer some of the questions about what TODO is about and where it's headed, don't miss jamesgpearce's comments too.
One of the first principles when forming the group was that we wanted to collaborate with, and learn from, each other before developing prescriptive guidelines. The ten member companies that launched with TODO are just a fraction of companies that have open source programs; there are companies in wide ranging industries like finance, automotive, and retail that have already expressed interest in participating too. So instead of launching today with our version of the answers, we wanted to invite dialogue and particiaption.
Many of the participating and interested companies have already written extensive documentation and internal tools to solve some of the unique challenges of their open source programs. We want to take that experience, find the common patterns, and open it up to the broader community.
We believe that the best practices, tooling, and development principles that will come from the group will improve the overall quality of the projects; that these projects can be adopted by other companies with certain expectations.
If these are the same problems you face in your company's open source program, we'd love to hear from you and have you participate because you can help define the problems we tackle.
Okay I'm not sure this is well thought out, at least the sign on procedure is not. Here is a series of messages they present to the user:
1. It is for companies with dedicated resources for open source projects.
2. The person signing on has to mention the company he is with, so ideally a person from the "dedicated resource" or open source department of a prospective company?
3. They exist to discuss "how to shift ownership of projects from companies to the community".
So as a person of an open source department at their company, one is expected to join this to help their company render their department useless?
They should bake it better and present it to the right person.
First off, we can probably agree that not every corporate open source project is one that the community expresses an interest in. For those projects without community interest, this is moot.
For projects that the community does have an interest in, it can easily become unwieldy for a company to try and lead an open source project for a variety of reasons. I see it as beneficial to the company and the community for the community to gradually assume ownership of projects they are interested in.
Even if the community takes the project in a direction the company doesn't like, the company can always fork, or revert to an earlier version and continue. It seems like a win-win to me.
Certainly as someone in a company's open source program, we should talk :) I am too.
Sometimes even company projects reach a level of maturity at which they can feasibly graduate to community or foundational ownership.
At Facebook, both React and HHVM have a stated interest in pursuing this outcome for example - but I'm pretty sure this does not make my role redundant any more than a teacher becomes redundant once their oldest pupils leave school each year :)
I think things like this are a good way to get companies more aligned with contributing to open source, even aside from the mammoth technology companies already involved. I know that for many companies, the decision not to open source parts of their software isn't based on any idealogical disagreement with open source, but because their software projects haven't been designed with open sourcing as a goal, and if they can now take that into account when starting new projects, I'd expect that you might see a lot more open source software. So I think an organization that helps foster that can provide a lot of benefit.
And I'm not even a big open source zealot, but the number of companies who "get" the fact that participating in open source can be useful for lots of reasons (many better than "get the community to do work for free for us"), could certainly stand to be higher.
Comments
Hey all, I've been part of pulling this initiative together and thought I'd just put together some of our early thoughts.
The primary purpose is to get the open source program managers from companies together. It turns out there are a bunch of challenges for companies who want to run open source projects effectively, and we discovered we had only rarely even shared our own experiences of doing so - let alone figured out how to improve things.
A roadmap for the group's work is still to be defined... at this point you should consider this an invite to get involved. But we imagine some of the outputs might include things like:
- shared best practices for running large open source programs well
- certain criteria or qualities that 'good' projects should aspire to (responsiveness to community, maintenance, test-coverage, clear licensing, etc)
- tooling & instrumentation that makes it easier for companies to reach and maintain those standards
- a directory of projects from members that meet some or all of those criteria
I don't want to imply that we're committing to do all of these, but perhaps these non-normative examples give a bit more colour to the sort of things we'll tackle.
If you're at all interested, please sign up. We hope to have a face-to-face workshop very soon to kick off the work and understand what members want to prioritize.
If I'm understanding the intent correctly, it sounds like the home page could use something like this:
Yes. Maybe this is why we are not in marketing :)
PS: we're going to use this text. Thanks!
After reading this announcement, I have no clue what this is or why my company might want to join it.
Agreed. "What it looks like to release open source projects, how to shift ownership of projects from companies to the community, and how to make sure that open source projects remaining healthy and active" has been discussed for almost 20 years. I'm willing to give them the benefit of the doubt that they have something to contribute here, but why not hold the announcement until they actually say what they're going to say?
For open source in general, we absolutely agree... but company-run projects aren't always as successful - and yet we feel they can be a valuable part of the overall open source landscape.
[deleted]
Why not sign up[1] then wait and see? I didn't see any indication that they are trying to form some kind of exclusive club.
1. http://todogroup.org/#join
No, very much inclusive. We'll be getting back to all the companies interested in the very short term.
If my company doesn't have anything open sourced but I would like to see how others do it to help pitch the idea, would I be welcome to join as an individual? Or should I just wait for the group's output?
Ah. Thank you for pointing that out. I completely missed it. I will delete my comment.
Would love to see someone from Github answer this question. Very curious what //TODO is about, what it actually does, etc.
I added some comments about the impetus for launching TODO, and why we approached it by not being prescriptive out of the gate. The list of possible projects is long, and our first order of business is prioritizing them.
We'll be contacting the interested companies (over 200 now) about an in-person workshop and the other discussion platforms we're using.
Thanks!
I agree with boucher. I have read every page on http://todogroup.org/ (don't worry, there were only a handful). There is nothing concrete about "talk openly, develop openly" other than the list of inaugural companies ("Box, Dropbox, Facebook, GitHub, Google, Khan Academy, Square, Stripe, Twitter, and Walmart Labs" from the blog post, though only some of those are listed on the official website).
I suppose that this is neutral at worst. I had the fleeting, whimsical thought that Apple and Samsung ought to both join.
I shared a few more (personal) thoughts about what the group can achieve above in a neighbouring comment.
Came here to say this. Can't see any kind of mission statement other than there is a membership list and they committed to open source discussion.
I feel similarly. I have a vague idea for what the group is about, but not really any idea as to what the group will do or what participating in the group would mean. More information's due.
Thanks for the comments everyone, hopefully I can answer some of the questions about what TODO is about and where it's headed, don't miss jamesgpearce's comments too.
One of the first principles when forming the group was that we wanted to collaborate with, and learn from, each other before developing prescriptive guidelines. The ten member companies that launched with TODO are just a fraction of companies that have open source programs; there are companies in wide ranging industries like finance, automotive, and retail that have already expressed interest in participating too. So instead of launching today with our version of the answers, we wanted to invite dialogue and particiaption.
Many of the participating and interested companies have already written extensive documentation and internal tools to solve some of the unique challenges of their open source programs. We want to take that experience, find the common patterns, and open it up to the broader community.
We believe that the best practices, tooling, and development principles that will come from the group will improve the overall quality of the projects; that these projects can be adopted by other companies with certain expectations.
If these are the same problems you face in your company's open source program, we'd love to hear from you and have you participate because you can help define the problems we tackle.
At first I thought this was going to be a tool that highlights "//TODO:" comments in code for contributors to hack on in open-source projects.
At this point, that might be more useful than what it currently is...
I've been quietly hacking away at a tool like that if you are interested. https://github.com/rcaught/todos_export
Okay I'm not sure this is well thought out, at least the sign on procedure is not. Here is a series of messages they present to the user:
1. It is for companies with dedicated resources for open source projects.
2. The person signing on has to mention the company he is with, so ideally a person from the "dedicated resource" or open source department of a prospective company?
3. They exist to discuss "how to shift ownership of projects from companies to the community".
So as a person of an open source department at their company, one is expected to join this to help their company render their department useless?
They should bake it better and present it to the right person.
I kind of read that a bit differently.
First off, we can probably agree that not every corporate open source project is one that the community expresses an interest in. For those projects without community interest, this is moot.
For projects that the community does have an interest in, it can easily become unwieldy for a company to try and lead an open source project for a variety of reasons. I see it as beneficial to the company and the community for the community to gradually assume ownership of projects they are interested in.
Even if the community takes the project in a direction the company doesn't like, the company can always fork, or revert to an earlier version and continue. It seems like a win-win to me.
Certainly as someone in a company's open source program, we should talk :) I am too.
Sometimes even company projects reach a level of maturity at which they can feasibly graduate to community or foundational ownership.
At Facebook, both React and HHVM have a stated interest in pursuing this outcome for example - but I'm pretty sure this does not make my role redundant any more than a teacher becomes redundant once their oldest pupils leave school each year :)
James Pearce (Facebook Open Source Person commenting in here) gave a pretty interesting talk about Facebook's internal Open Source process at OSCon: http://www.youtube.com/watch?v=fzL6Zoy_ndk&list=UUP_lo1MFyx5...
I think things like this are a good way to get companies more aligned with contributing to open source, even aside from the mammoth technology companies already involved. I know that for many companies, the decision not to open source parts of their software isn't based on any idealogical disagreement with open source, but because their software projects haven't been designed with open sourcing as a goal, and if they can now take that into account when starting new projects, I'd expect that you might see a lot more open source software. So I think an organization that helps foster that can provide a lot of benefit.
And I'm not even a big open source zealot, but the number of companies who "get" the fact that participating in open source can be useful for lots of reasons (many better than "get the community to do work for free for us"), could certainly stand to be higher.
Interestingly fully-open companies like mozilla aren't in there
'talking' isn't really a problem that Open Source has. Funding on the other hand...
I'm surprised this came from Github considering there's nothing even remotely parsable anywhere.
Maybe it's my (legit) dyslexia, but I can't understand what the hell this is.
Secondly, Walmart labs?
I'm involved & left some thoughts in a neighbouring comment. Also: https://github.com/walmartlabs :)
Crazy! I had no idea they did stuff like that.