Is Software Configuration Management Technology Regressing?


Everyone Is Transitioning to Simpler SCM

I believe there are eight reasons SCM is reverting to version control through the use of Subversion and Git. But are these reasons really justified?

1. Price of commercial tools

The reality—or perception—is that commercial tools are always expensive. ClearCase, the dominant commercial solution just a few years ago, carried a price tag ranging from thousands to tens of thousands of dollars per user. IBM’s acquisition set the stage for costs holding fairly steady. And even though there are reasonably priced, highly capable commercial SCM tools, the perception is that the capabilities doesn't justify the added expense.

In addition, commercial SCM tools typically consume much customization effort, requiring consulting and training, although some of the new SCM and ALM tools have driven those costs down significantly through easy  out-of-the-box installation and simpler configuration procedures.

However, building processes around free version control tools will cost significant resources. And from a training perspective, the biggest cost is in lost salaries. As a result, a mature process and easy-to-use technology  are both needed to reduce training costs. These are somewhat lacking in open source solutions and in many commercial tools, too.

2. Benefits of open source tools

Open source tools are inexpensive to acquire and maintain. The source code is in the public domain, so there is no chance of the vendor going bankrupt, and with so many contributors and experts out there, the tools  should continue to receive support and enhancements.

However, it is difficult to make architectural changes to an open source product, as this is disruptive to the community and knowledge base. It also requires dedicated resources to see such changes through, which can  take a significantly long time to develop.

Speed of updates can also be a problem due to a gradual response to market demand. In contrast, commercial providers pride themselves on rapid customer response for new features and capabilities.

3. Integration of commercial offerings bundled on top of open source tools

In the commercial SCM and ALM market you’ll find commercial vendors selling Subversion and Git solutions. Version control is a very visible component of an ALM solution, and when a vendor bundles one of them into its solution, that appeals to a market that has already adopted one or the other. On the other hand, a free tool bundled in a commercial package results in the perception of the loss of the free benefit.

4. Startups without the experience of full configuration management capabilities

Developers don’t like administration, and if you put a group of unseasoned developers together, the last thing they want isto put some SCM administration in place. This is actually a selling feature for open source  solutions. There is no need to contact vendors or evaluate solutions—just download what everyone else is using. You can find the minimum feature set you need right now.

Experienced developers, on the other hand, recognize the benefits of full ALM solutions. They know it’s best to start out with all the capabilities at hand, especially if that solution increases developer productivity.

5. Marginal benefits of commercial offerings

Just as the cost of some commercial tools can establish the perception that commercial tools are expensive, the functionality of some tools can paint the perception that commercial tools are only marginally better than  open source counterparts. And in some cases, that’s true. So why pay?

In my experience, there are several commercial tools out there that will pay for themselves within a few short months and then continue to accrue benefits. It doesn’t take a lot of marginal benefit to cover the license  costs of a commercial tool.

User Comments

Frank Schophuizen's picture

Great artciel. I fully agree with you observations, especially that the benefits and the necessity of an ALM solution is not sufficiently explained and marketed. To many, ALM is considered a sales pitch to lure customers in buying more tools (or licenses, if you will) from the same vendor. That is what happened in the '90ies.

Moreover, software engineers from the 90ies are now the software development managers of today. So, their frustrations and allergies about "big" tools or "integrated" solutions is now guiding their decisions... Big means expensive, integrated means expensive and commercial vendors means arm-twisting and lock-in.

ALM is not a tool nor an integrated tool suite. It is an integrated solution of processes, practices, tools (not necessarily from the same vendor, and including open source where appropriate), organization and people (!) that collaborate and integrate seamlessly. SCM is out; it is too narrow-scoped and tempts customers to think in terms of tools and licenses, rather than efficiency and effectiveness of the organization.

May 15, 2014 - 1:59am
Brad Appleton's picture

Hi Joe!
I believe another reason for the apparent regression in SCM tool functionality is the influence of Agile/Lean development cultures that call for extreme simplification combined with a rebellion against having SCM tools "imposed" on developers via their organizations and so called "formal" SCM experts, and how such a tool selection+deployment strategy takes away control from developers both in the definition of their SCM process as well as its automation.

DevOps-related tools are even supplanting more traditional SCM toolchoices in this area, and many are redefining what SCM (or at least the perceived value of it to their development teams) in terms of automated+"continuous" build/integration/deployment capabilities.

From the dev/ops teams perspective, ditching these higher-tiered tools is a way of taking back control over their own processes and development models, and eliminating a lot of the perceived "overhead" of what they felt was being imposed on them unnecessarily, or in a way that was more of a burden to  them than a benefit. Once they rid themselves of those chains/shackles they were free to automate and integrate the needed pieces themselves the way they felt was most effective & efficient.

We witnessed the same thing happening with tools for doing "project-management". Not only were the methods and techniques being used no longer perceived to be "current" and "useful" but they were seen as imposing old ways of heavyweight processes that took control away from the developers. The more popular agile/lean/kanban-based methods not only support a different model, but they do so in a way that gives full control to the team and not just a project manager.

I think we're merely seeing the same thing happen with SCM, and that a lot of the more advanced capabilities were perceived to be implemented in a way that is more closely associated with process overhead and disempowering bureaucracy and a single controlling (configuration) manager rather than employing a simpler model with more distributed control/power among the rest of the team.

More and more developers and development teams are simply trying to take-back control over their own SCM processes and activities (for better and for worse) and are willing to take a step backward in functionality as long as they get to be in control of their own SCM destiny and  the corresponding way they envision seeing it automated. Eventually more vendors (and open-source offerings) will take notice of this and come up with offerings that have the missing functionality in a way that is a better fit for them.

May 19, 2014 - 2:54pm
Joe Farah's picture

Hi Brad,

Great observation.  Control is paramount in expanding and simplifying process.  And no doubt there are a number of tools that simply don't allow the flexibility needed by developers.  I'm sure we can both name a few.  But there are others where the customization capabilities are a key factor in providing control.  If I may reference our own tool, Neuma's CM+ is a prime example of a tool where both as a developer and as a CM manager, you have process and control capabilities that are likely well beyond what you might have by regressing to a simple VC tool and adding in functionality via the various scripting capabilities.

And I think it comes down to a few key capabilities that SCM/ALM tool simply need to support:

   1) Centralized database/repository that all phases and functions of the application life-cycle have access to.

   2) Data capabilities beyond SQL, which provide data revisioning, large objects, simple 1-many relationships, etc.

   3) Very high-level scripting capabilities (well beyond Ruby, Python, etc) which integrate data, process control, UI generation (dashboards, forms, etc.) and ALM functions without requiring a mountain of scripting code.

   4) Tiered control that customizations may be applied to an organization, project, group, role or individual users, along with the capability for any user to take advantage of the customization capabilities, and to share their advances with other users.

To be honest, I have not seen a lot of tools that are strong in the customization area.  Way back in the early '90s, Amplify Control (later Telelogic Synergy) showed a lot of promise.  But instead of improving the customization capabilities it had, it instead took a (perfectly good) approach of delivering pre-canned customizations.

The customization/process/data management space is not specific to CM.  But CM is a great place to grow this backbone technology so that we don't have to go back to the basic wheel to regain control.

So I think you have really hit the nail on the head in suggesting that developers want to regain control.  I just think there are better ways to do this than to go back to version control basics.

May 19, 2014 - 10:43pm

About the author

Upcoming Events

Oct 01
Oct 15
Nov 05
Nov 14