I received an e-mail from Simon Romanski, director of information systems at Fulfillment America, asking about the nature of open source software and its intersection with commercialism. Open source software (the code) is free and open. You can pay for support, packaging, reliable distributions. If in what's called commercial open source, the code isn't all free, then should it be marketed as open source? It's a bit of a long story, so forgive the length. Here's Simon's original e-mail to me:
I have been doing a great deal of research recently into Web-based applications for businesses that are more specific than your typical portal providers like intranets.com. In particular, I have been focusing on the Web-based CRM providers. In this arena two companies have gotten a great deal of attention: Salesforce.com and SugarCRM.
The reason why I wanted to learn more about SugarCRM was because I thought it would be interesting to see if an open source product could actuallly compete with a purely Web-based service like salesforce.com offers. Salesforce.com has to be given credit for getting companies to host company sensitive information offsite at an ASP.
I decided to pull off the open source version of SugarCRM and find out what it really takes to get the system up and running. It took me two days of fiddling around with installing Apache, PHP and MySQL on a weak Windows 2000 machine (was also trying to get it working on Linux without much luck) just to get the SugarCRM install process to work. In the end I pulled off a version that had everything wrapped up into one executable which worked very well. By trade I am a web developer, not a programmer, I really can't complain that I had a hard time getting Sugar up and running.
When I finally got to the SugarCRM login screen my initial reaction was, 'Wow, this is amazing, salesforce had better watch out because these guys are moving, and they're moving fast.'
However, it didn't take me long to realize that there is a HUGE part missing in the open source version. That part is the ability to do grouping and to have various access levels that you can assign to these groups (SugarCRM calls them teams). For most organizations the inability to control users from deleting each other's contacts, schedules, leads, etc. makes it totally unrealistic to use. You can't exactly explain to everyone who you give an account to that they shouldn't delete information that other people have entered into the system.
Subsequently, Simon sent an e-mail to SugarCRM:
Thursday, August 25, 2005 7:58 PM To: email@example.com Subject: OpenSource
I don't get it. You say that SugarCRM is open source however the latest version (3.5) of the open source version still doesn't have the ability to group people (or as you call it teams). Now your Pro version has had the ability to do teaming since at least version 2.0. I can't help but think that this being a critical function of a CRM system is intentionally left out in order to steer people to the commercial version of you product.
Am I wrong here?
SugarCRM responded as follows:
Thank you for your interest in SugarCRM. On any given release 50% if our development goes back into the Sugar Open Source project. Given that you mention our 2.0 release, I am sure you have seen our open source project grow over the past few releases. Additionally with our module loader released in 3.5 the open source community has even more tools to easily develop functionality to be used with Sugar Open Source. In regards to decisions regarding which features go into each version of Sugar Suite are made by our product management team. That said, as a company we encourage feedback from our community and I will make sure your email is forwarded to them. Please let me know if you have any additional questions, and please continue to enjoy Sugar!
First of all, thank you for your quick response. Who ultimately controls the Open Source version? I see many requests for the grouping functionality in the forums.
If you update the Pro version of SugarCRM (which is itself based on the open source version) aren't you supposed to disclose those changes to the OS community? Or is it that the Pro version was always commercial and the the OS version was a subset of that version? Is there a certain amount of time that can pass before you disclose the changes back to the community?
While there have been a great deal of changes made to the open source version I can't help but think it will be a long time before the grouping functionality ever hits this version.
Simon's impression is that SugarCRM is using open source as a marketing tool, and in reality is just another commercial company.
Certainly, SugarCRM is one of many companies mixing open source and semi-open (paying customers can access the code and extend it under specific terms and conditions) or closed (proprietary). It's the mixed, upsell model that typically includes a free open source version for the lowest end of market (individuals, small workgroups) sans support, and for fee versions under various open source licenses. The SugarCRM Public License Version consists of the Mozilla Public License Version 1.1, modified for SugarCRM. Below is what you can do with SugarCRM's license, taken from the Web site:
What am I allowed to do with code that is covered by the SPL?
All kinds of great things! We are dedicated to building the strongest and most involved open source community possible. The SPL allows you to:
a. Run the world's best CRM system for your business.
b. Implement and integrate SugarCRM for companies.
c. Fix bugs.
d. Build new programs leveraging our APIs.
e. Freely distribute the SPL-covered source code.
f. Share contributions.
g. Sell new modules that you create under a license other than the SPL.
What am I not allowed to do with code that is covered by the SPL?
a. Sell any SPL-covered code.
b. Sell derived works of SugarCRM.
c. Restrict access to derived works of SugarCRM. If you make a code modification available to one person, you are required by the SPL to make that derived work freely available to everybody.
Can I sell new SugarCRM modules I create?
That depends. If you write a new module that is not a derived work (see below), then you own that code and can do with it what you please. In other words, you can sell it and distribute it under any license you wish. The key is that you can't sell a derived work of the original SugarCRM code or any other code covered by the SPL.
Given that 50 percent of the development of any version of SugarCRM isn't available to the open source community as free open source, based on the above e-mail from a SugarCRM representative, then SugarCRM is only partly open source, hence 'commercial open source,' but that is somewhat misleading.
I understand commercial grade open source or fees for support, maintenance services or special code or add-ons, but commercial open source as holding back features from the community? There's nothing wrong with the business model (it helps to ensure survivability), but attaching open source to it implies all the code is open to the community, as with Linux and the GPL license, not just to paying users. How about hybrid source as a better, but less marketable, term?
I chatted with SugarCRM's CEO John Roberts to get his side of the story. "Software costs money to build," Roberts said. "We are a commercial software company. Free is for 15 to 20 person implementations. Pro and Enterprise are for larger enterprise where team selling makes sense."
"We don't want to write software that
doesn't needs a lot of support. We are only holding back things relevant to larger enterprises," he added. [Note on the correction: Roberts sent an e-mail on 8/31 requesting the change above. He said that he meant to say that his company wants to write software that doesn't require a lot of support.]
SugarCRM also employs 18 full-time developers (out of a staff of 36) and works with about 50 other developers who have assigned Sugar CRM rights to their code under an Apache assignment agreement. "We never have anything in the Pro or Enterprise versions from outside developers," Robert's said. Contrary to what the SugarCRM rep told Simon, Roberts said that about 25 percent of the development for the new version(3.5) just released is held back from the free 'pure' open source version (also 3.5). Red Hat is more of a harvester of open source software, compared to SugarCRM, mySQL or Zend, which offer commercial versions, Roberts said.
As an alternative to SugarCRM's non-open source open code, SugarForge has modules, tools, language packs, skins and other code, as well as associated projects created by the Sugar Open Source community. Roberts said SugarForge has 900 registered developers and 90 extension projects. "Version 3.5 has a module loader, a framework that allows developers to write extensions, package them and post them so that end users can load them without any programming," Roberts said.
In other words, if you don't want to pay SugarCRM, go out and build your own free distribution and support it yourself or via another firm. "Our business model is based on an open source project, for which we actively develop the product and provide full support," Roberts said. The open source development methodology results in better software than black box, proprietary implementations, but the non-profit, open source model of a collection of developers who only work part-time doesn't cut it, he said. "We can produce vastly more code and functionality than we could part-time." And, you can keep some of the code behind a pay wall to help the sales effort.
"We don't believe in just providing a binary. We are really a community within a community. We are extremely fair and strict. We would never take something from a developer and put in a commercial product," Roberts continued. "People are comfortable with a hybrid model. They like the code, the application, the way the release cycle is managed, the cost and having input. It's ok to hold back a little bit, and we are consistent release to release for larger organizations. And, other parts of the community are ok with it because the larger organization funds the open source development. Commercial open source is in a gray area--we have to have clean separation between free and commercial versions."
A gray area indeed. Given what Roberts has said, the company should adjust the statement on its Web site about open source to be more in line with its commercial practices:
At SugarCRM, our source code is available to all. Download it, install it, run it for free or upgrade to a commercial license - your choice. Our bug lists are published, our feature roadmap laid out, our quality assurance testing shared with real customers - in real time. We only want to be paid once we have proven we have generated value for your company, not one minute sooner.
Postscript: Simon received an e-mail from Clint Oram, one of SugarCRM's founders and director for the SugarCRM open source project. Oram said that his company is looking at releasing the group permissions functionality that Simon requested into the Open Source edition in an upcoming release...