Open source is done. Welcome to open development
January 31, 2013 —
(Page 1 of 3)
Related Search Term(s): open source
If you're looking at embracing open source today, you might be a bit late to the game. Using open-source software is mainstream now, and being involved in open-source projects is nothing to write home about either. Everybody does it, we know how it works, its value is proven.
But what's next? Sharing source code openly is a given in open-source projects, but in the end it's only about sharing lines of text. The real long-term power of successful open-source projects lies in how their communities operate, and that's where open development comes in.
Shared communications channels. Meritocracy. Commit early, commit often. Back your work by issues in a shared tracker. Archive all discussions, decisions and issues about your project, and make that searchable. All simple principles that, when combined, make a huge difference to the efficiency of our corporate projects.
But, of course, the chaotic meritocracies of open-source projects won't work for corporate teams, right? Such teams require a chain of command with strictly defined roles. Corporate meritocracy? You must be kidding.
I'm not kidding, actually: Open development works very well in corporate settings, and from my experience in both very small and fairly large organizations, much better than old-fashioned top-to-bottom chains of command and information segregation principles. Empower your engineers, trust them, make everything transparent so that mistakes can be caught early, and make sure the project's flow of information is continuous and archived. Big rewards are just around the corner—if you dive in, that is.
What's open development?
Open development starts by using shared digital channels to communicate between project members, as opposed to one-to-one e-mails and meetings. If your team's e-mail clients are their knowledge base, that will go away with them when they leave, and it's impossible for new project members to acquire that knowledge easily.
A centralized channel, like a mailing list, allows team members to be aware of everything that's going on. A busy mailing list requires discipline, but the rewards are huge in terms of spreading knowledge around, avoiding duplicate work and providing a way for newcomers to get a feel for the project by reviewing the discussion archives. At the Apache Software Foundation, we even declare that "If it didn't happen on the dev list, it didn't happen," which is a way of saying that whatever is worth saying must be made available to all team members. No more discrepancies in what information team members get; it's all in there.