I spent my day today at OSCON 2012. I took the opportunity to attend talks on subjects that I don’t normally get to spent a lot of time with. The quality varied (I was shocked–shocked, I tell you–to learn that mining data out of arbitrarily-formatted HTML is “hard”). I spent a lovely lunch and parts of the afternoon chatting about various open source topics with my fellow attendees. One of my bigger take-aways from the chats is that the definition of “open” varies from person to person, project to project, and organization to organization.
Some one of the people I spoke with equate “open” with “transparent”. That is, “open” as in “open book”: let people see what you’re doing. Some take it a step further and extend “open” to mean “gather feedback and input from the community”. In both of these cases, the folks that I spoke with assumed that “their team” was doing all of the work and the notion of extending the team beyond the core group of people that their organization controlled (i.e. payed) was a bit of a foreign concept.
A few of the folks that I spoke with were more enlightened. By enlightened, I mean that their definition “open” more closely aligns with mine (me being the undisputed arbiter of such things and all).
If “open” means the same thing as “transparent”, then the term “open and transparent” is redundant (like “education and training”, but that’s a discussion for another time). “Transparent” means that you operate in full view: code, design, developer communication, etc. is equally accessible to all. “Open” means that you accept input from all. As in open to suggestion; open to involvement; open to change; etc. In this context, “input” means more than just allowing people to make bug reports, or suggest new features: it means giving up control. Input may come in the form of patches, or new bits of functionality. Input may come in the form of changes in design and architecture. Input may come from the addition of new developers who are not directly in your organization’s control to the project.
If you want your open source project to be successful, you’ve got to let other people play. If you want other people to play, you’ve got to give up any pretense of controlling everything.
