How to select an open source for your commercial product developmeny

I have touched upon this topic loosely in my previous posts, but I will try to put a more comprehensive list here. First of all many techniques in evaluating a 3rd party ISV's software building block and Open Source Software (OSS) remain the same. They differ in licensing, how you judge the licensing organization's long term stability, etc. Anyways, here goes

(1) Fitment for pupose - Before you consider anything else, the reused FOSS component must be fit for your use. You can't a square peg in round hole if its corners fall outside the circular boundary. You should have a list of functional requirements and non-functional quality attributes (which are probably the same as that you would have for evaluating a 3rd party ISV). Better to have a Priority list for further selection.

(2) Go through the licensing terms & IPRs very carefully, If its policies are a problem for your commercial software distribution, then evaluate the workarounds and whether they are acceptable (like seperate distrubution in case of GPL, opening of using code, etc) for your software management. You may have to compromise here

(3) Check whether the community has support (sponsorship) of big companies. It is likely that in such a case the open source will have a fairly long usable lifetime and will not be shutdown entirely, go commercial or be bought over canceling the license. Anyways, the action of no-step motherly treatement to adopted child will help you handle this scenario.

(4) Check about the number of developers working on it. If the list is large, the open source will be active and supported well in future. Lack of interest would implify risks in medium-to-long term stability.

(5) Check the Bug tracking tool for a list of open bugs, date of filing & date of closure of historical defects, defect trend, etc. Check how many new features are being added every release. This would give you an idea about the stability of software and the activity on the codebase and the support that you may get for bug fixes. Its like judging ifthe  inhouse development software is reaching a stage that is fit for shipping it out. Frequency of releases was earlier used as additional metric to test for stability, but the meteric is now slightly archaic in the Agile world and should likely be done away with as long as  small no. of enhancements are being done in each release

(6) Check references of other adopters in the business segment (or even outside it). If more adopters are there it is likely that the software is fit for use.

The items in (2)-(6) will refine the priority list you identified in (1), but if your team is prepared to undertsand, modify and support the adopted open-source, then that in itself will be a conisderable hedge against the risks. And you should be prepared to contribute back to the community in any case.

Also since this is an external dependency consider, considering wrapping it with an abstract enough interface and let your proprietary source use the Adaptation APIs. Sometimes some decisons go wrong or are not in our control or their could be a new smart kid on the block, whom you would like to use. At that time this Abstract interface implemented over the open source APIs will return your investment in gold.