Earlier this week, I participated in a round table at the Software Development Best Practices Expo.
Surprisingly (to me anyway) it was the only section specifically talking about Open Source. In addition to Andy Oram from O’Reilly, who was the organizer/moderator, the other participants were:
- Leon Shiman (of Shiman Associates and X.org Foundation)
- Gregor Rothfuss (of Endoxon and the Apache Software Foundation)
- James Turner (of Kronos, BlackBear Software, and LinuxPlanet)
It was an interesting discussion ranging over a wide variety of topics around open source and software development.
I was too busy listening and talking (probably too much the latter and not enough of the former) to take good notes, but here are a few of the threads I walked away with.
Governance of Open Source use within the enterprise
James pointed out that one critical aspect is management of open source usage within enterprises. You can’t, in a company of any real size of complexity, just have each developer or application team using “whatever they feel like” – including different versions of libraries with conflicting dependencies, etc. Instead, you need some reasonable centralization and standardization to keep everyone more or less on the same page. That doesn’t mean, of course, setting and enforcing arbitrary standards, or putting up barriers to innovation, but it does require some control.
Why have so few developers have contributed to open source projects?
One of the attendees related how he has been asking developers during interviews whether they’ve ever contributed to an open source project, and being disappointed at how few – not one in fifty – had ever done so.
This lead to some good discussion about why that could be. For one, many companies don’t have explicit policies regarding open source, and some developers fear they might get into trouble for contributing to open source “on company time” or even with their corporate identity attached. More likely, in situations where the corporate culture doesn’t explicitly encourage open source contributions, developers simply don’t make time for it. After all, it’s hard enough to get done all the stuff you “have to” get done in a given day/week/month/quarter/year – contributing to open source may be just another task that falls off the bottom of the to-do list in the face of everyday life.
Folks also pointed out that these were developers working primarily with the Microsoft platform, who might be expected in general to be less open source friendly and savvy than Java and Unix based counterparts.
Finally, we also talked about how there is a wide variety of ways to be involved – documentation, testing, sponsorship, helping out people on mailing lists and in the community who need support, all the way up to committer status or project ownership and creation.
What do you do when a project you are working with heads in a direction with which you don’t agree?
A few people offered examples of projects they’d developed which later became open source. One individual in particular mentioned a project he had started and chartered for some time, but then allowed others to take the reigns of. He felt the project had “drifted” (my word, not his) away from its original focus on standards compliance, focusing instead on innovation and being “up to date.”
This lead to a good discussion about how projects vary in their level of control – open source doesn’t mean everyone has the same ability to change project direction and put code into the next official release of that project. Some projects keep very tight control over commit access, and enforce rigorous engineering discipline (code standards, testing standards, release management) where others are much more cavalier in their attitude and consensus driven.
Someone who choses to bring a project into the open source world can choose to retain control or can choose to “Set it free” and let it go in whatever direction the community chooses. The problem is, once you’ve set it free, you can’t put that genie back in the bottle. (You could create a fork of your own, or try to lead via persuasion the community back to a given direction – but if you’ve been out of the loop for a long time, that will be a hard sell).
Thanks again to Andy and all the participants and attendees.
