In March of 2010, I sat on a panel with Justin Erenkrantz (Apache), Mårten Mickos (Eucalyptus), and Jason van Zyl (Maven/Sonatype) at the Eclipse Conference debating the future of open source [coverage]. The audience asked questions on licensing, development models and the direction of open source generally. One of the questions concerned the role of foundations like Eclipse, and whether they represented the future or if that would be written instead by commercial producers of open source.

My answer to that question was simple: neither. GitHub, instead, is the shape of things to come.

Mikeal Rogers came to a similar conclusion in Apache Considered Harmful. His arguments copncerning the importance of GitHub are compelling, as the evidence in favor of decentralized version control generally and Git/GitHub specifically is overwhelming. Quantitatively, virtually all of the metrics available to us reflect trajectories similar to those reflecting the relative popularity amongst Debian installations depicted above. As Chris Aniszczyk documents, legacy centralized tools reflect volume usage but Git’s massive growth has it poised to eclipse them. Git based services, meanwhile, are both profiting from and fueling said growth; an analysis of first half commit data for four major forges collected by Black Duck indicates that GitHub has in three years become the most popular open source repository.

Qualititatively, the benefits to decentralized development have been apparent to us since at least 2007. What GitHub calls “social coding” is the ability of decentralized version control tools like Git or Mercurial to inject collaborative development into a previously individual practice. The byproduct of which is the parellelization of development; like bacteria, GitHub developers may now evolve by swapping material directly to and from one another as required coverage. Which means, in turn, that forking is no longer a bad word but the way development should be done.

In the face of GitHub’s ascendance, the implications for open source foundations are unclear. In Apache Considered Harmful, Rogers’ argues that Apache specifically has essentially outlived its usefulness.

The problem here is less about git and more about the chasm between Apache and the new culture of open source. There is a growing community of young new open source developers that Apache continues to distance itself from and as the ASF plants itself firmly in this position the growing community drifts farther away.

But while I also subscribe to Clay Shirky’s maxim that “Institutions will try to preserve the problem to which they are the solution,” it is far from clear that it applies in this case. For disclosure purposes, I’ll note here that we count both GitHub and open source foundations like Apache and Eclipse as clients.

The argument that foundations have become vestigial in a post-GitHub world necessarily focuses on functional overlaps. Historically, project hosting has been one of the services offered by foundations. The data suggests that foundations who reject decentralized version control systems will fall behind, which is why structures like Eclipse are implementing Git. Even assuming a given foundation is able to transition from centralized to decentralized mechanisms, however, there is no guarantee that this will be sufficient. Iit’s unrealistic expect any foundation to compete with GitHub on functionality or community size, given the respective areas of focus.

The value of foundations, however, has never been principally hosting. They are, rather, the manifestation of a particular mission. The Free Software Foundation, the Apache Software Foundation, the Eclipse Foundation: all serve as the focal point for a group of developers. It is possible that their respective purposes have been fulfilled by GitHub, but the surging code repository seems likely to make foundations more relevant, rather than less.

As Rogers states:

Apache was founded about 12 years ago, a time when companies were still very afraid of open source and many people in the open source community were very afraid of companies. The world hasn’t changed that tremendously, big companies still use an open source stamp as a marketing tool, commonly referred to as “open washing”, and some in the enterprise are still wary about open source, particularly when it comes to certain kinds of licensing.

But, you would be hard pressed to find a single company that didn’t use some amount of open source software nowadays.

The obvious implication is that as acceptance of mainstream open source increases the importance and relevance of Apache’s mission decreases. I believe this to be incorrect. Aside from the many important non-infrastructure services offered by foundations – including IP management, project governance, legal counsel, event planning, and predictable release schedules – foundations have value as brands.

As the volume of open source assets grows, the paradox of choice presents itself to users. This problem in part already sustains a sizable marketplace of commercial products from vendors such as Black Duck, Open Logic, Palamida, and Sonatype. With GitHub and similar tools reducing the friction associated with development, we are likely to see selection problems get worse rather than better; as the volume of open source rises, fueled in part by GitHub’s success, so too does the difficulty of making a choice.

Which is one reason foundations are important. Much as McKinsey advantages Baker and Rhodes scholars in their hiring process, certain audiences will prefer to leverage open source software associated with a known brand such as Apache or Eclipse.

We have long argued that developers are the new kingmakers. As developers begin to make more choices within the enterprises they populate, they will inevitably face the same dilemma that their management predecessors did, which is the burden of choice. GitHub is a center of gravity with respect to development, but it is by design intensely non-prescriptive and inclusive, and thus home to projects of varying degrees of quality, maturity and seriousness. Consider the following:

GitHub, Inc. (“GitHub”) supports the protection of intellectual property and asks the users of the website GitHub.com to do the same. It is the policy of GitHub to respond to all notices of alleged copyright infringement.

Notice is specifically given that GitHub is not responsible for the content on other websites that any user may find or access when using GitHub.com.

GitHub, in other words, disavows responsibility for the projects hosted on the site. Foundations, conversely, explicitly assume it, hence their typically strict IP policies. These exclusive models offer a filter to volume inclusive models such as GitHub’s.

If your continued employment depends not just on the quality of the software you employ, then, but perceptions of the quality of the software you employ, the halo effect offered by foundations that actively triage their assets is likely to be of benefit. For better or for worse. If you’re choosing between one project of indeterminate pedigree hosted at GitHub and an equivalent maintained by a foundation like Apache, the brand is likely to be a feature. Managers used to say “you won’t get fired for buying IBM.” The developers making the decisions in the future may well have their own version: “you won’t get fired for using Apache.”

Rogers appears to have legitimate concerns concerning Apache’s acceptance of Git, and I concur that it’s a GitHub world and we’re all living in it. But I find it difficult to build the case that foundations more broadly won’t have a role to play in it.