sorted by: recent | see : popular

Content Tagged with matt + MySQL

I?ve been reading The Bee Keeper (also here in PDF), an explanation of the relationship between professional open source software (POSS) vendors and their communities, written by Pentaho?s CTO James Dixon. It is a very elegant explanation of the development/business model employed by the POSS vendors such as MySQL, Pentaho, JBoss and Alfresco.

James uses the analogy of the Bee Keeper to explain the model. It?s worth reading the paper in its entirety to understand just how appropriate this is but to put it very simply: the vendor is the bee keeper; the community is the bees; the open source project is the honey; and the customer is after processed honey (supported open source software). In order to be successful the bee keeper must satisfy the customers but also the bees, to ensure that they do not leave the hive, or sting him.

The analogy goes much deeper than that but you get the idea. One of the limitations of the Bee Keeper model, as admitted in the paper, is that it applies only to vendor-dominated (some would say captive) open source projects. As James writes: ?This model does not apply to POSS companies with service/certification models such as Optaros, SpikeSource.?

I?ve been thinking about that, and while the Bee Keeper model does not apply, I think the analogy of bees and honey can be adapted to fit both the service/certification models and hybrid/proprietary extension models, as well as explain the approach taken by vendors that support or build on community-led projects such as Apache or PostgreSQL.

The answer comes from the fact that, as well as man-made hives, wild bees also produce honey in bee nests, from which the honey is available to everyone who fancies trying to extract it.

If we assume that there is an abundance of bee nests (and I would describe 179,979 SourceForge projects as an abundance) and that many of these nests are both mature and highly productive (like PostgreSQL and Apache) then we begin to see how a business model could develop based on the collection and processing of wild honey, rather than man-made hives.

There are some consumers (adopters) that might prefer the taste (and low cost) of wild honey and are happy to go to the effort of collecting it and processing it for themselves. However, if they do not want to take the time or the risk to do so instead they might pay a honey collector (support provider) to do the job for them.

While the honey collector does not have responsibility to look after the bees that a bee keeper has he will have to take care not to disrupt the nest and may well choose to make an effort to nurture the nest and encourage honey production. Of course, as these are wild bees there is also always a risk that the bees will leave the nest or production will dry up.

The collector is also aware that any improvements resulting from his efforts are available to everyone and rivals can easily set up alternative honey collection businesses. A solution to this problem is to add more value beyond the pure honey and/or use the honey to create something else, with the honey collector adding some proprietary know how of his own to create a related product.

If we accept the accuracy of Wikipedia?s statement ?most commercially available honey is blended, meaning that it is a mixture of two or more honeys? then we begin to see how there is a role for honey collectors to become blenders (service/certification providers) that pick and choose honey from a variety of freely available bee nests and blend it together to produce a more palatable product.

Taking this a step further there is also an opportunity to create a completely different product. An example would be a brewer of mead. A brewer could of course choose to develop his own honey using man-made hives or acquire honey from a bee keeper, but by exploiting wild honey he lowers production costs and focuses on the additional value he brings to the production process.

EnterpriseDB is a great example of these models in action. The company is a honey collector - offering technical support for existing PostgreSQL deployments for those that want some extra peace of mind, while its Postgres Plus and Postgres Plus Advanced Server products are based on the community-developed PostgreSQL database.

EnterpriseDB is also a blender. Postgres Plus includes the core PostgreSQL database, as well as additional free and open source packages, such as open source database migration tools, grid capabilities and geo-spatial support. These technologies are also available for free, but customers are prepared to pay a fee to have the company combine and support them. Other examples of open source blender companies would include Optaros, OpenLogic and SpringSource/Covalent, or even larger services providers.

Meanwhile it is also a brewer ? adding proprietary extensions such as migration tools, Oracle compatibility and dynamic tuning to create Postgres Plus Advanced Server. These technologies are only available from EnterpriseDB and come at a price. Other open source brewer companies include IBM, Greenplum, Netezza, and Datallegro.

As EnterpriseDB shows, it is possible to follow more than one model at the same time.

Does that make sense or have I stretched the analogy too far? I am really thinking aloud here so it is quite possible I?m talking out of my a?nyway, let me know what you think.

By the way, in The Bee Keeper, James also writes: ?I don?t know how applicable it is to POSS companies with distro models such as Red Hat Linux and SuSE Linux.? I?m with him on that one. The Linux kernel/Fedora/RHEL model introduces a two-tier hive/nest and whichever way I think about it, the analogy doesn?t seem to fit.

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.