Good afternoon, Sports Racers! When you see people making claims about what open source is and who’s really doing open source, you know to get on guard, right? E.g.:
[BEA’s CEO Alfred] Chuang appeared to rule out open sourcing BEA’s Java middleware, saying business customers do not want to hack around with the application server’s code. Picking on Sun’s OpenSolaris program Chuang said: “Look at those who blindly open source. Solaris – two million lines of code. Useless.”
Chuang went on to criticize JBoss. Marc Fleury, JBoss’ chief executive, has prided himself on paying a hard core of developers to maintain the application server and keep development alive. Fleury, speaking at JavaOne last week, re-iterated the point: “We’ve been a big proponent of professional open source and rejected the myth that with peace and love open source falls from the sky,” Fleury said. It’s a view shared by Oracle chief executive Larry Ellison.
According to Chuang: “JBoss is open source software for selected people who are approved [and] can participate. [Participation is] selected by Marc Fleury. That’s not an open source process. An open source process is an open community process. You’ve got to have an open source process and open source community.”
In the past few months, I’ve sat through several debates about who’s more open source-y. It’s not always the closed source vendors who get into it either.
To me, the notion that there’s a solid definition of what it means to be open source is anathema to open source. As with Agile, there are guidelines, in my mind, primarily:
- You can download the code for free.
- You can build and run the code for free, but there can be (commercially deadly) string attached.
- You can modify the code for free, and run the results, but there can be (commercially deadly) strings attached.
- You can email patches and fixes to the committers who can commit them or skip them.
The Midnight Coder What Codes At Midnight!
What’s not in that list is “you can commit code to the project,” and that’s exactly what Chuang and others who get embroiled in OSS briar patches end up talking about all the time.
People either worry that The Midnight Coder will commit illegal or bad code to the project when no one’s looking or that actual control of the project rests in the hands of a few elitists who exclude just anyone from committing code.
Those, of course, are issues with all software, closed or not. In fact, they occur more often in closed source software than open source.
The realities with all software development are:
- Not everyone will be able to commit, esp. if the people in control don’t like you.
- When everything is in the clear, The Midnight Coder can’t survive.
Open source or not, what matters with software are:
- the features
- how well those features work
- if you, the end-user needs it, that the software will be updated and supported
- a reasonable price for the above
As long as you’re cool with those parameters, whether something is open source or not is irrelevant to you, the end user. Of course, the next step for OSS nuts like me is to turn from the end-users to the vendors and say, “since they don’t care, you should open source it, because it will make your life easier.”
Sandals and Rainbows
The catch with that sentiment is that if you’re a closed source vendor, and you’ve been charging too high of fee to copy the software (the cost of a license), then once you open source, it’s time to up your support and maintenance fees, but only if that pricing reflects the true value of your software. As you might suspect, there’s a high chance that many closed-source vendors are currently charging way too high of a copying fee. Those are the people who should fear open source the most, because re-couping that revenue means having to innovate new software to sell or, more likely, cutting fat.
Loosing revenue you’ve been unjustifiably getting is tough love: it sucks in the short term, but it benefits everyone in the long term. Copy-based pricing for software is ultimately a distraction from the real value in software that end-users should pay for: the relationship with the software providers.
What can an end-user do with that relationship? They can:
- Get help figuring out how to use the software.
- Get help making the software work and customizing how it work.
- Get help making the software work with their other software.
- Demand changes in the software, that is, dictate requirements.
- Ensure that the software will continue to be developed and not become a mystery box that no one wants to touch for fear of breaking it.
Again, these are all things that you expect in closed source software, the only difference is the pricing: in close sourced, you pay the vendor to make you a copy, in open source, you pay for what you’re really getting, a friendly relationship with the vendor*.
And that’s the part that isn’t all sandals and rainbows: in a commercial, open source world “pricing” is how much you pay for friends. If you can find free friends, hey, you go, girl! But if you can’t, don’t be shocked when it turns out that “open source” != “free.”
More importantly, don’t get all caught with people debating who’s more open source than who. When you’re deciding what software to use (start a relationship with), open source machismo is irrelevant. As we discussed above, being open source or closed source doesn’t matter so much as the nature of the relationship you have the software provider and if you’re comfortable with how much you’re paying for that relationship. At that point, open source is a feature rather than a funky debate topic to freak out about.
*: this line of thought stresses me out when it comes to “small” desktop applications. The thinking works for business and enterprise software, but for apps that I just download and run without ever needing to get support, I wonder…
Disclaimer: BEA is a client.
Technorati Tags: bea, opensource, pricing, software
Nice post.
This has always baffled me and is a good indicator that the person making such a statement has little experience with how most F/OSS projects work. I can’t think of a single project that has–or has had at any time–open commit access. There’s a pretty standard vetting process for potential new contributors that goes like this:
Lurk on mailing list
Participate on mailing list
Send patches to mailing list / tracker
Do #2 and #3 for quite some time
Commit access
#5 only happens when your patches are going through pretty much untouched and when applying them is taking up too much of the maintainers’ time. There’s many cases when commit access doesn’t make sense, even when your patches are always good (e.g. when the frequency of patches is low).
Every successful project I’ve been involved with includes one or more “elitist” maintainers – you need committers with a high level of intolerance for shitty code that don’t have a problem with rejecting patches. The best policy for maintainers seems to be in assuming you are going to throw a patch out before seeing it – every new piece of functionality is unnessary until proven required.
This general mentality is refered to as “keeping the crack out” by Seth Vidal (Yum, Fedora, Duke/Linux) and I think it’s one of the most important and least talked about aspects of F/OSS project maintainership. Keeping the crack out is not fun for maintainers – it’s not creative, artistic, or intellectually stimulating elsewise. People get pissed at you and throw around words like “elitist” to rationalize the rejection of their patch.
I refuse to work on projects that don’t have at least one guy who has demonstrated the ability to 1.) recognize crack and 2.) keep it out. No developer wants to contribute to a project that’s going to bloat into uselessness because the maintainer is incapable of rejecting functionality that’s not generally applicable (i.e. 80/20) to the community. I’d say this is especially true in commercially organized F/OSS projects where you run the risk of Gartner magic quadrants dictating project direction.
Notable crack-keeper-outers I’ve had the pleasure of observing and who should be lauded for their excellence in crack-keeper-outing: Guido Van Rossum (Python), Linus Torvalds (Linux Kernel), Seth Vidal (Yum/Fedora Extras), David Heinemeier Hansson (Rails), Havoc Pennington (GNOME/Metacity). It’s funny that you never hear about this aspect of maintainership even though it seems to be something that all great maintainers share.
So yea, I don’t buy the “elitist” argument for a second. It doesn’t make sense unless your goal in contributing to a F/OSS project is PR. No established/successful F/OSS project is going to reject contributions from someone based purely on commercial politics – and if they do it’s more likely that it’s because the contribution is crack.
Spoon!
From http://www.opensource.org:
(Yes, there is “Open Source” and “open source”, but since OSI coined the phrase, their definition deserves consideration.)
Your list has “read” and “modify”, but not “redistribute”. In my mind, that one is too important to omit: The leaders of a project (i.e. committers) may decline to accept my patches, but if they do, I have the option to distribute those patches myself, or even fork the project to include my patches.
This forms an important safety mechanism that keeps open source projects democratic, despite the exclusive nature of the committers in most projects: If the project leaders fail to satisfy the needs of the user community, that community can, as a last resort, fire the leaders by forking the project. This goes some way to ensure that “if you, the end-user needs it, that the software will be updated and supported”. Historical examples: emacs/xemacs, gcc/egcs, xfree86/xorg, the various BSDs.
Are there any examples of projects which are generally accepted to be open source, yet do not include the right to redistribute?
Ryan: your keeping the crack out point is lovely. Developing quality software definitely doesn’t co-exist well with commune notions of “everyone can write good code!”
Klobe: “And so he says, ‘I don’t like the cut of your jib.’ And I go I says, IT’S THE ONLY JIB I GOT, BABY!”
David: you’re absolutely right, the ability to redistribute the code is key. I’d just assumed that it was so strongly implied that I didn’t even consciously think of it. But, yes, if you can’t redistribute the code then something is fishy. Thanks for the clarifications ;>