One of the unfortunate by-products of HP's decision to shift webOS to an open source project is the notion that somehow webOS has been "dumped"--cast aside or buried in the open source graveyard.
I was just wondering… when did it become okay to consider open source a dead-end option?
Not to go all Pollyanna on all these pundits, but I would think that the historical open source success rate would at the very least see open source as an equivalent alternative to proprietary development practices--not as some kind of downgrade. (If I were not holding back, I would even argue that open source development is a better goal for which to strive. But, for the purposes of this discussion, I will settle for equality.)
The problem is not entirely the fault of the analysts and media… the way some projects are treated when they are donated to open source communities does tend to enforce the graveyard notion. When HP donates webOS to open source (we still don't know how), are they really wanting webOS to succeed, or are they trying to spin off a failed project with the most positive spin possible?
For all the successes in open source and free software development, there are dozens of failed attempts which mark the end of life for software efforts. Commercial vendors who dump them--because that's exactly what they've done--don't follow up with community and development best practices and then shrug their shoulders when the project, absent leadership and support, sputters and dies.
This is not always the case. Sometimes a project will take on a life of its own, despite or because of the original donor's actions. LibreOffice is a good example of that… Sun Microsystems had too heavy of a hand in governing OpenOffice.org, and when Oracle demonstrated it would, too, a fed-up community went off and forked its own project, while OpenOffice.org was eventually donated to the Apache Software Foundation (ASF).
The perception that open source is the place where software goes to die has been continually perpetuated by the attitude software vendors and independent developers have towards open source: that if you make a project open source, then developers will just show up and take the project to whole new levels, like the shoemaker's elves who magically fix the cobbler's shoes every night.
That is a demonstrably false and lazy way of thinking.
The ASF, which has recently come under fire from the open source community for its centralized, some say dogmatic, approach to fostering software projects, knows this all too well. This is why the ASF sticks every new Apache project into incubator status, no matter how successful the project was prior to its inclusion: the ASF wants to see how strong the community and development processes are before putting too much energy and resources into the project.
Looked in this light, the governance and rules used by the ASF and similar organizations like the Free Software, Eclipse, and Outercurve Foundations make a whole lot more sense. These groups have different missions, but they all share the same constraints: they can't afford wasting time and money on every single project that's donated to them. They will help foster the project to a certain level, and then, like helping a child ride a bike, at some point they will let it go.
This is a good way to launch an open source project, and all too often this is not the way it is done. Too often, companies will use the label of "open source" to try to attract a developer community, but without offering any guidance or support. Or they'll go another way and only open source part of a project, holding some back for proprietary, commercial add ons. Or they'll over-govern the project, keeping all the true decision making power for themselves.
And then wonder why no one shows up.
There is a false meme in the FLOSS ethos, borrowed from the popular movie Field of Dreams: "if you build it, they will come." The problem is not that this meme can't be applied to FLOSS projects--it assuredly can.
The problem is what is meant by "build it." All too often, the perception is that the software project itself is the thing that is built. If we build it, developers and their managers will think, then people will come and help us code this when we put it out there.
Sometimes, rarely, this is true. But more often than not, this fails. What needs to be built is the infrastructure around the project that will help newcomers know what the project is, how it was put together, and under what rules will the community work?
Community is key here. Without community, open source projects do not thrive. Human beings are social creatures, and we value community very much.
For instance, I think it would be nice to live high on a mountaintop, enjoying the majestic views, the clean mountain air, the solitude… but I don't, because I also value community more than these things. I value infrastructure, schools for my kids, and good neighbors. These are my choices, of course, but it's a choice a lot of my fellow people have made too. After all, they're living in communities like mine right along with me.
This is the true thing that must be built when creating an open source project: the tools and the infrastructure that must go along with the code in order for it to thrive.
Open source is not a dumping ground, unless someone chooses to treat it as such. If it is not treated as a garden that must be tended, don't be surprised when it does seem like a graveyard.
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.