Introducing //TODO for companies that are committed to open source
github.com
github.com
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.
"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."I suppose that this is neutral at worst. I had the fleeting, whimsical thought that Apple and Samsung ought to both join.
We'll be contacting the interested companies (over 200 now) about an in-person workshop and the other discussion platforms we're using.
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.
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.
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.
Maybe it's my (legit) dyslexia, but I can't understand what the hell this is.
Secondly, Walmart labs?