Two years ago Mikeal Rogers wrote a controversial piece called “Apache considered harmful” that touched a nerve for advocates of open source software foundations. Specifically, the piece argued that the ASF had outlived its usefulness, but in reality the post-GitHub nature of the criticism applied to a wide range of open source foundations.
For many years, open source foundations such as Apache counted project hosting as one of their core reasons for being. But in the majority of cases, the infrastrcture supporting this functionality was antiquated, as few of the foundations had embraced modern Distributed Version Control Systems such as Git. The Eclipse Foundation, for example, had a number of projects controlled by CVS, an application whose first release was in 1990. The ASF, meanwhile, was fully committed to its own Subversion project, a centralized VCS that was over a decade old at the time of Rogers’ post.
Outside the foundations, meanwhile, the traction of GitHub’s implementation of Git had exploded. It had become, almost overnight, the default for new project hosting. And because GitHub was in the business of hosting a version control system, and paid for it, it was no surprise that the quality of their hosting implementation was substantially better than what open source foundations like Apache or Eclipse could offer.
This preference for GitHub’s implementation led some developers, like Rogers, to question the need for foundations like Apache or Eclipse. In a world where GitHub was where the code lived and the largest population of developers was present, of what use were foundations?
One answer, in my view, was brand. Others included IP management, project governance, legal counsel, event planning, predictable release schedules and so on. But even assuming those services represent genuine value to developers, it would be difficult to adequately offset GitHub’s substantial advantages in interface and critical mass. GitHub makes a developer’s life easier now; intellectual property policies might or might not make their life easier at some point in the future.
As of this morning, however, developers at one foundation no longer need to choose. As the Eclipse Foundation’s FAQ covers, the Eclipse Foundation will now permit projects – just new ones, for the time being – to host their primary repository external to the foundations servers at GitHub.
The move is not without precedent; the OuterCurve (neé CodePlex) Foundation has permitted external hosting for several years. But the announcement by Eclipse is one of the first large mature foundations to explicitly fold external properties such as GitHub into its workflow.
This change should benefit everyone involved. Properties like GitHub gain code and developers, foundations can focus on areas they’re likely to add more value than project hosting, and developers get the benefits of a software foundation without having to sacrifice the tooling and community they prefer. For this reason, it seems probable that over time this will become standard practice, particularly as foundations look to stem criticism that they’re part of the problem rather than part of the solution. In the short term, however, there are likely to be some bumps in the road as new school populations within the foundations push their old school counterparts for change. Eclipse will in that respect be an interesting case study to watch.
Either way, while Eclipse may be the first large foundation to adapt itself to the post-GitHub environment, but it’s unlikely to be the last.
Disclosure: The Eclipse and OuterCurve Foundations are RedMonk clients.
