OSBC 2010 - Highlights - Day 1

For the third year in a row, I attended to Open Source Business Conference. Though I missed the morning keynotes, Day 1 was very enjoyable. I saw old acquaintances, met new ones and heard some insightful discussions on open source, the cloud and more. The unofficial themes of the day can be summarized as follows:

OSbc -> osBc -> Cloud -> Data

I use this shorthand to mean that the "open source" discussion has evolved from an emphasis on what open source means to software development; to an emphasis on the business opportunities open source provides; to open source as a critical element of the cloud movement and the next step in evolution of open technology; and, finally, to the principal that control of data will ultimately determine success in the cloud, further evolve technology and challenge the "open" movement.

I attended 3 sessions: a panel on the future of open source success, a discussion of Oracle's use of and participation in open sourece (note - I now work for Oracle), and Tim O'Reilly's future-focused closing keynote. Here are what I found to be the most interesting messages:

A. Open source solutions are commonly accepted by paying customers.

This theme came up in multiple contexts. Many open source products are widely used in the end user and enterprise IT environments. Many are also making significant profits. Customers seek open source for the quality of the products and the ability of open source to provide solutions that other vendors are not addressing. Cost savings is no longer the main benefit sought.

B. Open source continues to drive innovation.

Many software and business categories are still highly susceptible to the disruptive impact of open source alternatives. Open source has also impacted how software companies think about the sales and marketing processes. It cuts the cost of sales by removing the need to engage customers until they decide the software is valuable. Also, the high volume nature of many open source businesses has forced companies to design more efficient lead scoring and other sales processes.

C. However, open source might be approaching its limits.

The success of open source in the high volume, commodity sales model in open source might not be duplicated in other contexts. Also, implementations of so many value-add models over the years indicate how hard it is to identify the right balance between free and paid offerings. Each open source offering must monetize the unique solution it provides to customer problems, and support alone almost certainly will not be enough.

Possibly the biggest indication of the limits of open source is the dearth of public "pure" open source companies like Red Hat. Large companies have steadily acquired many of the most prominent open source companies and projects. While this is not necessarily bad for open source, it means that the impact of pure open source has been diluted throughout the industry instead of concentrating the potentially disruptive power.

D. The cloud is the natural evolution of the open source revolution, and is more transformative than open source.

Open source is likely the precursor to a much larger disruptive force - the cloud. Both the technology and spirit of the open source movement are critical to innovations in cloud technology. Cloud technology is already changing the way we look at operating systems and application stacks.

E. The cloud is important but still has significant limits - data ownership and control.

Companies that control the cloud infrastructure likely have limited commercial opportunities. Much like the experience of telco equipment providers, once the technology is deployed, few customers remain. By contrast, those companies that control how data is used within the cloud have great flexibility in providing compelling business offerings.

F. Rights and obligations concerning data will be the critical issue to address.

Tim O'Reilly illustrated the point best by asking whether we (the public) want a single company (like Google) controlling all our data. Everything from restaurant reviews to personal health records could be held by a single party that has its own ideas on how to use such information - good or bad. O'Reilly further emphasized the potential impact by highlighting the trend toward devices that contain sensors and wirelessly stream the resulting data to the cloud. The stakes are likely higher for data held by governments and the open source methodology could drive openness in this context.

G. Several companies and technologies were named as ones to watch.

1. VMWare - VM Ware has a chance to build an entire stack from operating system to applications, which might be a serious threat to Microsoft.

2. Red Hat - as the most prominent pure public open source company, the community had high expectations that the company would serve as a hub to aggregate an open source stack. Many believe Red Hat missed its opportunity to do so.

3. Google - Google has the unique ability to easily and efficiently integrate open source, cloud technology, and data

4. Opscode - provider of open source datacenter configuration management and infrastructure framework tools

5. Gluster - provider of open source data storage and management solutions

6. Erply - online solution for running an online business including everything from invoicing to relation management; great for open source startups looking for low-cost, powerful business solutions

7. Pentaho - rapidly growing open source business intelligence solution

8. Eucalyptus - open source "Infrastructure as a Service" cloud solution

Getting Started With Open Source Policies

Earlier this month I had the opportunity to work with Adam Cohn, Senior Corporate Counsel at Cisco Systems, to present a session on "Effective Open Source Development Business Practices" at the Practicing Law Institute's Open Source session on Free Software 2009: Benefits, Risks and Challenges in Today's Economic Environment. With companies of all types and sizes becoming familiar with and using open source software, creation and implementation of open source policies was a focus of our talk.

The structure and contents of an open source policy, as with any company policy, must be tailored to the particular needs of the company. As a result, this post does not focus on the specific contents of a policy (but see this article by Stormy Peters, Executive Director of the GNOME Foundation, with a "how to" on open source policies, including ideas on specific topics to cover within such policies). Instead it targets initial considerations in defining the term "policy," determining whether you need a policy, how open source fits into your risk profile, and if and how open source fits into your business strategy. Next, it offers tips on how to align your policy with your business strategy for maximum effect.

(Note: The content in this post is based on the PLI presentation, but are mine alone and do not necessarily represent the views of Adam, my co-presenter, or our respective employers.)


Initial Considerations

What does "policy" mean?

The term "policy" will have different meanings between companies, between departments within companies, and between individuals within companies. As a result, as you undertake the exercise of determining whether you need a policy and implementing the agreed upon policy, ensure everyone involved has a clear understanding of the meaning of "policy." For example, policies are implemented for a number of different purposes from minimizing operational risk (such as a manufacturing quality check process) to satisfying legal obligations (such as financial policies in support of Sarbanes-Oxley reporting obligations). Looking at this another way, a policy could be something as simple as a set of operational actions, a more complex set of review and approval guidelines, or a vision statement on what open source means to the company. Often, a "policy" will address many of these needs at once.

Do you need a policy?

Not everyone needs a true policy, and even when a policy is necessary, it should be tailored to address the particular needs of a company. Start by identifying the specific problems you are trying to solve, which might span from telling staff that open source software should not be used at all, to implementing robust processes to both use open source in product development and distribute software under an open source license. Also determine whether a separate, standalone policy is needed. You might be able to address the problems you identify through minor updates to existing policies, such as policies on use of intellectual property or review and approval procedures for product development and distribution.

What is your risk profile?

By identifying the risks your policy should address, you will be better able to make your policy meaningful. For example, your company might have a particular sensitivity to one of the following types of risks: (a) fear that use of open source, along with related review and approval procedures, will result in the inefficient use of resource as compared to the perceived benefit; (b) fear of lack of warranty or infringement indemnity; (c) lack of understanding of community needs and dynamics; and (d) lack of understanding on customer concerns and expectations concerning your use of open source. Companies that use open source sparingly for internal purposes alone might view (a) and (b) as bigger risks than (c) and (d) and should adjust their policies accordingly. By contrast, companies that are not involved in open source communities and that frequently distribute closed source products containing open source components might be more concerned about (c) and (d), and they would have different policy needs.

How does open source fit into your business strategy?

As with risk profile assessment, companies must also identify how open source fits into its business goals and adjust its use of open source and related policies accordingly. The results of a year-old Gartner survey indicate that virtually all technology companies use open source software. But, mere use of open source software alone likely should not be deemed an open source business strategy. By contrast, frequent use of open source for revenue generating purposes almost certainly constitutes an open source business strategy. Consider the following broad guidelines for when a business strategy might warrant a robust open source policy:

• Minor policy should be considered: (a) Incidental use of open source in product development; (b) Use of open source in development for internal use

• Robust policy could be helpful: (a) Frequent inbound use of open source in product development; (b) Participation in open source community projects; (c) Sponsoring an open source community

• Policy is strongly recommended: (a) Open source development tools with proprietary “crown jewels”; (b) Services business for a community project; (c) Dual license strategy

Aligning Your Policy With Your Business Strategy

Policies are often designed primarily to address risks or satisfy legal obligations. By contrast, strategies are used to indicate a companies goals to be achieved over a particular time. Policies and strategies cannot exist in a vacuum, and each depends on the other. Policies cannot be narrowly tailored to address important risks unless a strategy exists to help prioritize those risks. Similarly, strategies will not be successful unless proper policies are in place to assist in effective implementation and avoid or mitigate risks. As a result, companies should make alignment of open source policies and strategies a high priority.

Once a company explores the "Initial Questions" identified above, it should consider the following recommended actions to check for compatibility and identify areas where additional consideration is needed:

• Determine whether an operational "how to" guide is sufficient, or is a vision statement appropriate. A hybrid approach is likely most appropriate.

• Identify the specific business cases that would benefit from a policy (see the discussion on "How does open source fit into your business strategy?" above).

• Assess the impacted functional areas. Think broadly, beyond the development and legal teams. Your HR (employee participation in outside projects), IT (internal security), finance (lack of indemnification; revenue recognition), and other departments might also need guidance on how open source will impact their functional areas. Also think outside your company to assess the impact on your customers, partners and the open source community.

• Assign appropriate review and decision-making authority. The more important open source is to your business strategy, the more important it is for your managers to understand what open source issues they can approve, and the proper escalation paths.

• Test hypothetical business cases. While this concept is relatively simple, it can provide a meaningful sanity check before implementing a policy in a complicated business. For example, this type of review might identify that employees do not understand open source issues enough to implement the policy and strategy, which might require more training.

• Manage conflicts with other policies and strategies. For example, a company that rarely uses open source might have an supplier indemnification policy that would not be appropriate if it decides to use open source software more frequently in its operations. Open source components often don't have the warranty and indemnifications protections these companies are used to seeing.

Companies should review their policy/strategy alignment regularly to ensure both that their strategies accurately reflect their use of open source, and their policies address the particular needs of the company.


More Information

You might also find the following web links interesting as you continue your own research into open source policies (note that I do not necessarily endorse or agree with the content in these links, but they provide other perspectives on the policy discussion):

• Black Duck Software - Offers a whitepaper entitled, "Creating and Implementing an Open Source Policy: Five Steps to Success" (registration required)

• ABA Section of Science and Technology Law - Offers both a model open source software policy outline and a model open source software review/approval form that might server as starting points for a policy. These documents were drafted in 2005 by Heather Meeker of Greenberg Traurig, LLP, who is known for her frequent involvement in open source issues, and they are available for reuse and distribution under a Creative Commons license.

• Open Logic and Stormy Peters - Offers a heavily reference "how to" guide for policy creation. As referenced earlier in this post, the article provides more detail on the specific types of content that you might consider adding to a policy. Note: Open Logic also offers papers on how to write an open source policy and open source policy best practices (registration required).

• Digium - This open source telephony software/equipment provider shows (in multiple blog posts here and here) potential customers how to assess whether open source is right for them and to what degree. This is an example of a "policy" designed to promote a particular type of software by a particular provider.

Expanding Open Source Enforcement Strategies

What comes to mind when you hear "open source enforcement"? Probably the names "Busybox" and "Software Freedom Law Center". These organizations are good examples of the "cease and desist" style of enforcement in the open source context. But an enforcement strategy should go beyond "cease and desist" to also include other considerations such as alignment with business strategy, product development and business model considerations, and promotion of open source education.

A. Aligning Enforcement Strategy With Business Strategy

Enforcing intellectual property rights always sounds like a good idea. Unfortunately, the typical cease and desist and litigation strategy has significant pitfalls including requiring vast resources and risking the loss of goodwill with customers, partners and the community. Aligning enforcement strategy with business strategy clarifies which enforcement activities will have maximum impact while minimizing risks. The question is, how do you align these strategies?

Looking at the size and goals of a company is one place to start. Many open source vendors today are relatively small and privately held. These companies prioritize rapid growth, building adoption and proliferating products over converting customers to cash. These companies could reasonably choose to avoid tricky enforcement issues under the theory that any customer, paying or free, in or out of compliance with a license, is one more customer that can be converted to cash sometime in the future.

By contrast, other open source companies are either publicly held, or privately held and on the verge of generating a return on investment. Accumulating customers is not the focus of these companies, but the traditional cease and desist and litigation approaches to enforcement of unauthorized copies could be seen as a quick way to make money for investors.

B. Building Enforcement Success Into Your Product

Enforcement begins with the choices you make as to features to include, the license that applies and the business model. For example, DRM (digital rights management) is a dirty word in the open source community, but it can be a valuable tool in enforcement. Companies with a subscription model can use DRM tools, such as a digital fingerprint, to track subscription periods and to confirm whether particular installations are eligible for support and services.

Licenses make a difference in enforcement too. The popularity of GPLv2 is due in large part to its viral terms, which make the mere threat of enforcement enough to drive compliance, particularly with traditional proprietary software companies. GPLv3 offers an even more intriguing range of enforcement options because it allows licensors to easily apply their own conditions for enforcement opportunities.

A company's chosen open source business model makes a difference too. As mentioned above, companies with a subscription model often worry about enforcement because they want to ensure the services and tools they provide are only available to licensed servers. By contrast, companies with an open core model might not be as concerned with unauthorized availability of the software because they make their money by enabling additional features or functionality.

C. Safety in Numbers

One of the most successful enforcement strategies adopted by proprietary software companies could be a model for open source enforcement strategies too. Many of the leading software companies are members of the Business Software Alliance (BSA), an organization that not only organizes anti-piracy and license compliance programs, but also promotes public policy initiatives including intellectual property and development policies. Possibly the greatest advantage of the BSA is that it allows licensors to pursue enforcement strategies collectively, thus allowing enforcement resources to be pooled while avoiding the risk of individual members losing goodwill. The uniformity in approach also creates predictability in license rights and when enforcement is appropriate.

Open source companies could come together to form their own Open Source Software Alliance (OSSA) and realize the same benefits. Ideally, the proposed OSSA could also partner with the Free Software Foundation to add credibility to the positions it takes and bridge the gap between the open source and free software movements. Unfortunately, the gap between open source and free software is likely too big for the FSF to endorse an organization like the OSSA.

These are just a handful of ideas that I hope will help open source companies break out of the "cease and desist" box to realize that enforcement means so much more than adversarial confrontations and litigation.

April Roundup

A number of news items grabbed my attention this month ... for instance, I vaguely recall a story about one big tech company buying another, but the names escape me. In any case, a number of interesting open source blog postings appeared in April. Here is a sampling of posts falling in two basic categories:

Open Source as a Hobby and Business

• Connecting Hobby and Business in Open Source - How are some businesses able to harness the passion of developers for their open source hobby to create open source success? Dana Blankenhorn illustrates that it takes more than good software and a good business model to create a successful open source business.
  

• Open Source Business Strategy: About the Open Source Whole Product Concept - Roberto Galoppini explores the idea that successful commercialization of open source requires delivering a fully realized product. In my opinion, productization is the critical element differentiating an interesting project that is viewed as a fun toy from an enterprise class tool that customers are willing to pay for.

Open Source in Government

• Five Ideas to Get FOSS Into Governments - Sun's open source officer, Simon Phipps [Disclosure: I work for Sun], offer six (in spite of the blog title's reference to five) concrete ideas to speed government adoption and use of open source. Because of their size and influence (both as exemplary users of open source, and through their ability to impose procurement and usage rules), governments are important players in the open source movement. Broader government adoption of open source would be a great benefit to the industry as a whole.
  

• Participatory Legislation: the Italian Democratic Party Launches a Wiki - This blog post describes two cases of governments taking first steps towards applying open source principle to the legislative process. Specifically, the post mentions efforts in New Zealand and Italy to allow the public more direct input into writing laws. These small steps mark what I believe will result in a more participatory governing process that will ultimately lead to more accountable government.
  

• Election Industry Trade Group Issues Report Examining Open Source Voting - The Election Technology Council, a trade group US voting system vendors, recently published a report concluding that open source and proprietary software products must be treated differently for purposes of governments making decisions about voting technology citing complexity in management and lack of accountability in traditional open source projects among other things. My view is that the Election Technology Council is perpetuating the type of fear, uncertainty and doubt we typically see in industries not prepared for competition from open source vendors. While it is true that the integrity of the voting system requires certain minimum standards including security assurances, open source software can surely satisfy those needs.

Other hot topics included the importance of channel sales in growing the scope of the open source industry, and deeper discussion of the status of the emerging cloud industry , and what type of open source license is appropriate for cloud technology.

Prize Fighing in the Clouds

Ding! Ding! Welcome to the main event! In one corner, we have cloud computing heavyweights Amazon, Microsoft, Google and Salesforce ... In the other corner, we collection of cloud computing heavyweight contender including IBM, Sun AT&T, Cisco, EMC and VMware. Let's get ready to rumble!

The rapid emergence of clouds as the next big thing in computing, and the positions being staked out by the participants look more like a prize fight than the garden variety competition we are used to seeing in technology development. Battle lines have been drawn based on the recent release of the Open Cloud Manifesto - a position paper created by a collection of technology companies (IBM and the other contenders above) to advocate for open standards that will lead to open clouds.

Critics of the Manifesto, Microsoft in particular, claim that it was created without soliciting industry-wide input in an open manner, and openness demands the inclusion of all interested parties. In spite of the controversy over the Manifesto, all technology providers would argue that standardization is good for the development of an industry around clouds. Some of the opposing parties have already agreed to "bury the hatchet" in favor of interoperability. It is inevitable that standardization will occur, and the only question is how long it will take, and whether it will occur through a voluntary Manifesto or similar community agreement, through alliances between technology companies , or through a de facto standard resulting from a dominant industry entity. In any case, we are only in the first round of a 15 round marathon.

All the focus on the Manifesto and standardization misses an important broader point. The discussion calls into question how competitive and effective open source can be in an emerging industry. It's clear that open source can create massive disruption in existing proprietary industries, and that closed business models are best at protecting legacy revenue streams from closed source businesses. As Matt Asay recent noted, companies have every incentive to maximize the lock-in of their customers and will be wary of committing to an open standard at the expense of lock-in (the Prisoner's Dilemma). At the same time, it's not clear that being open even solves the problems of vendor lock-in.

Regardless of whether we believe that open source and standardization are the best models for disruption or prevention of lock-in, the cloud industry should embrace open source to promote quality. The fact is that open source produces quality software, and it is quality that will provide the knock-out punch in this cloud battle. As a result, my recommendation is for companies in the cloud space to start with an open platform if they are newcomers, and existing players should move to a more open platform in these early days of the industry. After all, even big punchers like Amazon only address a portion of the spectrum of technologies needed to fully realize the potential of the cloud. This way we can speed the move to standardization and avoid the problems of proprietary lock-in that we have see all to often over the life of the computer industry.

Keep it a clean fight, no hitting below the belt, and may the best fighter(s) win.

Highlights of OSBC 2009 - Day 1

Yesterday I attended the first day of the 2009 Open Source Business Conference in San Francisco. This is the premiere event for anyone interested in open source and has separate tracks specifically appealing to Executives and Managers, Developers, Venture Capitalists, and Attorneys. This is a great place to not only see and hear all the "rock stars" of the open source industry, but you can even meet and talk to them in person ... it's like having a backstage pass, but without the groupies.

I attended several interesting sessions on the first day and some of the key points that stood out to me are below. I also participated in a session on managing open source within an organization with an excellent panel: Virginia Tsai Badenhope from Smithline Jha law firm, Joyce Chow from Apple, Angela Ziegenhorn from Symantec, and Duane Valz from Yahoo! I'll have a separate post on that in the next couple of days.

-New Meaning of "risk" in open source. In the past, open source discussions focused (often unnecessarily) on risk, specifically referring to the perceived risk with the quality of the software. Now, however, the stronger view is that NOT using open source software is risky... risky in the sense that IT managers might lose their jobs if they don't cut costs. (Matt Asay noted this in his keynote opening remarks.) The survey data presented by Michael Skok of North Bridge Venture Partners backed this up with unfamiliarity with open source ranking much higher as a barrier to adoption than legal concerns.

-Don't lose focus on innovation and quality. A good deal of discussion occurred around whether the current economic difficulties benefit open source. The majority view is that yes, indeed, those in need of software solutions are more likely to look to open source as a free or low cost alternative to proprietary software.

However, several presenters also pointed out that open source has always stood for more than cost savings and the open source community has worked hard to demonstrate the pace of innovation and quality of open source software. Marten Mickos, SVP of the Databased Group at Sun (at least for a little longer) made this point very well in the panel discussion portion of the keynote. During the Marketing in Open Source presentation moderated by Sun's Zack Urlocker, Greg Armanini from Zimbra (Yahoo!) emphasized this point saying that we don't want to lose the check on the innovation checkbox in procurements. It would be a shame to lose that message in the marketing push around low cost solutions. John Roberts, CEO of SugarCRM also said that the ability of customers to maintain control over the software and avoid lockin is critical.

-Issues of open source "purity" are not longer important. Creating a business with open source software is well accepted and must not be seen as a contradiction to open source values. This evident in the mainstreaming of open source in the software industry, the breadth and quality of open source solutions, and the fact that litigation of open source issues is becoming more common.

-The next frontier for open source is enterprise IT. This is where the big money is for the open source industry, and it is evidence of the legitimacy and broad acceptance of open source by even the most conservative customers. (Note - Jonathan Schwartz, CEO of Sun Microsystems (Disclosure: I work for Sun), said Sun's data shows that ALL of the Fortune 500 companies use open source.)

-Disruption is great for business, but don't disrupt adoption. Marten Mickos and other panelists had commented that a good business strategy is to target any industry that has not yet been disrupted by open source. Michael Skok of North Bridge Venture Partners further clarified this notion by emphasizing that adoption by users must still be easy. In other words, do not disrupt the ability of end users to obtain and use the product.

I found all of these points useful in further clarifying how best to implement open source as a business strategy and I hope you do too.

Making Money with Open Source

The question of whether a business can make money with open source software has most often been answered with an uninformed "no," at least until recently. As open source becomes mainstream and an integral part of the software industry, the common answer to this question is becoming, "yes, but I'm not exactly sure how." This was the topic that Joyce Chow (Apple Inc.) and I addressed in our presentation on Open Source Business Models at the Practicing Law Institutes seminar on Open Source Software in San Francisco earlier this month. Here is a brief summary of the highlights of our presentation.

To start, calling open source a "business model" is not accepted by everyone. Open source is clearly a development and license model, but it does not directly derive revenue. It is best viewed as a tool or strategy that can be used to generate revenue, much like any other business strategy. For the sake of simplicity, this post will treat use of open source in any meaningful way as a strategy that is an open source business model.

Open source business models are best considered as a spectrum of strategies using open source, from a 100% open source software model, to a pure proprietary model (though some might argue that "proprietary" is not the opposite of "open source" ... we will treat it here as the other end of the spectrum because it indicates that revenue is generated with no reliance on open source software). Along the spectrum are various combinations of development, licensing, services and other strategies with different triggers for generating revenue. Some of the most well know, starting from pure open source and moving to pure proprietary, are:

• 100% Pure Open Source - This is not a business model in the sense that entities in this category are typically non-profit entities that collect donations for the purpose of furthering the goals of their chosen open source project rather than profit-seeking. Entities like the Apache Foundation and Free Software Foundation fall into this category.
  

• Open Source as a Lure - Companies like Google and Sun Microsystems (my employer) employ this strategy. Google hosts its own open source code repository and open source applications (such as Android) optimized to its search results framework to generate higher web traffic and resulting ad revenue from developers and application users. Sun optimizes its hardware-dependent open source applications (such as Open Storage, xVM Ops Center, and MySQL database software) so they work extremely well on Sun's high-performance servers. In both cases, revenue is not derived from the open source software directly, but rather from the increased sales of related activities and materials.

• Aggregation and Services - These are really two separate models, but aggregation is not a viable business opportunity on its own and the two models are well matched. In consideration of seemingly infinite amount the open source code available on sites like Sourceforge or Launchpad, pulling related code together into a fully functioning application is a real value. Red Hat's ability to compose Linux from multiple sources with many copyright holders into an enterprise-friendly, reliable operating system is a perfect example. Providing services (including training, support, maintenance and professional consulting) is a very compelling revenue opportunity. Services are a natural addition to aggregation because of the expertise and knowledge gained in the process of aggregating code and ensuring it works properly. Red Hat also enhances its offering by providing a full spectrum of services to customers.

• Embedded Use - Open source software licensed as embedded components is another viable business model, but the revenue generating potential lies in the use of a dual-license model rather than the value of the open source software itself. An embedded component licensed under a permissive open source license (e.g., BSD, MIT, Apache, etc.) will not generate revenue because users have no incentive to pay for the freely available software with broad license rights. By contrast, an embedded component licensed under a restrictive or viral license (e.g., GPL) forces a potential OEM or system integrator to purchase a commercial license to the same software. Of course, this requires full ownership (or at least broad license rights) of all rights in the software. The MySQL database is an example of this model.

• Tiered Product - Tiered open source software offerings include two basic types of models. First, an open source offering could be an entry level version of a product, much like the evaluation or "light" version of a proprietary product, with a more fully-featured version available for a fee. However, the open source vendor has an advantage over the typical proprietary evaluation product because the source code is freely available for modification and customization. Funambol's open source and carrier grade editions illustrate this type of tiered product well. Second, an open source offering could be fully featured with no separate enterprise version of the product, and the open source vendor can compel purchase of a commercial license by offering additional tools or add-ons that make the open source software more valuable either by making it easier to use or enhancing its efficiency. In both cases, we come closer to a pure proprietary model in that revenue is generated by the value of the software itself either alone or in conjunction with other software or services.

• Incidental Open Source - Many of the most useful and reliable software tools, components and subroutines are available under open source licenses. As a result, virtually all software developed and distributed today contains open source software to save time and resources. However, the mere inclusion of open source components in a software product does not mean that a software vendor is engaged in the open source business. As a result, the incidental use of open source should not be seen as a means of generating revenue through the use of open source.

• Pure Proprietary - The name says it all. Distribution of software containing no open source components, and with no connection to other open source software is in no way an open source business model. This model was common 10 - 15 years ago with most software vendors such as Microsoft, Oracle and others, though all of these vendors not use open source materials at least on an incidental basis and are actively participating in other open source business models.

This is not an exhaustive list by any means. Each business entity must consider its goals, strengths, and the multitude of variables of each development, license, go-to-market element and revenue trigger for each open source strategy to ensure it finds the best point along the spectrum for it's unique needs. Moreover, these business models should be combined to achieve maximum effectiveness.

Jump On the Bandwagon

Last week I attended a very informative CLE on Open Source Software 2008: Benefits, Risks and Challenges for Software Users, Developers and Investors, and was lucky enough to join Joyce Chow from Apple in presenting a session on Open Source Business Models. What made the seminar so useful was the breadth of topics it covered … everything from the nuts and bolts of open source licenses, to the technical details of linking and derivative works, and even ethics in open source (presented in part in a very entertaining fashion by Dave Marr, one of my colleagues at Sun). Bob Pierce, a former colleague of mine at Adobe, provides an informative review of the presentations on his blog.

In talking with other presenters and attendees, it became clear that the law surrounding open source software has reached a milestone. The skills needed to support an open source software business are no longer practiced by a handful of attorneys, and instead are skills that every attorney should have. Examples of the importance of understanding open source appear almost daily:

• Current economic troubles make the low cost and convenience of open source software particularly attractive to IT departments and businesses of all sizes.
  

• Cisco has been sued by the FSF and SFLC for failure to comply with the GPL - having a effective open source management process, knowing how to comply with open source licenses and ensuring such compliance occurs is critical to virtually all software businesses.

• The Open Inventions Network is pooling patents and prior art to protect Linux and the open source community from patent lawsuits - the open source community controls intellectual property rights for the benefit of the community.

• Gartner research shows that 85% of enterprises currently use open source software and the other 15% will within the next 12 months - even if you think your client doesn't use open source, it almost certainly does.

These are but a handful of examples, but searching everything from broadly circulated business periodicals to the most narrowly pointed open source geek blog will yield a virtually limitless supply of information on the growing importance of the open source model.

In short, this is the time to jump on the band wagon or be prepared to be left behind.

Relationships Matter

After a couple of postings focused on the state of the open source business, I would like to pick up the theme of earlier postings concerning fundamental legal considerations for open source businesses.

Good businesses are built on good relationships ... relationships with customers, partners, and employees. Open source companies have another important relationship to consider ... the community. In the spirit of the old adage "good fences make good neighbors," contracts, instead of wood or brick, help keep good relationships from going bad. While contracts are well accepted in customer, partner and employee relationships, they are not as effective in a community relationship. Whether through contracts or other means, open source companies must address the unique demands they face in balancing their profit motives with open source ideals.

The most fundamental of all business relationships is between vendor and customer, and standardized contracts are a well-accepted means of describing the expectations of these parties. While the commercial contracts of open source companies are generally the same as for proprietary companies, certain virtues of the open source development model allow open source companies to sidestep or minimize the many traditional commercial software contract clauses. For example, the availability of free software before purchase often makes customers less worried about issues like evaluation licenses, performance and ownership warranties, broad indemnification rights, and licensor liability obligations.

Partner relationships of all sorts (marketing, distribution, inbound licensing, joint development, etc.) also are commonplace in the open source business and typically addressed through standardized contracts. Because partners, like customers, can get the value of open source software without paying for it, open source companies must present additional value (such as marketing or referral benefits) compelling enough to entice partners to enter into agreements that provide adequate protection. Specific clauses might include prohibitions on forking the code or creating an unauthorized solution, or an obligation that a partner's solution must always be available under an open source license.

Employees are the most important assets of any technology business. As a result, employment agreements, related agreements governing ownership of inventions created by employees, and confidentiality agreements are regularly used. The traditional templates for these types of agreements are, however, at odds with the open source ideals of community participation because employees of open source companies are also members of the community. As a result, open source companies must challenge themselves to rethink the traditional scope of employer ownership rights and level of oversight in employee participation in outside projects and implement appropriate legal agreements and company policies. This type of flexible approach also has the benefit of being a great tool for recruiting potential employees from the community.

A community relationship is different than the other relationships above in that an open source company can't rely on a contract to set expectations ... the community has no single point of contact that can enter into contracts, and the relationship is based on a constantly evolving application of open source principles as well as trust established over time. However, a company's contributor agreement, the one important community-oriented legal agreement, should reflect community ideals such as by granting contributors joint ownership or broad usage right in contributed code. The community also looks to a company's position on patents as an indication of open source friendliness so a carefully considered patent policy is important see my previous post on patents for more on that). In general, open source companies need to establish a clear business strategy that incorporates open source principles, and be able to clearly and tactfully articulate why the community should accept a particular business decision even when it might conflict with open source ideals. Decisions as to when and how to enforce violations of open source licenses, or when to introduce closed source code into an open source solution are among of the most difficult for the community to accept, but a strong community relationship will help.

Each of these 4 relationships are vital to the success of an open source business. While contracts can play a primary role in open source companies and their customers, partners and employees being "good neighbors," the community relationship, by its very nature, is less predictable and requires trust along with the proper balance between sincerity in honoring open source principles and conviction on business strategies that might be seen as contradicting open source values.