I recently attended the FJUG where Geertjan Wielenga presented on the NetBeans RCP. It struck me how committed he is to the NetBeans community. He’s been evangelizing NetBeans for the past 6 years, and the fact he came to speak at a JUG meeting reiterated his commitment.
At the same event, developers from corporates were railing against their corporate frameworks: How they were difficult to use, out of date and full of bad design decisions. Pretty bizarre.
Why the contrast in attitudes? I’d say the primary reason is the difference in the way corporate projects and open source projects are run, in particular, the transparency and community participation required by open source, and avoided by corporate development teams.
Corporate development teams tend to be isolated. This is especially pronounced with teams creating the framework for enterprise wide use. Add to this the fact that funding for framework projects tends to taper off after a time as no business unit will incur the cost of improving the framework and IT has to justify the spend with no immediate return. This leads to a skeleton crew struggling to keep up with framework maintenance, never mind improvements.
Open source has shown that bringing more people to focus on a problem is not only viable, but desirable. In The Cathedral and the Bazaar, Eric Raymond discusses the community driven Bazaar model of development:
That is, while coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities. The developer who uses only his or her own brain in a closed project is going to fall behind the developer who knows how to create an open, evolutionary context in which feedback exploring the design space, code contributions, bug-spotting, and other improvements come from hundreds (perhaps thousands) of people.
Why not take advantage of all the talent available to you in your company? And while people have their own project specific work to get through, there are sizable portions of downtime that could be put to better use.
But why would other developers in your company want to participate? I’d contend that solving issues they have with the framework combined with peer recognition, a chance to better their skills and a chance to be part of something great would be motivation enough. Damien Katz puts it well:
They do want to be a part of something great. They want to add their work and make it even better. They want to contribute to projects where the total excellence of the project reflects well on them and their efforts. They want to make the world a better place, and don’t want their efforts wasted.
So how do you move from the Bizarre to the Bazaar? Adopt open source elements in your corporate framework project. Change is hard, but the following could be implemented in corporates without too much kicking and screaming:
Make the code available throughout the organisation
Having the source code readily available to everyone in your organisation helps in a couple of ways. The framework team (and anyone else contributing code) should feel pressured to produce only quality code. No one wants to have their dodgy code exposed.
Having a set of high quality code should raise the bar for development in the organisation. Developers can learn from the code in the framework and take those lessons to their own projects.
Extend the family of committers
There will always be a core team of developers responsible for the framework. There’s no reason, however, to keep other developers from contributing. Other developers are just as capable as the core framework team and have the pleasure of using the framework day in and day out.
Not everyone should be given commit access, but anyone should be able to submit a patch for inclusion. If someone consistently delivers high quality submissions, consider giving her commit access.
Open up the documentation
Documentation is generally not something most developers want to spend hours doing. It’s most often slapped together at the end of a project by someone with too little time to do a great job.
In addition, the author writes from the perspective of someone intimately familiar with the project and this often leads to writing that leaves out important details or simply doesn’t cover the information users of the framework need.
So don’t hide your project documentation in a Word document. Put it on a Wiki and let anyone contribute. Over time there will be a more comprehensive and a higher quality source of information available.
Everyone submits bugs/features
Open up your bug/feature tracking software to everyone. Anybody should be able to log and browse defects. It may be scary for everyone to be able to see your defects, but the quicker they’re found the quicker they can be fixed. Plus, to help fix your defects developers will need to know they exist.
Allowing features to be requested allows you to keep track of what your users actually need. You do want to know, don’t you?
Create mailing lists
Create user and developer mailing lists for the project. This creates a repository of questions and answers that can serve the community long after the original discussion ends. It also ensures that users have direct access to the framework team. As a side benefit, it should help prevent the isolation of the framework team.
Wouldn’t it be cool if you could be proud of your company’s framework? Do you think the open source approach would help your organisation?