451 CAOS Theory 
A blog for the enterprise open source community
Is it asking too much to expect corporate contributions from paying customers?
Matthew Aslett, April 16, 2009 @ 10:11 am ETAre vendors that ask their paying customers to also contribute code changes trying to have their cake and eat it too?
The issue of increasing corporate contributions to open source has been bubbling under ever since Jim Whitehurst highlighted the lack of enterprise participation during a speech at the 2008 OSBC conference.
Whitehurst also mentioned the topic during 2009’s OSBC but in the intervening year there has been little in the way of visible progress. Perhaps this is because it is asking too much.
If it is true that there are two types of people, those who will spend money to save time, and those who will spend time to save money then is it not somewhat unfair to expect those that have already spent money to save time to also spend time on open source contributions?
Most open source vendors expect enterprises to be the paying customers rather than the community users but if the software in question is only really of interest to enterprises then it stands to reason that the vendor will struggle to encourage community contributions.
A radical solution to this problem is to not ask enterprises to pay for your software.
This is the approach taken by Funambol, for which enterprises are the community users of its push email and mobile sync software and service providers, carriers and device markers are the paying customers.
The company separated its user base in this way because, as CEO Fabrizio Capobianco explained at OSBC, “in my opinion the community edition should be targeted at the enterprise, as they are more likely to contribute code back”.
Clearly this approach is not going to work for all software segments but the rise of cloud computing, SaaS/PaaS and hosting providers does point to a new target market for software vendors: ask the service providers to pay for the right to build or offer a service based on your software and sell that to enterprises, but allow enterprises to use it for free in-house.
This approach relies on the use of the AGPL license, which ensures that third parties are not able to offer the software as a service without being compelled to contribute back.
Even then there are no guarantees that enterprises would be more inclined to contribute back to the community. There is no way of compelling corporate contributions unless enterprise distributes the modified software beyond the firewall.
A lot of vendors would find it hard to change the habit of a lifetime and not expect enterprises to be their direct paying customers. Fabrizio’s other piece of advice, which is “do not sell anything to your community, do not even sell them support” would be particularly hard to stick to.
But if a vendor is asking enterprises to spend time and contribute code, then a start would be not asking them to also spend money.
Comments (6) Categories: Licensing,Software,Storage
[...] news by Matthew Aslett « Computer IT Jobs Vacancy: [computer-jobs] Excellent senior .NET [...]
I think in general every open source project whether commercial or organic should not worry about ‘struggling to encourage community contribution’. The whole point of most contributions is that the community is self-motivated to do it. For example the reason I submit bug fixes to projects is that I don’t want to maintain that fix, the same goes for new features etc. Encouraging contributions means trying to motivate people you have no control over.
The best strategy is to make the contribution process as easy as possible. Get out of the community’s way.
At Pentaho we have had no problem getting contributions from partners and customers. They employ some of our most active contributors. But we don’t do anything special to encourage them.
I think telling a potential customer that is looking for a ‘whole product’ that they cannot pay with money, but have to write code, will cause confusion. Confusion in the sales cycle is not good.
When it comes to bug fixes I think the case is fairly clear. One of the reason a customer pays money for the product is so that the vendor will fix bugs for them. Community members don’t have that option so they must fix the bug themselves and then contribute the fix (to reduce maintenance costs).
James
Hi Matt. I think in a lot of instances, it’s not so much that vendors “expect” paying customers to be contributors. For customers who, for one reason or another, need to modify the source code, it’s better to contribute it back and have the vendor maintain and upgrade it.
When someone signs up with us, we don’t say “now be sure to contribute,” and most never see or use the source code. But if they *do* modify code to add features or fix bugs, it will usually be better for them if they contribute it.
-Lance
Pentaho
That is a good point.
[...] whether what they use is really open source (EOS Directory), whether they are ready to contribute (Matthew Aslett, 451 chaos theory) and on how companies can design their revenue model (e.g. the open core thinking). Having talked [...]
[...] whether what they use is really open source (EOS Directory), whether they are ready to contribute (Matthew Aslett, 451 chaos theory) and on how companies can design their revenue model (e.g. the open core thinking). Having talked [...]