News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Integration Watch: From open source to commercial quality: A study in rigor




October 15, 2009 — 
For the last year, our company has been working with a client that is moving from a purely open-source model to a commercial product. The OSS product is already widely used, so the first year has consisted of setting up the corporate entity, creating the support infrastructure, and building a sales team while closing deals with users who were eager to get a commercial license and/or priority tech support. Next year, working from an established base of customers will see a stronger push for sales at sites not familiar with the product.

The model is slightly unusual: a self-funded OSS company is a rara avis. As a result, there are no case studies to build on, and much of the details of this particular model have to be learned on the run.

One particularly interesting set of changes occurs in product development and management as the transition from OSS to commercial quality is undertaken. Some readers, especially OSS diehards, will view this as a false dichotomy. Nothing in the OSS model should imply software of less than commercial quality. At least, not in theory.

This particular project consists of roughly half a million lines of code that were written primarily to solve a specific set of problems. The developers had certain business needs, wrote a solution, and shared it as OSS. They also wrote more than 600 pages of documentation. However, they did not design the product to compete with commercial offerings. Over the years, other contributors added pieces here and there to solve other specific problems: generally, just enough code to obtain a specific feature.

As a result, one of the first things we’ve done with the product is to decide what features to remove. What features are partially implemented with no likelihood of completion? What features add nothing to the value proposition of the product? What features that are not central are more trouble than they’re worth? All of these features are being removed and put into a separate OSS resource pool that users can adopt, while keeping those bits out of the commercial offering.

We’ve also changed the release schedule. Prior to commercialization, the core team put out new releases four to six times a year. They believe in the agile creed of frequent small releases.

However nice this practice is for internal product development, it is anathema to enterprise customers and ISVs. They want no more than two releases a year. And they’re not terribly happy about patches to those releases. Having fewer releases makes it easier to sell against future features, and the longer planning cycle enables true product management, rather than “whatever is next needed,” which is characteristic of OSS projects written primarily for the needs of the contributors.

Predictably, quality requirements have increased as well. Previously, the development process was at Capability Maturity Model (CMM) level 2: repeatable, but not defined, managed or optimized. This has been one of the more challenging changes. Developers who have maintained their quality standards at a given acceptable level of quality are not easily convinced of the need to tighten quality control—especially as this requires more effort.

To a certain extent, new tools—made possible by the ingress of funds—can be of help in the process. For these purposes, we’ve been examining Atlassian Studio, which provides hosted versions of Subversion, JIRA, Confluence (a wiki), FishEye (SCM analysis), and Crucible (peer code reviews) for $25 per developer per month. This solution appears to be tailor-made for small, distributed teams like ours.

The last major change is the nature of support. Hitherto it has consisted of posting answers to the mailing list. This has worked fine within the confines of normally accepted protocols for asking for help online. With paid tech support, however, all questions must be answered quickly, and ignoring stupid or rude questions is not an option. Moreover, customers expect something more than a mailing list—generally a private portal of some kind. Support is one of the areas where the value of a paid license can be made especially conspicuous, so its proper implementation is, and should be, a high priority.

Interestingly, all these changes are for the better and all, without exception, rest on one aspect: introducing greater rigor. This rigor is the quality often missing from OSS projects, in part because it’s difficult to impose it on contributors who are donating their time. But OSS projects that want to stand out from the crowd or are entertaining thoughts of eventually going commercial can help themselves significantly by establishing a pattern of this rigor early on.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.


Related Search Term(s): open source


Share this link: http://www.sdtimes.com/link/33835
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading