Ok, there's a lot to cover here.<p>First off, the Apache Software Foundation isn't trying to absorb anyone or anything. Projects and people come to the ASF. It's a specific policy of the Foundation to NOT solicit projects. If someone says they're representing Apache and soliciting projects, they're wrong.<p>Secondly, Apache is very opinionated about how projects should be run. This comes from years of experience as not only a successful project, but as a successful non-profit organization overseeing dozens of projects. If a community doesn't like the ASF's style or rules (such as no dictators, benevolent or otherwise), they don't need to be there. No one wants to keep projects hostage. Part of the point of the Incubator is to get this figured out earlier than later.<p>Thirdly, about git and subversion. First off, there's increasing support for git at Apache (see <a href="http://git.apache.org/" rel="nofollow">http://git.apache.org/</a>) but there are some serious drawbacks for use of git. Consider this: subversion was practically made for Apache in the way Linus made git for Linux. With that in mind, subversion isn't going anywhere at the ASF. Some of the rational is just plain stubbornness, but some of it goes straight to the core values of the Foundation.<p>Apache has become, for better or worse, the place where lots of projects go when they grow up. Growing up is hard to do. It's not fun. You have to do things like get a job, pay taxes, etc. When a project grows up, people start caring about who contributed what, under which license and making sure every line of code is legit. A lot of engineers don't care about this, but businesses and their lawyers do. A lot of the Apache Foundation "bureaucracy" is to handle this oversight and paperwork.<p>Git is an impressive tool and github is awesome for what it is, but it's not a non-profit foundation and it won't replace one. Confusing the Apache Software Foundation for your coding sandbox only suggests you don't understand the true purpose of either.
The ASF is the first home that comes to mind when an successful open-source project needs independent stewardship. Often when a company wants to "spin off" an open source project, they turn to Apache.<p>What alternative organizations fill this need in a more lightweight fashion? Most other umbrella open source organizations I know of focus on copyleft and other issues that can be hostile to commercial interests.
Just to get two things out of the way: I'm an ASF member (albeit not very active lately) and a huge fan of git with or without GitHub. I'm one of the many people advocating for git internally at the ASF. I have been met with opposition in the past, but a lot of it has been around who's going to maintain the infrastructure, given it's a volunteer system. Let's just take it as axiomatic that the ASF is going to self-host its code. So it's at least a fairly pragmatic argument. And I think we finally have a solution.<p>My real issue is with the bouncing back-and-forth the author does in his post around the notion of IP. It's a shitty topic that most devs don't want to be bothered with, but alas, it's quite important in the real world. And GitHub is mostly a landmine field when it comes to this. I don't think it's a failing of GitHub itself, but most projects just don't have licenses attached to them. Unlike with SourceForge, there's no requirement to have an OSS license on public projects. Then many that do fail to meet the copyright header requirements for the license. Or you could have a public project with a restrictive license [1]. Being public doesn't mean you get to do whatever you want with the code. This is dangerous and bad for OSS.<p>Apache gives you that protection. There's never any question about it. That's the primary reason projects go through the incubator -- to make sure the IP is all in order. It's an annoying, bureaucratic, but necessary process in a litigious society. But because of the care and protections Apache provides in this regard, I think they've done more to get OSS adopted in traditionally closed companies than just about anyone else.<p>[1] I came across Tom Preston-Werner's repo for his site. He's one of the GitHub founders. It's a public repo with a license that restricts usage of certain portions of the project (generally his content): <a href="https://github.com/mojombo/mojombo.github.com" rel="nofollow">https://github.com/mojombo/mojombo.github.com</a>
Some good points, but github doesn't take the place of a community. When it's working well, it helps, but when there is a breakdown of collaboration and communication, you get one of those codebases that has been forked 1298 times where none of the people doing the forking is sharing anything. That's a community fail, not a version control system issue.<p>I do think that it'd be nice if the ASF offered git alongside svn, and concentrated on the community aspect of things, which it does tend to do fairly well.
I'm curious how does it harm anything? Did it kill any puppies? Maybe it's inefficient but harmful?<p>Also remember GitHub is a for profit company. Its allowance for Open Source hosting is a marketing tactic. Anytime they feel the marketing value is not there, they will shut it down. Not that I'm against GitHub. It's a great company for itself. But comparing the Apache to GitHub is like comparing apple and orange.
This essay put me in mind of The Cathedral and the Bazaar. It is a neat demonstration of how tools and processes are inextricably linked.<p>Who knew, though, that the ASF would be cast as the new priests in the cathedral? I suppose it took a whole new level of social development, enabled by tools, to cast them in that role.
So you're saying a system that has had repeated successes is harmful. I really think you make a good point here about the need to remain open to change. So talk about that. Obviously github has some very positive impact. How can Apache adapt to that? You're not really talking about the tools here, you're talking about community.<p>I see a potential solution here being that Apache has different rules for projects in different stages. Do you think that would solve the issues?<p>Remember, you're view of anarchy on GitHub will only last so long. Rules and order come out of anarchy for a reason and like all things GitHub will become the exact same stale community you're complaining of now in 10 years.
I'm curious as to the average age of committers by project under the ASF vs. popular projects on github. My hypothesis is that they would be older by a significant margin.
Hate to be the grammar cop here, but the consistent misspelling of "its" in the article is distracting. If the author is here, could you please fix that? It's taking away from a very well-written and insightful piece of writing.
I am not entirely sure what the article is trying to get at.
Politics and law in open source are real and needed, especially in the face of software patents.<p>Many contributors develop open source code as part of their paid work, as such it is quite important to establish the legal framework to allow contributing the companies IP to an open source project (which includes necessary patent grants). Comitters need to submit an Individual Contributor License Agreement stating that they have the legal right to contribute the code they're contributing. If worked on contributions as employee the company also typically needs to submit a corporate contributor license agreement.<p>Like it or not (and I personally do very much <i>not</i> like it), you cannot just upload some code somewhere these days.<p>As such the even FSF is an extremely important organization. Much frowned upon and usually not understood.
Open source licenses would not work without Copyright Law, most developers don't know or understand that.<p>And the whole thing of svn vs git. Personally I don't get it. I use svn when it makes sense and I use git when that makes sense, just like I use Java/Ruby/C++/Python/Javascript/Closure/Scala/whatever or GoogleDocs/PDF/OpenOffice/MS Word(yes) when needed.<p>The main feature I need from VCS are atomic commits. So CVS is out for me for that reason. Sure git's nice and all, but I spend 99.9% of my time writing or thinking about code and software architecture, not tinkering with my VCS, so as long as it works, I don't care.
Easy forking and branching is nice too. In the end, though, just as with Linux there is/are some de-facto master branch(es) somewhere from which "releases" are cut.<p>Currently with apache it's more convenient to use svn, so I do that.<p>I don't get the religious opposition against one version control system vs another.<p>Disclaimer: Apache committer here.
1) Apache Software Foundation and GitHub are two totally different things. Who cares about their internal preferences and bureaucracies. They're both producing outstanding open-source projects which are used by hundreds of thousands of companies and people.<p>Open-source (and the world) has only gained <i></i>positive<i></i> things out of these communities.<p>2) If you're suggesting that ASF needs to change its bureaucracy, I disagree. Frankly, I feel the bureaucracy has worked, given the success the foundation projects have had.<p>3) I'm not sure what other points your post brings, but if you're simply just saying that ASF needs to keep itself up-to-date with new tech (dunno git?) then this is also a totally absurd argument since the tech being used in Apache is totally amazing and new.<p>I feel like your outcry is referred to general institutions... you should probably refer to governments and other political entities instead of bashing on a foundation that has given the world amazing products.
<i>Some</i> people at the ASF think that Git may have <i>some</i> issues so are not wholeheartedly endorsing it for any and all projects.<p>Somehow this gets translated into "Apache considered harmful".<p>Why is this even on the front page?
Well written... I wrote a response last night that dives into some numbers and my experiences with helping the Eclipse Foundation move to Git and Gerrit... <a href="http://aniszczyk.org/2011/11/23/apache-and-politics-over-code/" rel="nofollow">http://aniszczyk.org/2011/11/23/apache-and-politics-over-cod...</a><p>Apache is pretty much the last major open source community to not move to some form of distributed version control. It's either politics (they host the Subversion project there) or negligence in my opinion.
Well written.<p>I wrote a similar article recently as well...<p><a href="http://lookfirst.com/2011/11/contributing-to-open-source.html" rel="nofollow">http://lookfirst.com/2011/11/contributing-to-open-source.htm...</a>
This might be slightly offtopic, but might be a symptom of the "institutional"/"organizational" issues addressed in the article:<p>I always thought Apache 2 and Subversion were two of the best examples of <i>second-system effect</i>. I mentioned this once to one of the core Apache (and Svn) developers years ago, and not only was he blissfully unaware of the effect, he indicated that he had helped build incredibly successful pieces of software (ie., Apache 1.x) and didn't need any advice from from Fred Brooks or anyone on how to do it.<p>Both Apache 2 and svn have been extremely successful projects, but both were late, didn't really match expectations or even the success of their predecessors, and are slowly being outcompeted by much smaller and usually more efficient projects (eg., nginx, lighttpd, git, hg) that are developed much more quickly by much smaller teams.
Free project infrastructure wasn't hard to setup five years ago. It hasn't really been a problem since 1999 when SourceForge opened. Before that, the SunSites did a nice job, and before that you basically had to know a friendly university sysadm (which wasn't _that_ hard to find).<p>I'm not sure what people think they gain by going under the Apache umbrella, but it must be something since they bother. There are no lack of alternatives.
I wish at least one open source replacement adopted .htaccess (and httpd.conf) compatibility.<p>Litespeed is the only product in existence which has made switching over from a complex Apache install a one hour affair, but it's free version is limited to 5 hosts and the commercial version can only be justified in a profitable environment.<p>The performance difference is breathtaking however.
..why isn't project x on git /rant<p>tl;dr<p>Github has a great social interface, it is a tool, there are others and there will be more.<p>Yes it is an evolution towards DVC + great social interfaces, older industry mammoths will be slower to adopt then newer more agile projects.<p>ps. I just switched from git to mercurial and it's a breath of fresh air.
As an aside, the Clay Shirky quote ("Institutions will try to preserve the problem to which they are the solution.") was new to me, but puts the RIAA/MPAA pretty much perfectly into perspective. Not really related to the article, but it clicked as I was reading.
Where to start with this blog post? It appears that the author has seen a couple of private emails and thinks he knows all about the internal workings of the Apache Foundation. He is wrong on so many counts.<p>His entire dislike of the Apache Foundation appears to be predicated on the fact that the organisation did not force every project to move to this blogger's favourite version control tool. Making a change as large as this requires many different things, but in particular:<p>1. Community change. How committers interact with each other when there are lots of forks is quite different to the current situation. That suits some projects and not others. Not every project at Apache will benefit. Some will. All who change will need to think long and hard about release processes, merging strategies and much more. Git encourages the idea that every commit or fork is completely equal to every other fork or commit. The Apache Foundation is built on the concept of meritocracy: commit rights are given in response to demonstrated skill. This is not an intractible problem with git, but new challenges need to be solved.<p>2. Legal change. Right now there is a simple process for signing off intellectual property for contributions which were merged from external contributors (who have not signed a release). That changes with git and becomes more complex. There are solutions, but they require careful planning.<p>3. Infrastructure. Hosting a large git repository with the level of downtime acceptable to Apache isn't something you do quickly. That needs planning and maintenance.<p>4. Toolsets. Lots of things in Apache are tied into subversion. From mailing list commit hooks to build servers and much more. Changing those things takes work.<p>5. Splitting the community. Right now the entire organisation's intellectual property is held in a single repository. Everyone knows where everything is to be found. Changing this simplicity requires a very good reason.<p>So what do we have now? A blogger who (it appears) doesn't actually contribute code to any Apache project. Telling other people how to run their organisation (which is wildly successful). And that they should change to this blogger's favourite new tool (they should have done it in 2008!) or face irrelevance.<p>If Apache moved every project to github tomorrow would that satisfy this blogger? More importantly, would that have caused this guy to commit high quality code toward one of the Apache projects? Or is he just blowing a lot of hot air about something he knows little?<p>And what brought on this great complaint? That the Apache Foundation is currently underway with trials for one project to see how git would succeed for their workflow. And to then evaluate its suitability for other projects across Apache.<p>Apache is not Github. That is, Apache is much more than a website, a couple of tools and a repository of code of random quality.<p>Disclaimer: I am an Apache member, but not speaking on behalf of Apache
Much of this is pretty unsurprising, especially for people like me who watched the attempted transition of OOo to Apache.<p>The way the article puts it is that the ASF is trying to solve problems that don't exist anymore, which is true to an extent, but the deeper problem is that the ASF has a particular view of how open source development and project management work, and attempts to impose that view on far too diverse a community, even as it tries to absorb more and more communities.<p>The ASF is simultaneously trying to be "big tent" and unified, and the balance is all out of whack. It's easy to draw parallels to recent political problems in the US and EU. In all three cases, there's going to have to be some transformations, probably in both society/community and structure, to come back to a place where the institution contributes to the greater good, instead of being a source of unending tension and meta-arguments.
I second this thoroughly. I was was almost driven to start blogging last week by ASF's poor job of maintaining its projects. There was a small bug in Solr. I was not the first to find this bug, and someone had not only reported the bug, but filed a patch on the bug tracker a year and a half ago. The patch was never merged in, nobody provided any feedback as to why the patch wasn't merged in.<p>One huge plus with Github is that if the official steward of a project would like to hand it off to someone else, or is failing to maintain it, it is trivial for someone else to take over the project.