I was visiting a prospective client this morning, who was interested in using SalomeTMF as a test management framework, and we were discussing whether there was any risk in choosing it as a tool.

To prepare for the meeting, I had a quick look at the project, and while what follows is not a complete analysis, it certainly reaised some red flags and some gold stars about the project.

Background:

SalomeTMF was a project created by France Telecom, and it’s hosted on ObjectWeb, as part of the OW2 consortium. It is a modular test management framework written in Java, with plug-ins for various testing and bug tracking tools like JUnit, Bugzilla, Mantis, Beanshell and more. After a healthy start to the project, with a great many incremental releases over a period of years, releases appeared to have stopped in 2007, and the original developers and maintainers appear to have become dormant.

Analysis:

Currently the project appears lacking an active maintainer, but has many users and several developers. Its user forums are quite active, and a call for new maintainers (made by a disgruntled user) shows that there are a number of people interested in ensuring that the website, wiki and software get regular updates and releases. The best placed candidate for new maintainer is a developer who made a new release of the software in September 09.

There is one email from the historical maintainer which raises a red flag for me: he says “it has been a long time since we’ve actively maintained the project, but rest assured that it has not been abandoned… We are working with partners and users of Salome to ensure future maintenance and development of the project. I will keep you posted.” This sounds to me like the old maintainers are not quite ready to completely hand over control of releases and maintenance of the website to those who are working off the OW2 forge.

In this situation, project take-overs should generally be placid. If there is a possibility of conflict, the historical maintainers will retain the benefit of thedoubt until proven wrong, in which case many more months may pass. The alternative is an aggressive take-over where someone proposes themselves as (perhaps interim) maintainer, and makes releases, reviews patches and updates the website.

The bug database shows that there are not many bugs getting closed at the moment, suggesting that the user community is waiting for someone else to do the project maintenance.

I would have liked to analyse the source repository also, but I could only find a CVS repository in the ObjectWeb forge, which versions files rather than the repository. Most of the files I found have not been modified for 2 years or more. This is not necessarily conclusive evidence that the project is inactive - it is possible that other files I didn’t look at have been heavily modified, or that development has moved to another SCM.

Summary:

The project presents considerable risks -  no active maintainers, and a community which appears to be finding its way to the point where all of the keys to the house are available to a new maintainer. The documentation for the product architecture is good, as is thedocumentation for writing new plug-ins, but there is next to no documentation of the community governance structure, and the various community resources, who has access to them, and how one gains access.

Three options exist for a company interested in using the tool in the medium to long term:

1. Consumer - use the product as it is, do some basic work-arounds and bug fixes to get it working for you, and no more
2. Passive fork - develop the product to have features and functionality which you are interested in, and send patches back to the user forum & patch tracker. Have design discussions in public on the user forum. However, do not assume or try to assume control of the project.
3. Aggressive take-over - Ask the original maintainers to hand over access to all project resources to a community member - perhaps a developer in your team - and if this does not happen in good time, take your case to ObjectWeb administrators. If that fails, fork.

An aggressive take-over has the potential to be counter-productive, and expensive, and is as such not to be favoured. Perhaps encouraging the most prominent active community member to become an active maintainer is the best way to achieve the same end.

Which alternative is best will depend on the choices available. Alternatives to using SalomeTMF might be sourcing an equivalent commercial tool, or developing an alternative internally.

If the alternative is sourcing another application, then a cost-benefit analysis of choosing the commercial solution over modifying Salome is required. If SalomeTMF is close to meeting your needs, a passive fork is an attractive choice.