16 ms·

Ok, there's a lot to cover here. First off, the Apache Software Foundation isn't trying to absorb anyone or anything. Projects and people come to the ASF. It's

by jaaron 15y ago

Ok, there's a lot to cover here. 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. 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. Thirdly, about git and subversion. First off, there's increasing support for git at Apache (see http://git.apache.org/ http://git.apache.org/) 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. 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. 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.

visural 15y ago
While correct, it would benefit Apache in the long run to foster better communities and tools for their projects to grow. While they provide value in terms of the protection/process/management it's all for nothing if the developers can't collaborate effectively. GitHub has changed many developer's UX of opensource development to the point that they don't want to do it "the old way". Apache should be looking to grow in this direction to keep their developers and projects engaged.
- sliverstorm 15y ago
  Trouble is, their existing developers and projects seem to be doing fine with SVN. Don't forget those are the most important people, the workhorses you already have- not the flighty young birds you hope to one day trap. Sure, there is always the future to think about, but the future isn't happening a week from now. They have time to watch Git grow and wait until the time is right.
  - thomaslangston 15y ago
    There's no reason they can't do both at the same time. And the time to adopt GIT was 2008.
  - danssig 15y ago
    >Trouble is, their existing developers and projects seem to be doing fine with SVN. This statement has little meaning. If they were still on SCCS and had been using it for years I'm sure they would "do just fine" with it. But if they move to something modern they could do even better.
  - reissbaker 15y ago
    Except that the existing developers aren't all doing fine with SVN. As referenced in the post, both CouchDB and PhoneGap (existing "workhorse" Apache projects!) prefer to use git, but have met with strong opposition from the ASF. The time to allow for Git usage is already here. It's not just pie in the sky forecasting -- existing projects are being held back by bureaucracy.
mef 15y ago
what about Subversion goes "straight to the core" of the ASF that is not also true about git?
- deleted 15y ago
  [deleted]
- umarmung 15y ago
  Subversion is a centralised or push model. Git is a distributed or pull model. This is at the heart of the processes one may use, certainly within a project but possibly at cross-project or organisational model.
  - mef 15y ago
    what processes does the ASF use cross-project or cross-organizational which could not be replicated in a git environment?
buff-a 15y ago
There's no reason apache can't maintain its own "legally authorative" git repo. Nothing in the authors post suggest that he is confusing the ASF with a "coding sandbox". Making that claim suggests to me that you are invested in the alternative and not thinking objectively. And I disagree about subversion being "made for Apache in the way Linus made git for Linux". Subversion is an utterly derivative implementation of any server based VCS in existence, where as git is an example of truly creative thought (not just from Linus) about what VCS should be for a large community that requires the accountability that you claim ASF requires.
- tptacek 15y ago
  I'm not totally familiar with the issues here, but from an earlier perusal of the email threads on this, it seems like ASF's concern involves things like git's ability to edit the repository history.
  - buff-a 15y ago
    Oh, I can think of a million scary sounding consequences of using git and I'm sure that all were raised. This is what established groups do when confronted with change: raise any objection even though a moments thought demonstrates the paucity of its merits.
    - tptacek 15y ago
      That moment of thought was apparently too expensive for you; you didn't respond to the actual concern, but rather raised an argument suggesting that any argument about git must be meritless. I don't know who you expect to convince by baying at the moon. The ASF people are right in at least one sense: if you don't want to run projects in the ASF style, you are free to take your work elsewhere.
      - buff-a 15y ago
        I need not respond to the actual concern because the ASF has already done so. The ASF has already decided to allow git to be used. I assume that their lawyers OK'd this change. So I did not intend to continue an ongoing discussion: ASF has already concluded that discussion and approved git. Clearly, jaaron does not represent the views of all the "ASF People", and for him to raise issues as legal showstoppers when the lawyers have clearly approved is utterly disingenuous. The purpose of my post was not to discuss the merit of the git vs subversion argument, but instead to discuss the merits of jaarons criticism of mikeals article. One method that established groups resist change is to continue to bring back discussion to issues that have been decided. It helps slow discussion on change by making it appear that a previous issue was not, in fact, resolved. In their mind, of course, its not been resolved: the lawyers were wrong, or perhaps the lawyers didn't understand. Established groups don't just get over it and move on. Why would they? ASF has decided to allow Git. I believe that those projects which use git will enjoy more success than if they use subversion. Mikeal makes some interesting observations about this. Jaaron spouts the traditional establishment bullshit: 1. The other side are children. We are grown ups. 2. Legal implications. 3. Nobody is forcing you to participate. 4. Condescension. "It's impressive for what it is" ... (but "what it is" is "just a sandbox") I'm calling it for what it is.
chaseideas 15y ago
Strongly agree with jaaron's post. I also agree with some of the replies stating that the ASF should do as much as they can to foster contribution and a more active/social community. Perhaps they've just been a bit slow to adopt newer solutions because active contributors are content with the existing setup, and it's not seen as a huge benefit to change this just to be hip with the new crowds every quarter. Either way, it's nice to see Git catching on a bit, since it's one of the most common choices nowadays. As an organization, the ASF does an excellent job of overseeing crucial projects and the bureaucratic side of programming that comes along with developing services in the enterprise space. With such a large community and range of projects, a degree of bureaucracy is required to keep things running smoothly. They also do a good job of staying a mostly neutral party and working strongly towards the success of any project they "take in" under their wing. As jaaron noted, they don't actively solicit anything, or go around trying to absorb projects. They simply help maintain the projects that have grown up (and many people rely on). Being strong proponents of the open web, flexible software licenses, and doing a lot of the paperwork heavy-lifting in the internet and programming industry from a legalese standpoint, I think they do a lot more for the web as a whole than most people are aware. On the community note, I've run a few Apache community forums over the years, and it always seemed Apache users are starving for more community interaction and very appreciative of the social environment. Many of the Apache projects have a bit of a learning curve to be put into practical use, and people appreciate some guidance in learning the ropes. Maybe the ASF will notice and embrace a larger sense of community as time goes on, or perhaps some of us here on HN can connect and brainstorm something to fill the void. I think the title of this post was just hyperbole to catch peoples attention regarding a web server vulnerability or newly discovered bug. Haha, seemed to work pretty well. We're often caught up in the hype of new and catchy-sounding web technologies, but Apache is an organization that helped shape the modern web. Could they perhaps make the community more approachable to newbies? Sure. Are they harmful to the open source movement? I would think not. They bring a lot to the table. - Chase
blasdel 15y ago
The ASF isn't where projects go to "grow up". It's mostly where companies like IBM go to dump their enterprisey Java frameworks so they can be marketed as ostensibly open to outside developers.
- bergie 15y ago
  Nope, ASF actually provides and enforces a reasonable governance model for projects it adopts. I wrote something on why this is important: http://bergie.iki.fi/blog/open_source-free_software-what_we_need_is_open_projects/ http://bergie.iki.fi/blog/open_source-free_software-what_we_...
mapgrep 15y ago
There's actually not a lot to cover here? The question is why you're so scared of git and in six paragraphs you managed NOT to answer that question. This is really sad. One might hope an open source fondation would be forthright and fairly transparent. Apparently not.
- jaaron 15y ago
  Uh, I linked to the official git repos for Apache. Apache isn't afraid of git. Plenty of Apache people love git. At the same time there are issues with implementing and supporting it by the ASF infra team. If you want all those details, search those mailing lists.
cpeterso 15y ago
Ironically, http://git.apache.org http://git.apache.org is not responding.
- bergie 15y ago
  There is also a mirror on GitHub: https://github.com/apache https://github.com/apache
mikealrogers 15y ago
This is perhaps the most depressing response I've received to my article. As I said in my article this is far less about git and more about the chasm that has grown between Apache and the rest of the community. Your first two points boil down to "nobody makes you join Apache, if you don't like our policies then you can get out". How does this help Apache or its projects? Apache could still be valuable to the community but this kind of stubborn attitude will insure that it continues to become irrelevant when it could be a leader. I do understand the purpose of Apache and it is not hosting source code. That is the point I'm trying to make. If that is not its value, and its policies around hosting that source are no longer beneficial to its projects, then it should change its policy. I think that you, and many people in the ASF, have married the existing policies of Apache with the purposes for which they were created. While the intentions of the policies may still be relevant, and in my opinion correct, the policies themselves will not remain relevant forever in a field as rapidly evolving as technology and GitHub may just be the first example of Apache policy incompatibility with evolution of open source.
mcantelon 15y ago
>there are some serious drawbacks for use of git Such as?
- mtts 15y ago
  It's not centralized.
  - marshray 15y ago
    I've used centralized SCCSs for years and years. I guess I don't see why you can't use git as one, just have everybody agree to push to a central repository on a server. There is the issue of the size of the local copy, but it doesn't seem to be a big deal in practice. I just don't check in the heavyweight frameworks as vendor drops into the same repos as I use for my own, smaller, codebase. Granted, I'm scared to death of ending up in a merge-gone-wrong hell situation trying to do stuff that I'm very familiar with in Perforce. But I'm happy being a git newb taking baby steps a bit longer.
    - rimantas 15y ago
      There is no issue with the size of the local copy. Most of the times the entire git repo is smaller than single SVN checkout.
      - nirvdrum 15y ago
        I don't think I've ever seen a situation where that's true. And I've converted a lot of repositories (I maintain the svn2git project). SVN has its metafiles, but git has the full history locally. In all but the most trivially-sized projects, the git clone is bound to be larger. For larger projects it can be several orders of magnitude larger.
        rimantas 15y ago
        Git also has much more efficient storage mechanism.
tedsuo 15y ago
I would put up node.js as a counter-example. It is a large, important project successfully being managed on github. It's sponsor, Joyent, is a private company, but the role could easily be filled by a foundation like Apache.
neilk 15y ago
Hey, I work at the Wikimedia Foundation -- a non-profit -- and we're eagerly anticipating a switchover to git. I don't see what one thing has to do with another.
dscape 15y ago
[this text was written by mikeal originally here but somehow got censored. gist exactly as he wrote it https://gist.github.com/1387977 https://gist.github.com/1387977] This is perhaps the most depressing response I've received to my article. As I said in my article this is far less about git and more about the chasm that has grown between Apache and the rest of the community. Your first two points boil down to "nobody makes you join Apache, if you don't like our policies then you can get out". How does this help Apache or its projects? Apache could still be valuable to the community but this kind of stubborn attitude will insure that it continues to become irrelevant when it could be a leader. I do understand the purpose of Apache and it is not hosting source code. That is the point I'm trying to make. If that is not its value, and its policies around hosting that source are no longer beneficial to its projects, then it should change its policy. I think that you, and many people in the ASF, have married the existing policies of Apache with the purposes for which they were created. While the intentions of the policies may still be relevant, and in my opinion correct, the policies themselves will not remain relevant forever in a field as rapidly evolving as technology and GitHub may just be the first example of Apache policy incompatibility with evolution of open source.
- jaaron 15y ago
  "How does this help Apache or its projects?" The Apache Foundation is what you make of it. It will not change just because you post to your blog, but it will change if you engage the committer and membership population, build a consensus around your ideas and volunteer to do the actual work to make the changes happen. No one will force you to do such work and if you don't want to do it, then you're not obligated to do so. No one will be upset if you, I or anyone else leaves the Foundation. It's cool. We're all here at-will, volunteering effort and code. Apache cannot be everything to everyone, despite how much it is pulled to be so. Right now it fills a particular important role in the open source and larger software ecosystems. It's in that position due to both historical precedent as well as intentional decisions by the membership body. But trust me, no one in Apache is ever, ever completely satisfied with the Foundation. That's to be expected -- the organization is driven by the compromises of a large group of people with different ideas and expectations. To balance between the chaos of constant change and the death of no change, the organization has grown guidelines and rules from the collected wisdom of its membership. This gives us at least some framework by which to evolve. As for hosting code, there have been proposals at time for Apache to push the code hosting to some other organization. Once it was SourceForge, then Google Code, now Github. Of course, it's a tricky situation as the Foundation has particular requirements and wants to know its code will be around for decades. Moreover, infra team is constantly understaffed and thus are a very, very conservative bunch. We've seen way too many people jump in with a great idea and then leave maintenance to someone else. They're stubborn for a reason. And perhaps Apache and Github are incompatible. So what? Github is a tool. It's incompatible with lots and lots of organizations and ways of doing things. The FSF has its rules and culture. Same with the Linux kernel, distros and desktops like KDE and Gnome. Android is different too. Not all of those mesh with Github and that's fine.
kahawe 15y ago
Spot on, excellent points and I could not help but wonder about the article... most people would consider "apache" to be synonymous for the httpd and not the ASF, so the headline is clearly fishing. Then, OP argues ASF's processes are broken and a github project with one maintainer is so much easier... you really have to consider the scale of the average sourceforge (back in the day) project vs. apache even back then - and they have only grown from there, so no wonder a project hosted on github now is more "fun" to contribute to and work with because processes are probably pretty much non-existent and communication-paths and hierarchies are pretty much flat. The same goes for working at a small start-up vs. working at HugeFatCat Inc. But one thing I cannot stand: arguing git over subversion. Yes both are great revision control systems but they are just meant for different applications. Where I am working, I would take subversion over git any day if all I really want is an absolutely sure-fire way of having a simple and easy to use central repository. I am in the unfortunate position to having met and working with quite a few people (programmers non-the-less) who have a hard time coping with basic CVS/SVN update-commit cycles - with git and mercurial offering you the option to commit but to your local changes first before actually committing your changes to the repository you checked out from (or another repository or...), this would have literally created havoc and confusion for my small team here... I know them, yes it sounds ridiculous, but I know I have saved myself a hell of a lot of trouble and headache. SVN is an absolutely perfect tool for the job if you do not need the de-centralization, on-the-go-commits and all the possibilities of creating custom processes in git with all its flexibility and features and options. SVN works just fine for what it is. git and mercurial are not better,newer,shinier substitutes but different beasts altogether. (great, shiny, powerful and useful none-the-less) So could be please just let them peacefully co-exist and be thankful someone made them for us to make our lives easier?
- ma2rten 15y ago
  I am sorry to tell you, but you are plain wrong! Git is better. The problem is that SVN embraces a workflow that is inferior. But if you are not willing to change your workflow, git will seem confusing, indeed.
  - kahawe 15y ago

by jaaron 15y ago

visural 15y ago

While correct, it would benefit Apache in the long run to foster better communities and tools for their projects to grow. While they provide value in terms of the protection/process/management it's all for nothing if the developers can't collaborate effectively. GitHub has changed many developer's UX of opensource development to the point that they don't want to do it "the old way". Apache should be looking to grow in this direction to keep their developers and projects engaged.

sliverstorm 15y ago
Trouble is, their existing developers and projects seem to be doing fine with SVN. Don't forget those are the most important people, the workhorses you already have- not the flighty young birds you hope to one day trap. Sure, there is always the future to think about, but the future isn't happening a week from now. They have time to watch Git grow and wait until the time is right.
- thomaslangston 15y ago
  There's no reason they can't do both at the same time. And the time to adopt GIT was 2008.
- danssig 15y ago
  >Trouble is, their existing developers and projects seem to be doing fine with SVN. This statement has little meaning. If they were still on SCCS and had been using it for years I'm sure they would "do just fine" with it. But if they move to something modern they could do even better.
- reissbaker 15y ago
  Except that the existing developers aren't all doing fine with SVN. As referenced in the post, both CouchDB and PhoneGap (existing "workhorse" Apache projects!) prefer to use git, but have met with strong opposition from the ASF. The time to allow for Git usage is already here. It's not just pie in the sky forecasting -- existing projects are being held back by bureaucracy.

mef 15y ago

what about Subversion goes "straight to the core" of the ASF that is not also true about git?

deleted 15y ago
[deleted]
umarmung 15y ago
Subversion is a centralised or push model. Git is a distributed or pull model. This is at the heart of the processes one may use, certainly within a project but possibly at cross-project or organisational model.
- mef 15y ago
  what processes does the ASF use cross-project or cross-organizational which could not be replicated in a git environment?

buff-a 15y ago

There's no reason apache can't maintain its own "legally authorative" git repo. Nothing in the authors post suggest that he is confusing the ASF with a "coding sandbox". Making that claim suggests to me that you are invested in the alternative and not thinking objectively. And I disagree about subversion being "made for Apache in the way Linus made git for Linux". Subversion is an utterly derivative implementation of any server based VCS in existence, where as git is an example of truly creative thought (not just from Linus) about what VCS should be for a large community that requires the accountability that you claim ASF requires.

tptacek 15y ago
I'm not totally familiar with the issues here, but from an earlier perusal of the email threads on this, it seems like ASF's concern involves things like git's ability to edit the repository history.
- buff-a 15y ago
  Oh, I can think of a million scary sounding consequences of using git and I'm sure that all were raised. This is what established groups do when confronted with change: raise any objection even though a moments thought demonstrates the paucity of its merits.
  - tptacek 15y ago
    That moment of thought was apparently too expensive for you; you didn't respond to the actual concern, but rather raised an argument suggesting that any argument about git must be meritless. I don't know who you expect to convince by baying at the moon. The ASF people are right in at least one sense: if you don't want to run projects in the ASF style, you are free to take your work elsewhere.
    - buff-a 15y ago
      I need not respond to the actual concern because the ASF has already done so. The ASF has already decided to allow git to be used. I assume that their lawyers OK'd this change. So I did not intend to continue an ongoing discussion: ASF has already concluded that discussion and approved git. Clearly, jaaron does not represent the views of all the "ASF People", and for him to raise issues as legal showstoppers when the lawyers have clearly approved is utterly disingenuous. The purpose of my post was not to discuss the merit of the git vs subversion argument, but instead to discuss the merits of jaarons criticism of mikeals article. One method that established groups resist change is to continue to bring back discussion to issues that have been decided. It helps slow discussion on change by making it appear that a previous issue was not, in fact, resolved. In their mind, of course, its not been resolved: the lawyers were wrong, or perhaps the lawyers didn't understand. Established groups don't just get over it and move on. Why would they? ASF has decided to allow Git. I believe that those projects which use git will enjoy more success than if they use subversion. Mikeal makes some interesting observations about this. Jaaron spouts the traditional establishment bullshit: 1. The other side are children. We are grown ups. 2. Legal implications. 3. Nobody is forcing you to participate. 4. Condescension. "It's impressive for what it is" ... (but "what it is" is "just a sandbox") I'm calling it for what it is.

chaseideas 15y ago

Strongly agree with jaaron's post. I also agree with some of the replies stating that the ASF should do as much as they can to foster contribution and a more active/social community. Perhaps they've just been a bit slow to adopt newer solutions because active contributors are content with the existing setup, and it's not seen as a huge benefit to change this just to be hip with the new crowds every quarter. Either way, it's nice to see Git catching on a bit, since it's one of the most common choices nowadays. As an organization, the ASF does an excellent job of overseeing crucial projects and the bureaucratic side of programming that comes along with developing services in the enterprise space. With such a large community and range of projects, a degree of bureaucracy is required to keep things running smoothly. They also do a good job of staying a mostly neutral party and working strongly towards the success of any project they "take in" under their wing. As jaaron noted, they don't actively solicit anything, or go around trying to absorb projects. They simply help maintain the projects that have grown up (and many people rely on). Being strong proponents of the open web, flexible software licenses, and doing a lot of the paperwork heavy-lifting in the internet and programming industry from a legalese standpoint, I think they do a lot more for the web as a whole than most people are aware. On the community note, I've run a few Apache community forums over the years, and it always seemed Apache users are starving for more community interaction and very appreciative of the social environment. Many of the Apache projects have a bit of a learning curve to be put into practical use, and people appreciate some guidance in learning the ropes. Maybe the ASF will notice and embrace a larger sense of community as time goes on, or perhaps some of us here on HN can connect and brainstorm something to fill the void. I think the title of this post was just hyperbole to catch peoples attention regarding a web server vulnerability or newly discovered bug. Haha, seemed to work pretty well. We're often caught up in the hype of new and catchy-sounding web technologies, but Apache is an organization that helped shape the modern web. Could they perhaps make the community more approachable to newbies? Sure. Are they harmful to the open source movement? I would think not. They bring a lot to the table. - Chase

blasdel 15y ago

The ASF isn't where projects go to "grow up". It's mostly where companies like IBM go to dump their enterprisey Java frameworks so they can be marketed as ostensibly open to outside developers.

bergie 15y ago
Nope, ASF actually provides and enforces a reasonable governance model for projects it adopts. I wrote something on why this is important: http://bergie.iki.fi/blog/open_source-free_software-what_we_need_is_open_projects/ http://bergie.iki.fi/blog/open_source-free_software-what_we_...

mapgrep 15y ago

There's actually not a lot to cover here? The question is why you're so scared of git and in six paragraphs you managed NOT to answer that question. This is really sad. One might hope an open source fondation would be forthright and fairly transparent. Apparently not.

jaaron 15y ago
Uh, I linked to the official git repos for Apache. Apache isn't afraid of git. Plenty of Apache people love git. At the same time there are issues with implementing and supporting it by the ASF infra team. If you want all those details, search those mailing lists.

cpeterso 15y ago

Ironically, http://git.apache.org http://git.apache.org is not responding.

bergie 15y ago
There is also a mirror on GitHub: https://github.com/apache https://github.com/apache

mikealrogers 15y ago

This is perhaps the most depressing response I've received to my article. As I said in my article this is far less about git and more about the chasm that has grown between Apache and the rest of the community. Your first two points boil down to "nobody makes you join Apache, if you don't like our policies then you can get out". How does this help Apache or its projects? Apache could still be valuable to the community but this kind of stubborn attitude will insure that it continues to become irrelevant when it could be a leader. I do understand the purpose of Apache and it is not hosting source code. That is the point I'm trying to make. If that is not its value, and its policies around hosting that source are no longer beneficial to its projects, then it should change its policy. I think that you, and many people in the ASF, have married the existing policies of Apache with the purposes for which they were created. While the intentions of the policies may still be relevant, and in my opinion correct, the policies themselves will not remain relevant forever in a field as rapidly evolving as technology and GitHub may just be the first example of Apache policy incompatibility with evolution of open source.

mcantelon 15y ago

>there are some serious drawbacks for use of git Such as?

mtts 15y ago
It's not centralized.
- marshray 15y ago
  I've used centralized SCCSs for years and years. I guess I don't see why you can't use git as one, just have everybody agree to push to a central repository on a server. There is the issue of the size of the local copy, but it doesn't seem to be a big deal in practice. I just don't check in the heavyweight frameworks as vendor drops into the same repos as I use for my own, smaller, codebase. Granted, I'm scared to death of ending up in a merge-gone-wrong hell situation trying to do stuff that I'm very familiar with in Perforce. But I'm happy being a git newb taking baby steps a bit longer.
  - rimantas 15y ago
    There is no issue with the size of the local copy. Most of the times the entire git repo is smaller than single SVN checkout.
    - nirvdrum 15y ago
      I don't think I've ever seen a situation where that's true. And I've converted a lot of repositories (I maintain the svn2git project). SVN has its metafiles, but git has the full history locally. In all but the most trivially-sized projects, the git clone is bound to be larger. For larger projects it can be several orders of magnitude larger.
      - rimantas 15y ago
        Git also has much more efficient storage mechanism.

tedsuo 15y ago

I would put up node.js as a counter-example. It is a large, important project successfully being managed on github. It's sponsor, Joyent, is a private company, but the role could easily be filled by a foundation like Apache.

neilk 15y ago

Hey, I work at the Wikimedia Foundation -- a non-profit -- and we're eagerly anticipating a switchover to git. I don't see what one thing has to do with another.

dscape 15y ago

[this text was written by mikeal originally here but somehow got censored. gist exactly as he wrote it https://gist.github.com/1387977 https://gist.github.com/1387977] This is perhaps the most depressing response I've received to my article. As I said in my article this is far less about git and more about the chasm that has grown between Apache and the rest of the community. Your first two points boil down to "nobody makes you join Apache, if you don't like our policies then you can get out". How does this help Apache or its projects? Apache could still be valuable to the community but this kind of stubborn attitude will insure that it continues to become irrelevant when it could be a leader. I do understand the purpose of Apache and it is not hosting source code. That is the point I'm trying to make. If that is not its value, and its policies around hosting that source are no longer beneficial to its projects, then it should change its policy. I think that you, and many people in the ASF, have married the existing policies of Apache with the purposes for which they were created. While the intentions of the policies may still be relevant, and in my opinion correct, the policies themselves will not remain relevant forever in a field as rapidly evolving as technology and GitHub may just be the first example of Apache policy incompatibility with evolution of open source.

jaaron 15y ago
"How does this help Apache or its projects?" The Apache Foundation is what you make of it. It will not change just because you post to your blog, but it will change if you engage the committer and membership population, build a consensus around your ideas and volunteer to do the actual work to make the changes happen. No one will force you to do such work and if you don't want to do it, then you're not obligated to do so. No one will be upset if you, I or anyone else leaves the Foundation. It's cool. We're all here at-will, volunteering effort and code. Apache cannot be everything to everyone, despite how much it is pulled to be so. Right now it fills a particular important role in the open source and larger software ecosystems. It's in that position due to both historical precedent as well as intentional decisions by the membership body. But trust me, no one in Apache is ever, ever completely satisfied with the Foundation. That's to be expected -- the organization is driven by the compromises of a large group of people with different ideas and expectations. To balance between the chaos of constant change and the death of no change, the organization has grown guidelines and rules from the collected wisdom of its membership. This gives us at least some framework by which to evolve. As for hosting code, there have been proposals at time for Apache to push the code hosting to some other organization. Once it was SourceForge, then Google Code, now Github. Of course, it's a tricky situation as the Foundation has particular requirements and wants to know its code will be around for decades. Moreover, infra team is constantly understaffed and thus are a very, very conservative bunch. We've seen way too many people jump in with a great idea and then leave maintenance to someone else. They're stubborn for a reason. And perhaps Apache and Github are incompatible. So what? Github is a tool. It's incompatible with lots and lots of organizations and ways of doing things. The FSF has its rules and culture. Same with the Linux kernel, distros and desktops like KDE and Gnome. Android is different too. Not all of those mesh with Github and that's fine.

kahawe 15y ago

Spot on, excellent points and I could not help but wonder about the article... most people would consider "apache" to be synonymous for the httpd and not the ASF, so the headline is clearly fishing. Then, OP argues ASF's processes are broken and a github project with one maintainer is so much easier... you really have to consider the scale of the average sourceforge (back in the day) project vs. apache even back then - and they have only grown from there, so no wonder a project hosted on github now is more "fun" to contribute to and work with because processes are probably pretty much non-existent and communication-paths and hierarchies are pretty much flat. The same goes for working at a small start-up vs. working at HugeFatCat Inc. But one thing I cannot stand: arguing git over subversion. Yes both are great revision control systems but they are just meant for different applications. Where I am working, I would take subversion over git any day if all I really want is an absolutely sure-fire way of having a simple and easy to use central repository. I am in the unfortunate position to having met and working with quite a few people (programmers non-the-less) who have a hard time coping with basic CVS/SVN update-commit cycles - with git and mercurial offering you the option to commit but to your local changes first before actually committing your changes to the repository you checked out from (or another repository or...), this would have literally created havoc and confusion for my small team here... I know them, yes it sounds ridiculous, but I know I have saved myself a hell of a lot of trouble and headache. SVN is an absolutely perfect tool for the job if you do not need the de-centralization, on-the-go-commits and all the possibilities of creating custom processes in git with all its flexibility and features and options. SVN works just fine for what it is. git and mercurial are not better,newer,shinier substitutes but different beasts altogether. (great, shiny, powerful and useful none-the-less) So could be please just let them peacefully co-exist and be thankful someone made them for us to make our lives easier?

ma2rten 15y ago
I am sorry to tell you, but you are plain wrong! Git is better. The problem is that SVN embraces a workflow that is inferior. But if you are not willing to change your workflow, git will seem confusing, indeed.
- kahawe 15y ago