6. Commercial Open Source Model

Beekeeper Model for Single-Vendor Commercial Open Source

Now lets turn to the Beekeeper Model:

The Beekeeper creates an environment that is attractive for bees: accommodation and a natural, food-rich habitat. The bees do what they do naturally and make honeycombs. The honeycombs are processed and the resulting products, honey and bees-wax, are sold to customers. The money from the customers is then used to grow the bee farm. Notice that there are multiple roles that need to be filled within this model and that some of those roles are focused on the bees, whereas some are focused on getting the honey and wax into the hands of customers.

Notice also that there is no interaction between the customers and the bees.

The single-vendor commercial open source model looks very similar:

Single-Vendor Commercial Open Source software companies exist as an exchange system between two sets of consumers: an open source community (motivated by mutual contribution) and a mainstream market (motivated by economic rewards). Organizations in need of support, services, and training etc contribute financially for those services as paying customers. That money is used by the company to pay for full-time resources (engineers, product managers etc.) whose efforts (the majority, if not all of it) end up as open source software, freely available to an open source community. The open source community contributes to the software by helping improve the design, functionality, quality, translations, and documentation of the software. The improved software attracts more customers and the cycle continues, hopefully perpetually. In this model all three parties gain:

• The community gains open source software they can use for their own purposes. This software has more functionality and more resources than a ‘pure’ open source project could provide. In this way the community profits directly from the company and its customers.
• The customers gain higher quality software at a better price. The customers profit from the open source community’s ability to produce high quality software.
• The company gains by growing and increasing its valuation as a result of keeping both sets of consumers content.

The Beekeeper and Maple Syrup Farm models work well because the end products (bottles of honey and maple syrup) are very similar and are distributed, packaged, and sold in similar ways. You do not need to know how honey or maple syrup is made in order to buy either of the end products. The big difference is the way the raw materials are created. In the beekeeper model the raw material is generated by a mutually beneficial partnership between the beekeeper and the bees.

In addition:

• The closest ties between the company and the community are through the engineering (includes development and quality assurance) and product management (PM) groups.  These roles are ‘honey-focused’. There are interactions between other departments of the company and the community but they do not happen on the daily and hourly basis as with engineering and product management.
• In this model the roles of Engineering and product management become much more closely aligned to each other because between them they are sharing the role of the project administrators of the open source model.
• There is no buffer zone between engineering and the consumers of the software. In fact the engineers have more routine contact with the community than anyone else in the organization. The roles of engineering and product management are significantly different compared to the proprietary model. In the single-vendor commercial open source model the engineers have continual, direct communication with the community (open source consumers). In the proprietary model direct contact between engineers and the consumers is not a major part of the model (an understatement). In fact contact between engineers and consumers is usually kept to a minimum.
• The Sales, Marketing, Support, and Services departments are market-focused. Their roles are oriented towards the customers and are involved in an ongoing process of creating a whole product around the software and getting it to market.
• There is usually a community liaison role within the single-vendor commercial open source company whose job it is to focus on community growth and satisfaction, and to assist with incoming contributions. Open source projects typically do not have this role.
• Engineering and product management are involved in both aspects of the model. Their roles in the productization process are not significantly different from the corresponding roles within a proprietary organization.
• The productization process is highly inefficient if it has to react to the contents of the software after it is done. That is to say the participants in the Productization process need to be involved (if only passively) in the creation of the software to avoid significant delays in creating the whole product.
• Since the company creates most of the software they are in a position to monitor intellectual property, license, and patent issues. Many single-vendor companies have contribution agreements that include copyright assignment so that any IP-related issues can be cleanly resolved.
• Note that, at a high level, the roles of the Sales, Marketing, Support, and Services departments are very similar between the single-vendor commercial open source and proprietary models. This is because they are focused on the whole product aspect of the model. A prospective customer should not have to learn about open source in order to become a customer. The sales and marketing materials should neither hide their open source model nor require understanding of it by the market. The business model of the commercial open source company is a competitive advantage that should be presented to the customers, but if they are not interested or do not understand, they should still be able to purchase offerings easily. Although the role of marketing is not fundamentally different in this model the strategies, tactics, and techniques used to market the software are different primarily because:
  • A mass marketing approach is used instead of a high-touch, expensive enterprise approach
  • A prospective customer’s transition from the marketing domain to the sales team occurs significantly later in their experience.

As you can see there are numerous similarities between the Beekeeper and single-vendor commercial open source
models:

• Bees can fly and so have the opportunity to leave the bee farm if they decide to. So the Beekeeper must tend to his bees. The Beekeeper has very little control over his bees and has no ability to direct them to do his bidding. Likewise the community, if they are unhappy with the project, can leave the project or even worse: fork it (see the Wikipedia entry on Fork). So the company must keep their community happy. The company cannot rely on the community to follow any directive or schedule it might have.
• Bees can sting. Community members can publicly object or criticize the company on its own or other web sites.
• The growth of the bee farm depends on how much honey and wax the Beekeeper can sell to direct customers (passers by), channel partners (the grocery store), and OEMs (the candle maker). How much he can sell depends partly on his business skills and partly on how much honey and wax he has. How much honey and wax he has depends on how many bees he has. How many bees he has depends on how much honey and wax he lets the bees keep for themselves. In order to achieve maximum growth the Beekeeper must grow both his bee population and his customer base at the same time. Likewise a single-vendor commercial open source company must perform a balancing act and grow the community and customer base together.
• The bees and honey came first. There is no chicken-and-egg dilemma here. The Beekeeper invested time and effort in his beehives before he had anything to sell to his first customer. The longer he spends building his bee population before he starts selling products the quicker it will grow. Likewise the single-vendor commercial open source company must build a community that helps create the software before they can engage in the commercial world. The longer the company can focus on adoption before having to worry about revenue the better it will be. In many cases the up-front investment necessary to create a usable seed (bee farm) is substantial and beyond the capacity of a volunteer or self-funded team (in a timely manner). This is the entry point for venture capitalists (VC), and they have heavily funded commercial open source companies (over $3 billion between since 1997). It is more attractive to invest in a disruptive commercial open source company than to invest in a new closed-source proprietary software company that has to compete with open source.
• Each bee hive has a queen. In order to start a new hive the Beekeeper needs to attract a queen and enough of her bees to make the hive viable. Likewise open source projects often have a single founder or administrator that is the main leader of the project. Open source projects can be ‘acquired’ or ‘merged’ if the project leader and prime contributors are convinced that the move is beneficial to the project.
• The customers don’t want to deal with the bees. A single bee or even a swarm of bees cannot directly meet the needs of any of the Beekeeper’s customers. It is the work of the Beekeeper that turns the efforts of the bees into the whole product that the customers desire. The honey in the jar is the same honey that was in the hive, but the customers will only pay for it in a jar. Likewise the commercial customers don’t want to deal with open source. They want a whole product.
• The customers’ cash is no good to the bees. A crisp bank note or a pile of coins is of no use to a bee but the Beekeeper can use that money to buy hives, bee feed, or bee medication (those varroa and tracheal mites can be problem). Likewise the company’s customers do not directly help the open source community. It is only when the company uses that money to pay for engineering resources to improve the open source software that the community benefits.
• Each individual bee makes a small contribution to the system. It takes a large number of bees for a successful outcome. Likewise the contributions of the community are vital to the model but the individual contribution of most community members is small.

In my definition if a group of people associated with a single commercial organization develop or maintain a substantial part of the software (60%) and/or they provide the majority of resources (download site, wiki, other online tools etc) they are operating a Beekeeper model. Within this category, however, there are significant differences in how contributions and software development are managed. If you are looking at code contribution only:

• OpenNMS is very democratic and open about the software development process
• MySQL is notorious for being opaque and difficult to contribute code to

If you broaden the scope to include use cases, peer review, testing, documentation, translations, forum help, bug fixes, scalability studies, configuration diversity and quotes & news the contribution story is more open across the board.

To provide some context: in my experience contributing to Apache Foundation projects (wild hive) has been like giving candy to fog: I stand there and hold out my offering and it falls to the floor in silence. In contrast contributing to Alfresco, JBoss, and MySQL has been easy and rewarding. I still use Apache software for many things but I have given up trying to contribute. Philosophically, the Apache Foundation projects are the most open of all of these, however, in practice, the effort required to contribute is beyond my endurance.

To my mind, you need to look at all the barriers to accepting contributions of each type. The barrier could be philosophical, organizational, procedural, legal, resource bound, or something else. From the perspective of a contributor, unless they are told, they might not be able to identify the barrier.

Community and Customers

Customers are corporations, the community are people. They have very different needs.

In the Beekeeper Model customers are not bees, bees are not customers, and you cannot convert one to another. It is impossible for a bee to pay for a product and for a customer to make honey. I call this the Consumer Dichotomy. It seems that this might not apply to the commercial open source model and so is a limitation of the analogy but it is not. The customer in the Beekeeper analogy equates to the organization that is paying for the whole product from the commercial open source company. The bees equate to the community of individual employees and enthusiasts.

In the diagram above notice that all the customers have a monetary relationship with the commercial open source
company. Notice also that the community members provide contributions. Some of the community members are
employees of customers, but many are not, and some customers have no community members on staff.
Consider:

• The company often knows a community member for a long time before finding out who they work for. Sometimes they never find out. Community members often remain part of the community as they move from employer to employer.
• For business software the sales contract is between an organization (customer) and the single-vendor commercial open source company. If an employee in a role that is a touch point between the customer and the company leaves their employer, a new individual is nominated to fill the role, and the old employee is no longer a part of the relationship but the organization still is.

The community/customer discussion becomes complicated when community members and customers get mixed together. This happens frequently. But in terms of the model, the customer is still an organization, and community members are still individuals, it’s just that some of the community members work for some of the customers.

This distinction between customers and community is important when it comes to attempting to turn members of the community into customers. The sales and marketing groups need to be aware that, in most cases, it is not possible to convert a community member into a customer. However is it possible to convert the employer of a community member into a customer. Slamming community members with a marketing pitch is unlikely to achieve this.

Community members have the potential to persuade their employer to become a customer. The members themselves typically have no budget or no control over how the budget is spent. A commercial open source company needs to educate its community members on the services that are available and the long term advantages to everyone if those services are used. The company needs to find a way of presenting this and enabling members to present it to their employer without de-valuing the capabilities of the community member.

When we compare the open source project model and the single-vendor commercial open source model we notice that the commercial model contains all of the people, processes, and items of the open source model. There are no elements missing. The difference is that the single-vendor commercial open source model includes a Productization process that produces a whole product.  The same differences exist between the Wild Hive and Beekeeper models.

When we compare the proprietary model and the single-vendor commercial open source model we see that the single-vendor commercial open source model contains all of the people, processes, and items of the proprietary model. Again there are no elements missing. The difference is that the single-vendor commercial open source model includes a community and all of the contributions that the community make. The same differences exist between the Maple Syrup Farm and Beekeeper models.

The single-vendor commercial open source model is a perfect (in mathematical terms) combination of an open source
project and a proprietary software company. It has all of the elements of the other models: nothing added and nothing removed.

Next: Service/Support Model