I frankly believe Blankenhorn is putting too much value into the user community. This is not to say that the user community doesn't matter. It does, especially for early-stage open source projects. However, with SugarCRM's large paying customer base of about 5,000 organizations, collecting user input regarding the new user interface, or any other feature, is simple enough without the need to expose the function to the much larger free-user community.
In many respects, SugarCRM's "Go Pro" marketing campaign, an effort to convince users to become paying customers, is the best form of security for paying users: knowing that SugarCRM's revenues continue to grow at a level that allows SugarCRM to invest in future product enhancements and remain a strong and viable vendor. No amount of free users can provide this form of security for a paying customer.
Learning from OpenSolaris
So where does OpenSolaris come into this issue? Its fate has been in limbo for months, awaiting Oracle's decision about its direction now that Oracle owns it. In fact, the OpenSolaris Governing Board has gotten so frustrated by the lack of action that it has proposed disbanding itself if Oracle does not engage with the community by August 23. Some community members are already talking about whether they would be able to fork the OpenSolaris code base and create a new community outside of Oracle's control. However, they are coming to the same conclusion that others reached in April: Although OpenSolaris has a user community, it does not have the depth of developer skills to shepherd an operating system project forward -- at least not enough to compete with the likes of Linux or Oracle's Solaris developers.
This is an important reminder for SugarCRM users, both current customers and potential customers. As large and vibrant as the SugarCRM user community is, even with access to the product's source code, expecting that another vendor will rise from the community to provide a better customer-to-vendor experience than SugarCRM does itself is a big, iffy assumption -- one that should not be part of your product selection decision. Keep in mind that Vtiger has already forked the SugarCRM code, and yet has not been able to provide a sufficiently strong value proposition to attract enough existing or potential SugarCRM customers.
I've said it before, but it's worth repeating: The best advice may be to simply ignore -- or at least put much less weight in -- the availability of source code when making a product selection. More often that not, you will have too much at stake elsewhere to take on maintaining a forked source code should difficulties arise.
This article, "Considering SugarCRM? Don't fall into the open source purity trap," was originally published at InfoWorld.com. Read more of Rodrigues et al.'s Open Sources blog and follow the latest developments in open source at InfoWorld.com.