About a month ago, I provided a post in this blog that suggested that enterprises consider taking some of the processes that are used to produce Subversion (as an example of good open source processes): In addition to the code. That stirred some interesting discussions, more offline than online, so I wanted to revisit this topic.
I find it disappointing, if not surprising, that enterprises are so reticent to consider the less restrictive, but still process-driven configuration management procedures that the Subversion project utilizes. I get a lot of initial backlash when I talk about open source processes. The reality is the backlash is not really coming from knowledge, but uninformed impressions. It is almost funny to think of organizations, who depend upon open source technology (e.g., Apache, Linux, Subversion, etc.), rejecting the processes that produced it without true consideration. That’s like saying "I love my house and find it to be of high quality, but I wouldn’t consider building another one the same way." What happened to good old plagiarism of successful ideas and processes?
For example, visibility seems an obvious approach to better quality that should be enabled by our processes. First, one is going to be more cautious in their work knowing that it can potentially be seen by the broader project team. It is a strong deterrent to shortcutting the coding standards that the project (or the enterprise) has identified. Second, the code benefits by having more eyes reviewing the changes, which means a higher probability of issues being identified earlier in the lifecycle at a lower cost to their enterprise. I realize some people are reticent to having their work "exposed", but that shouldn’t be an inhibitor to doing the right thing. Most of the people that you really want doing the work will welcome the chance to share their "brilliance" at a more detailed level. This visibility is achieved to some extent by general read access, but also by posting deltas to a mailing list and its associated archive. Visibility can also be enhanced through an association of the delta with a change request
If visibility is achieved, then it is logical to consider what the impact would be to other processes. Who would consistently violate accepted processes if they knew the team saw those violations and knew the team is impacted by those violations? How would the broader team react to these violations? Aren’t people hired with the expectation that they will do the right thing for the enterprise and as an extension of that, for the project team?
Contrast that to implementing a hook that impacts everyone’s productivity and, while forcing adherence, can be consistently required for some users versus correcting their behavior. Each user pays a price with every operation just in case they "might" be violating a process. Of course, since we’re talking version control (aka a time machine) the changes can be rolled back if a violation occurs. And consider the fact that this won’t be isolated to one type of violation, but will be repeated for many different types which will build on the impact to each individual.
I think enterprises need to become more open minded and consider the benefits to the approach the Subversion project takes versus the process enforcement that most lean towards today. Since you’ve built your house on Subversion (Apache, Linux, etc.), it seems reasonable to look to build other houses in the same way.