- licenses expire if not renewed? Is so, is the vendor willing to collapse existing licenses and apply the pro-rated return to extending the needed licenses that remain. Irrespective to the answer to the last question, how long do you have to find alternatives and migrate the repositories to them?
- If the current licenses do not expire, but support and upgrades do, pull all of the upgrades as they become available even if you do not have time to apply them. Then you can continue using the tools until they they no longer work within the existing environment (such as being tied to specific systems, requiring specific operating systems levels, etc.). At some point in the future, assuming the organization survives, it will still be necessary to either restore support or change to some other tools and form a new tool chain.
- Are there conditions where license restrictions, such as moving to another server, able to be relaxed by the vendor, even if support has officially expired? If so, try to get written commitment from the vendor now while there is still the luxury of time.
Administration and Support
One of costs associated with all tool chains is the overhead involved in using, administrating and maintaining them. There is also the consideration of how much custom infrastructure has been built around the tools themselves. This, too, forms a part of the tool chain.
On large teams there is a need for extra overhead and extra control in order to maintain communication – especially to allow knowledge to be transferred to the future. This is because the normal turnover rate in large teams may be the same as for small teams, the absolute numbers is larger and information must be organized so that it can survive this. This means that as a team size decreases, this additional overhead will cease to serve a valid purpose (one of the reasons agile teams can be so... agile). This also means that it may be necessary to relax some of the controls and/or dismantle some of this infrastructure to keep the development effort productive.
Converting Tool Chains
There are two ways a tool chain can be converted, one is to use new tools and the other is to change the infrastructure that configures and integrates the tools. In this case, the primary reasons to change the core tools themselves are to save support and license costs, or to save on the time spent administrating them. Regardless, the most likely end result is the same – a transition to FOSS tools.
There are several good articles in past editions of CM Journal on how to select new tools, but in most cases it boils down to finding ones that will meet the actual requirements and this case they also include minimal setup, conversion, administration and integration costs. At this point everyone is generally asking for specifics, so for once I am going to break with tradition and give some. There are many others available than what I am about to recommend, but these are the ones have used and the ones I have had recommended to me.
- Version Control – Subversion, git or Mecurial
- Defect, Issue and Enhancement Tracking – Bugzilla or JIRA (though it is COTS, it is fairly reasonable in terms of initial and maintenance costs)
- Agile Tools – ScrumWorks Basic (the Pro version supports integration, but at a cost), PPTS (Bugzilla), GreenHopper (JIRA, though it is also COTS it is by the makers of JIRA and is fairly reasonable in terms of initial and maintenance costs)
- Build Management – CruiseControl, Hudson