The Consequences of Being an Open Source Company
No Matt, my brain definitely wasn't idle.. I've been thinking about these problems for the better part of the last decade. And it seems like I`m not the only one who wants this discussion.
Dries told me that as a follow up to my previous post I should write a post with solutions to the problem. Difficult as I don't have the solutions yet.. If I had them .. well :)
Fact is that different types of opensource products might require different approaches Alfresco to my knowledge has little to no contributing community , Linux distributions tend to have a big one, if not just in the form of the different open source projects they pacakge. The MySQL community is more one of documentation, helping out and bugsquashing. So my ideas aren't valuable for everybody, which is maybe why Matt Asay can't understand me, he might be looking at only one side of the picture.
There are some little things that I can suggest however.
Open Source works because of people contributing to projects, Open Source companies should recognize that and figure out a way to return more business the partners that also contribute to their code , this way they can contribute both on commercial and financial level. If you keep sending business to non contributing partners at the loss of the ones that actually commit code, some people will be unhappy. Those contributing shops might not be bringing the big revenue for the vendors, but they sure are contributing.
The other part is in the support model, Matt somehow thinks I`m in the "everything must be free" camp. Wrong, I`m in the right price for the right product/service camp.
Which means that if I`m escalating a support issue of a customer of mine to a vendor, my time must also be paid for. However that's a difficult sale, my client already paid for his support contract , to the software vendor.
So my suggestion, back when RedHat came to the Bemelux, was to have different types of support contracts, a customer could get a direct contract with a vendor where no integrator could log the calls. Then with another contract type if the a partner actually logs a call for his customer he must get some kind of kickback for that...
One of the advantages there are that more first line calls can be tackled by local partners, partners that might know their customers better.. but they still have a backup if they can't solve the problem. Therefore less investments are to be made in a support organization by the vendor.
And last but not least , don't tell your partners what they can't do. They should be listening to their customers, if their customers choose for the open source version it's the customers choice, and the partner should be able to help his customer, the last thing you need to do is punish them for listening to their customers needs rather than the vendors. This is how the proprietary world works.
Oh and Matt, next time you are in Belgium, let's do another round of Buytaert vs Asay :)
Maybe we come up with some better ideas than the above ones.
Comments
#1 Dino De Lellis : Escalating Support within an OpenSource context.
I like the Kris's idea mentioned above wherein customers could potentially get differing support levels based on local partners who were more familiar with their locale and its conditions with the step up to regional or national partners for critical problems that the local partner may not be ready to bet "the boat on".
I recently saw a postgre corruption problem in some secondary tables of a multi-gigabyte db site, that were detected and yet still went on for 6 months because there was no one locally was willing to take the chance to try to fix it without 2-3 hours of downtime on this live system.
Matters came to ahead, unexpectedly when a new software module had to use these secondary tables and the db simply crashed. They then endured 22 hours of downtime instead of what might have been 2-3.
If, for this opensource package, the customer would have had local experts who could have come in and face to face done the reassurance thing while they called a regional office, things would have gone a lot smoother. ( Fewer heart-attacks, fewer firings, few heads rolling down the red carpet -- just kidding )
And Matt, they would have paid thru the nose for both levels of help ...
Dino De Lellis
#2 Dave : Thanks!
Thanks!
#3 Matt Asay : Alfresco's community
It's true that we don't have a code community of Drupal's scale, but we get a fair number of code contributions from a range of Fortune 500 customers of ours, as well as SI partners of ours. We get a ton of input to our products from our community and, frankly, a heck of a lot of cash, too, which is also nice. And yes, we've also had "community contributions" from people that don't pay us money.
I love the Drupal community. But I'm not sure I'd trade it for my own. There are days that I would, but there are other days when I recognize that different types of community simply present different challenges and opportunities.
But there's no doubt that it's very hard to develop a community, be it an organic, "non-profit" type community or a corporate-centered community. Neither is easy, though the former is probably easier to create (and harder to monetize).
It might well be that monetization doesn't matter, but I don't agree. I think it does. We benefit from the money side of open source every time we use Apache, Linux, MySQL, Samba, and so forth. They're all heavily subsidized by greedy capitalists looking out for their self-interest. The code is better for it.
It's for us to help ensure that money doesn't come to dominate open source, because I personally feel that this would spoil the beauty and value of the open source ethos and logos. But let's try not to flame those (like, um, me) who are earnestly trying to figure out ways to make money in open source without ruining open source. There are plenty who don't care about the last part of my sentence, but I'm not one of them.