Bill Burnham posted about an entrepreneur he knows that’s using an overseas outsourcer to customize and maintain their Open Source CRM.
He recognizes the benefits of having third parties prototype with a free community version when the production deployment would result in a subscription to the CRM company. But he also points out that some outsources are deploying community versions for their clients and offering support, competing directly with the CRM company. He suggests that long term, this kind of competition has the potential to undermine the economics of the Open Source business the CRM company is trying to build.
On the surface, this seems to make a lot of since. However, if you dig in a bit you’ll see that having a vibrant open source ecosystem built up around a project is perhaps the best thing that could happen to the CRM company. Even if that ecosystem is driven by services around a community version. I think if you asked the CRM company about this, they’d agree.
Its important to recognize that the community version will always remain the vanilla community version. It can never become the professionally supported version. If it diverges from the community version, it’s a fork.
Neither the community version nor a fork is a credible alternative to the professionally supported version that you’d get from the company. In fact, the fork most likely couldn’t even be called by the same name without violating the CRM companies trademarks.
I’m not saying that under certain circumstances they wouldn’t behave in the same manner. I’m simply saying they are not the same.
So, its the community version, or a fork, is that a problem?
It is a big problem if you want timely fixes and updates and/or want to remain on the strategic roadmap that the company (project) has set out.
Let’s say a customer has a support contract for the community version with an outsourcer. If there’s a bug, who’s going to fix it? The outsourcer, right? But what if there is no fix in the code base, or what if the company/project has indicated that they were not going to fix it until a future release. What’s the outsourcer going to do? Create a patch? What are they going to do with he patch? Do they have commit privileges in the code? Probably not. They could submit the patch back to the project, but what if the code is heading in a different direction and the patch doesn’t get rolled in?
Like it or not, the outsourcer just forked.
So now, the outsourcer has the ongoing burden of maintaining the forked code and over time this will most likely become a crushing burden to them. Anyone that’s been involved with using open source and created a patch knows that until it’s part of the code base, its a fork and may as well be toxic waste. No one wants to touch it.
It’s hard enough maintaining your own code, the last thing people need is the added burden of maintaining someone else’s forked code.
So, back to the CRM company. If a customer is willing to take maintenance from an outsourcer and live with the structurally inferior support as well as the potential to diverge from the project roadmap, they deserve a steep discount in support. It’s not worth the same amount.
This kind of support is indeed a commodity and the competition will be fierce. It’s up to the company/project to innovate and execute (just like any closed source commercial software company) to avoid sliding down the slippery slope toward this undifferentiated segment of the business.