Log in

No account? Create an account

Previous Entry Share Next Entry
A Rest Stop on the OSS Turnpike
You know you are doing a poor job of explaining yourself when something that is so obvious that you take it for granted is a complete revelation to someone else.

Last week the CodePlex Foundation (CPF) sent "ambassadors" (me and President Sam Ramji) to ApacheCon to participate in one of open source's most significant annual events and to pay our respects to the Apache Software Foundation (ASF). 10 years is a great run, and the ASF has done some very impressive work during that time, work that has certainly inspired us in planning the CPF. Personally I give a lot of credit to Brian Behlendorf, who set the ASF on a unique path from the beginning.

In the early days of open source we all thought of flagship open source projects as succeeding in part because of the leadership of a single dominating individual. This tribal structure of a "benevolent dictator", or at most a "council of elders", seemed to be the norm, most clearly demonstrated in the case of Linux and Linus Torvalds. Unfortunately this model does not replicate well. If you have to have another Linus to have another Linux, then there isn't much you can do to facilitate that. You pretty much have to wait to get lucky. Now, I think there are characteristics of open source that make it easier to get lucky, but that's another topic.

Brian easily could have been the benevolent dictator of the Apache project. However, he wanted something different. He wanted a process and an approach to project governance that would liberate projects from their dependence on a single individual, something scalable, and repeatable, that could incorporate and adapt to changing best practices in open source software (OSS). Today we call this "the Apache Way". It is an end to end process for the software development lifecycle that any individual or company can adapt to. As we at the CPF try to figure out how to facilitate corporate participation in OSS, we've learned a lot from the Apache Way.

So why is it so hard for people to understand what the CPF is doing? Sam Ramji and I sat down with the folks from the ASF last week to talk about our mission and some of our specific approaches for fulfilling that mission. This led to their moment of revelation, and in turn mine.

At one point Greg Stein looked up and said -- you could almost see the lightbulb going off over his head, "So the CodePlex Foundation could be completely successful 5 or 10 years from now and have no intellectual property of its own?"

I thought about it. Now, I expect in 5 or 10 years the CPF will have some intellectual property assets, but it seemed perfectly obvious to me that that isn't a necessary condition for success. Why was it such a revelation to Greg? I think the answer comes down to this: we're in early stages, and have yet to have any projects affiliated with the CPF. We've only recently released our first draft of the project guidelines. So the legal documents we have posted so far talk primarily about how code can be contributed or licensed to the CPF. To the casual observer, that makes the CPF look like an intellectual property aggregator. And sadly, that's almost the complete opposite of what we're actually doing.

I start with an undeniable basic premise: Corporate software developers under-participate in open source projects.

What should we do about that? Jim Zemlin of the Linux Foundation has talked a lot, over the years, about the importance of paid development driving OSS, and increasing the number of OSS developers who are paid to work on OSS projects. At the CPF we are focused on the complimentary approach: getting more paid developers to do OSS development. So we are focused on a very different end of the problem. We are looking at companies where code by default is assumed to be proprietary, and it is assumed, by default, that the work of software developers automatically belongs to their employer. As companies recognize the need to increase participation in OSS, they recognize that they must change these default behaviors. The problem is they have no well-defined process for how to do so.

Some of the issues have to do with software development practices: how testing is done, how builds are managed, how dependencies are tracked, how bugs are tracked, how releases are scheduled, how security fixes are managed. All of this has to be adapted to new practices when a project becomes OSS. Some of it has to do with cultural practices. OSS developers simply have a different and more promiscuous notion about how to share ideas and drive innovation. A lot of it has to do with intellectual property: not just finding the right open source license, but finding the right contribution agreement to get software out the door and the right release agreement to enable developers to create software owned by someone other than their employer.

It can be a long turnpike from the point where a software idea is conceived inside a corporation until the point where it reaches its final destination as a released OSS project. Kudos to the ASF for trail-blazing this path and thinking about the whole problem end to end. But by their own admission, not every project is a fit for the ASF. They are a small, lean organization (frankly, so are we). Their core expertise is in the community and engineering side of OSS, and they do a great job of mentoring projects through the Apache Way. But they cannot, at the same time, have the expertise to accomodate a wide range of licenses or contribution agreements. They have one license, and one contribution agreement that projects must adhere to. We have an opportunity, at the CPF, to compliment the work of the ASF by focusing on the early stages of this journey and what it takes to get a project out from behind the corporate firewall. That means a more nuanced approach to contribution agreements, and contenancing a wider range of OSS licenses. But all of this is intended to make the CPF a pass through point. We are there to help corporations find the right home for their OSS projects and their OSS development work.

If we are successful, projecs may start at the CPF, but end up with the ASF, or some other organization. The key thing is to get projects out "in the wild" in the open source community, while doing so in a commercial-friendly manner. We are just a rest stop along the way, complimentary to, and additive with other OSS organizations. That's the real answer to Greg Stein's question, and that's how we aim to address the issue of under-participation.