alfresco

Oct 15 2008

Let the customer choose where to buy lunch from !

Matt Asay is pushing his favorite Open Source model again. The model where the majority of developers of a project work for a company and that company is creating a business around the project. There's nothing wrong with that model, but he seems to forget the other models time over time :)

Matt is absolutely right with 2 of the 3 things he wants you to consider.
A SI in the middle of a $50 million dollar project involving Alfresco not talking to Alfresco is just wrong. An SI not offering a support contract is also just wrong. But an SI forcing his customer to buy the commercially supported version from a vendor ? Where's the customer choice ?

The customer should have the option to choose for a commercially supported version or the free version. And preferably that should be an educated option.

Matt seems to forget about situations where an Open Source project is not managed by one central organization , by one company that contributes most of the code. What companies are in charge of Apache, Linux (and don't reply RedHat here), Xen (No it's not Citrix anymore) , Samba , and lots of others.

If you were in Australia why wouldn't you get a MySQL support contract from Arjen Lenz ? Even if he didn't have MySQL Partner Certification ?

If you were in Germany , as a Centos or even RHEL user would you want to get your critical Samba Support from some support guy at RedHat or from some German guy at a local shop

If Michael Badger were in the SI business , would he be a good partner to support your Zenoss setup ?

3 totally different cases, the ex-employee, the developer not employed by a vendor, the guy who wrote the book.

Not all Open Source projects are backed by 1 clearly identifyable company, lots of open source developers work at SI's and they might be a better source for a specific project than a vendor that just integrated their product.

Worse even .. I've seen tons of traditional SI's jump on the Open Source wagon, by working only with the Commercially backed Open Source tools, as if they were proprietary software. Obviously the commercial Open Source vendors love these SI's they are the best resellers , and probably the worst integrators.

So Matt, please remember, there is more open source on this planet than your corporate backed open source, I haven't seen figures , but my bet would be that the corporate backed part is the smallest one.

In the end the most important thing is that the customer has got to have the educated choice between the locally supported opensource alternative , or the locally supported opensource alternative with commercial backing ..

But then again , it might be the European vs US vision however :)

May 13 2008

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.

May 10 2008

This week in Gent

On Wednesday Gent hosted the IBBT Brokerage event, some usual crowd, lots of unusual crowd .. but mostly trying to figure out what's the difference between the startups I usually run into and the ones I saw at the IBBT event. The weirdest part .. the language .. Dutch...

Thursday was the Fireside chat with Seth , again some usual suspects , but also some unexpected people .. Seth gave an interesting overview of the current Java Content management platforms , Daisy, Magnolia,

Obviously the language debate came up , I really need to finish that blog post :)

The format, 1 presentation followed by 2 shorter group brainstorm sessions where one member of the group presented the findings was really interesting, you ended up speaking to people you don't always run into. Altough the 25 minute brainstorm sessions migyt be a bit longer. Definitely worth another version. Just the food afterwards... 3 times spare Ribs at Amadeus in 4 months time is just too much .. next time Gekroonde Hoofden please :)

Then Friday, Matt and I spent the day in Gent brainstorming about that undead project :)

May 06 2008

Doesn't Matt Asay want Open Source integrators to earn a living ?

Or, why the Inuits won't partner on selling Ice from Alfresco unless they change their strategy.

I usually agree with lot of the things Matt Asay writes but today in Closing an open-source deal trough your systems integrator , he thinks the way to work with partners in an opensource environment is to force them to sell the commercial solutions of your products.
He also thinks you should block them from starting an implementation before the end customer has signed a purchase order.

Whew.. this must be the most stupid idea he had since he started his opensource career. The sad part is that I haven't seen a commercially backer of an opensource project dealing correctly with its contributing partners. He isn't solving the problem , he is creating a bigger one :(

Integrators and consultants are often the bigger contributors to a project because they are integrating new features for their customers, You know, their local , we speak your language , customers. So now Matt wants to force them not to sell services around GPL software anymore but sell the commercial versions ?

As lots of commercial opensource versions do not allow you to make changes to the code if you don't want to loose support your hands are tied again. And yes I have been in this situation before multiple times, a situation where , a commercially backed opensource project, required a couple of small changes to fit with a customer, because of these changes the commercial vendor would drop support , so the customer decided not to buy the license. Should a local integrator capable of helping such customer loose that deal because of a partnership ? Off course not .. It's perfectly understandable that a software vendor can't support every different patch. Shouldn't an integrator have the freedom to assist a customer in making these choices, and give him valuable advise ?

Forcing the integrator to sell the commercial version brings them back to the proprietary software vendor situation , where they couldn't solve issues either.

Mind this is a Category "C" user ,(an organization that has more money than time), which should be an easy win for the commercial opensource vendors.

Then there is the issue of Paying twice where a customer both pays for the time the integrator spends on solving his issue and the support contract. I`m stil looking for a solution for this one.

In the past we invested in different partnerships , some requiring certification, with different Open source vendors before, never got a dime back from these investments.

While our shop was a small but specialist expert knowledge center most deals that those other vendors had in our area went to the incompetent boxmovers that did volume, often totally screwing up the actual implementation. Whether we had contributed to the project, or in the case of Linux distributions were probably equally skilled to support the environment as the vendor itself didn't matter.
We didn't sell enough boxes , so we never got any deals back. Our business is advising people on how to implement open source , implement it for them and support them. We are working with both type A,B and C customers. But the commercial opensource vendors want to force us to go back to the old proprietary boxmoving model, sell licenses, don't sell solutions, Oh and No you can't fix that .. you'll have to wait for the next commercial release or lose support.

So how many of the opensource benefits should the customer give up ?

No Matt, this time your idea stinks,

This way skilled consultants that care about open source and contribute to the community are being punished for doing so, whereas they should actually be getting business back from the vendors, so they can earn money and contribute more on your product you force them to waste more time on the sales side. While the people that just move boxes, don't care if its an open source application or a proprietary package gain more. For them its just business as usual .. selling boxen.

It just doesn't make sense

This concept is just bad for opensource in general, motivated people will stop contributing to products they implement, as they see that their efforts aren't appreciated by the vendors.