I’ve been involved with open source software projects since at least the 1990s. I even saved a Unix application from certain death that I still use today. But that doesn’t mean I’m all rosy-eyed about all open source software projects. They are not all created equal.
To be clear, there are “open source” projects that are neither all that open nor all that successful.
But let me parse my terms before you get all hot and bothered. “Open” can be as little as dropping the code out on a repository somewhere, which is the level at which many projects currently sit. Or, it could mean that the code is actively managed under an open governance model. Most fall somewhere in between, and a number die a quiet death from neglect. I’ve also seen projects that claim the open source label long before releasing any code. And, as we’ve seen with Kuali, there is no guarantee that open source software will remain that way.
Meanwhile, someone like Terry Reese, who has programmed and maintained the amazing MARCEdit application for many years, is criticized for not open sourcing his software. If he refused to also make it better and add capabilities then maybe there would be reason for concern. But it has been tirelessly maintained and improved. Managing an open source community is not easy. I can certainly understand why Terry may want to simplify his job by vastly reducing the number of variables involved.
All things being equal, open source is better than closed source. But things are rarely equal. And it doesn’t follow that software must be open source to be useful and valued. It also doesn’t mean that someone such as Terry may choose to open source the software when he no longer wishes to maintain it. So let’s stop beating up people and projects that wish to control their own code. There should be many options for software development, not just one.
Now go ahead and give me hell, people, because I know you want to.
Picture by J. Albert Bowden II, https://www.flickr.com/photos/jalbertbowdenii/, Creative Commons License CC BY 2.0.
About Roy Tennant
I’ll give you a choice of hells.
Level a) Scotch as far as the eye can see, all of it blends in plastic bottles.
Level b) Single malts surround you, but every tumbler is ever filled with ice (Sisyphus’s bar & grill).
90% of open source software is crud. Then again, 90% of everything is crud, which includes closed-source software.
Ceteris Paribus, being able to tell which is which before choosing is useful, as is being able to pick out the 10% of one system and use it on its own, or to remove unwanted bugs/ice from an otherwise satisfactory solution .
But as you say, Ceteris is never Paribus, and unless an open source project has a critical level of use and support, is complete and bug free, or you have resources to make any needed changes, proprietary solutions may win out. But be careful who you sup with, because once you are locked in, it can be hard to get out- but when you do, don’t look back.
Simon, As always you are far, far too erudite for me to craft any sort of response that reaches the level of your discourse. So allow me to simply say, “Hear, hear!” and raise a glass of Scotch to you that is properly, and barely, watered.
I might be chided for obsessing over semantics, or dismissed as a religious purist, but I do think one might be confused by reading your post as there seems to be some ambiguity between “open source software” as a resource developed by a community of practice, and “openness,” as an approach for managing that community.
“’Open’ can be as little as dropping the code out on a repository somewhere, which is the level at which many projects currently sit. Or, it could mean that the code is actively managed under an open governance model.”
Dropping code in a repository could be considered an act of “openness” but unless it carries an OSI Approved Open Source License, it is *not* open source software. The governance model associated with a project is independent from its licensing terms. One example I can provide is uPortal and Liferay Portal. Both are distributed with OSI approved licenses, but they have very different communities (governance, communication, direction, goals). One is governed by a community elected peers, the other is governed by a company board. One’s development is driven by community led interests (emergent), the other looks to capitalize on and build toward market trends. Please know there is no value judgement here and one could cite benefits to both approaches.
You are correct, there are many different modes for managing software and the communities that support them: benevolent dictators, meritocracies, the “Apache way,” “the open source way” etc. It is very important for people and organizations to not only understand what constitutes open source software (an OSI license), but also the community that supports (or doesn’t support) it. The latter will impact not only the success of the project (as you said), but more importantly, the value of the project for you and your organization. Even a successful open source project and community may not align with you or your organization’s goals.
Patrick, Thank you for your thoughtful, nuanced, and thought-provoking response.
Roy