One of my jobs at CollabNet has me consulting with enterprises that are planning to adopt Subversion either for specific projects or as a standard for the organization. These enterprises understand the value of Subversion for meeting their requirements for version control and software configuration management. They appreciate the work that the open source community has invested in this state-of-the-art tool and are excited to leverage that investment. What they often struggle with is their predisposition to use the tool as a "hammer" to enforce processes versus taking a cue from the Subversion developers themselves to improve their own processes. They are open to using an open source tool, but can’t see adopting some of the open source processes.
We all know that the software industry is still relatively young in comparison to other industries. It has matured quite rapidly, but many of us still remember the days when you had the master programmer who basically did all the work in isolation (including testing) and you just handed an occasional pizza through the doorway along with some appropriate high caffeine drink. After some period of time, you were handed a diskette or tape (before that punch cards) that had your desired application. Software was virtually all art and almost no science. We had few people that were good at coding and fewer still with any background to prepare them to code. We’re still finding our way between the two (art and science), but we certainly strike closer to a happy medium these days. We also have weeded most of the weak links out of the coding ranks. However, we have left the mechanisms in place that we used to limit the potential negative impact of those weak links.
Version control is one of the areas where we exerted control on the coders. We tightened our control over who put things into the repository, we added checks to validate what they wanted to put into the repository, and we protected them from themselves in many ways. Much of what we did came from the exceptional case of someone doing something well beyond what they should. It is like the person who charged off a new suit as a cost to the company because coffee got spilled on their old suit in a business meeting. As a result, a policy was put in place that not only prevented that abuse, but also made it difficult for people on long-term assignments to get their clothes cleaned. All of that control inside version control came at a cost. The exceptional case now meant everyone felt a performance penalty while a trigger or hook executed to make sure they weren’t violating the process. It made the individual less responsible and slowed down time to market. And for distributed development, it made it almost impossible for people to act on the exceptions to the rule since the person with that ability might be in another country and another time zone.
Open source has long been viewed as having limited development processes, but for those who really investigate it, quite the opposite is true. Much like the fact that agile development is potentially more structured than waterfall or even iterative development, open source development is very process oriented. The key difference is in the mechanisms used to drive that process. The Subversion community is not unique in how they develop software, but it should serve as an example of how commercial development might improve processes with the obvious goal of a monetary return on investment.
Subversion is developed with broad visibility to what is being done. That goes beyond the requirements and design behind the work to extend to the actual coding changes being committed. The posting of the deltas from each commit to a mailing list provides the opportunity for many eyes to review and comment on the work. Visibility is a main tenant of successful open source development and is a key contributor to the quality of vibrant projects. That visibility also is the key to the "enforcement" of the processes that the community defines. If someone fails to act in accordance with those processes, it is done in the open allowing the community to appropriately sanction the violator. Since the policy is in place for the benefit of the community, the violation negatively impacts the community and they react accordingly. Since version control exists as a type of "time machine", such violations are rectifiable (i.e.: changes can be rolled back, objects can be deleted, etc.). The impact is now limited to the offender and potentially someone who has to "fix" the violation (in most cases, the offenders themselves). Every action is not impacted in anticipation that someone might violate process, instead the violators are impacted and as a result, violations are actually made even rarer.
There’s a lot more that can be said on this topic but let me conclude this post by just asking you and your organization to consider not only using Subversion but also the process enforcement approach taken to its development. Don’t dismiss it as out of hand because it flies in the face of the traditional tool control approach. Instead, consider its merits and consider the fact that most of your processes are in place to prevent very exceptional events, not the norm. At the very least, most organizations can find great benefits in a balance between the two. So use Subversion, but take more than the code.