>> "But guess what: competition sucks. Cooperation is much better.
One of the biggest problems with competition is that it means
that somebody has to lose. For every winner, someone is a loser.
That person is going to be hurting. In the case of open source,
someone has spent (possibly) years of their life working on
something, and now, all of that is gone. That shit stings."
A thoughtful post by Steve, but I don't agree with this quote at all. It's misdirected to think that an idea is worth more just because someone has put a lot of time into it. It's also dangerous to assume that there must one way to do something and that it has to work for everyone.
Many others have said this before me, but it bears repeating: Open source is not a zero-sum game. New ideas and implementations do not come at the expense of existing code. The pieces don't get smaller; the whole pie gets larger.
I agree. Look at nginx vs apache - competition with nginx has done a lot to improve apache. Merb did more to improve Rails than anything else has. New projects with different design centers give you the flexibility to try out approaches that wouldn't be possible in the old project.
The thing that sucks is people taking sides and getting all bent out of shape over things. Even the people behind "competing" projects can cooperate in their work. Ruby MRI, JRuby, Rubinus, Maglev - all these supposedly competing projects created collaboration on RubySpec and other shared pieces of technology. When John Trupiano and I collided over Rack::Rewrite vs Refraction, we just talked on IRC and had a friendly chat about our different approaches and motivations, and how features in one project influenced the other. Nobody got mad or hated anyone over it. Even major political rivals can be close friends - look at James Carville and Mary Matalin (or don't, if you value your peace of mind).
Most "competing" projects are not friendly: marketing materials put out deride the alternative as "slow", "buggy", or what-have-you (some of the stuff put out about my project simply makes me want to quit it is so nasty).
Interesting, then, that, for whatever reason, I do /not/ see this kind of behavior with the various Ruby implementations: most people I deal with in that community actually seem to enjoy the various versions existing and work together. In this case, I wouldn't even call it "competition": I'd call it "cooperative experimentation".
But this argument breaks down when you look at the nginx vs. Apache example: proponents of nginx tend to just pummel Apache with pain, even when many of the claims aren't even true (which is extra stupid as I don't even think it is correct to believe that nginx and Apache are trying to solve the same problem).
What did Wayne say when you proposed to make these changes to RVM itself? It seems like if you wanted to make the pie bigger, and you just want ideas versus egos to rule then you could've proposed to improve RVM.
> you just want ideas versus egos to rule then you could've proposed to improve RVM.
One of the features I noticed from rbenv is that it does less than RVM. This is a good thing, but proposing this improvement to RVM would essentially be asking the maintainer to remove features.
People had similar complaints about Rails and now it's pretty modular and flexible with what you include/exclude. A proposal for RVM to be more modular with what it does to your shell would have probably been well received.
Certainly. Sometimes changes are just too major to bring back upstream and a new project is warranted. It just seems like Wayne was blind-sided by all of it.
Why assume he did? There's no law or even expectation that you can't create new projects. Not everyone is gifted at the diplomacy or negotiation required to work on existing projects. And, of course, many people want to have their "own" projects. There's nothing wrong with that at all. If everything was just an improvement of something old..
There's no law for many things in this world, but there certainly are expectations.
There are many projects with widespread use that have become core projects in the Ruby community (Rails, bundler, RVM, etc). It's reasonable to expect that issues or design decisions get discussed on the project mailing list before you try and divide the community.
It's at least no more divisive than to have Passenger vs Thin vs Unicorn vs Heroku vs WEBrick vs Pow for the serving end of things. Or RSpec vs Test::Unit vs MiniTest vs Shoulda vs Riot for testing. Good things have come out of all of these additions and they were not all fuelled by discussions.
In any case, to defend against claims like yours (which are common, it seems), it does seem wise for anyone wishing to create something new to post to existing mailing lists with their ideas. Once the maintainers say "No" to your idea to rip out 90% of their system, you can then create your new project and have the valuable mailing list link to say "Look, I tried."
Open-source software is about making software, not about staking claims to product areas and stroking egos. Linux Torvalds didn't ask for Andrew Tanenbaum's opinion before releasing Linux, and John Resig didn't send Sam Stephenson a pull request for Prototype before releasing JQuery.
The pie gets larger, but the use cases do get fragmented: if someone is really excited about some new feature or implementation mechanism, it is usually not the case that whatever "stalwart" project that is out there is unwilling to include it, and yet people assume this constantly and start a new project from scratch, or (a greater insult) fork the other project, to include that feature. Users and developer alike now have to choose, and that really does suck.
I would agree with Steve's statement if it were phrased as "cooperation over competition." Sometimes competing is just not avoidable, but that's alright.
Creating new things can be a great way to progress even without cooperation. Not everyone wants to or can successfully cooperate with existing projects, so if creating a new project is what gets them working and contributing to the world, that's still a win.
Naturally, working together on things can get bigger results in the long run, but the idea of creating new projects instead of merely patching up what we already have should never be dismissed or placed "below" cooperation.
One of the things posted in this article is a comment on GitHub's popularization of the concept of "fork": to me this was a mistake made by those developers, and they should have used the actual term from git, "clone" (which, in fact, Google Code does in their implementation of this same concept).
The thing that makes git great is not that it is easier to /fork/ other people's work: we don't think of all the different versions of Linux out there maintained by different people in the hierarchy (Andrew Morton, Alan Cox, etc.) as "forks", and no one considers them "competing".
But now, GitHub is teaching this new breed of open source developer that there is no difference between using a distributed version control system to collaborate on a project and forking someone else's efforts to compete with them: that really does suck. :(
A thoughtful post by Steve, but I don't agree with this quote at all. It's misdirected to think that an idea is worth more just because someone has put a lot of time into it. It's also dangerous to assume that there must one way to do something and that it has to work for everyone.
Many others have said this before me, but it bears repeating: Open source is not a zero-sum game. New ideas and implementations do not come at the expense of existing code. The pieces don't get smaller; the whole pie gets larger.