OSBC 2010 - Highlights - Day 2

Day 2 of the 2010 OSBC again had several interesting sessions, including some insightful legal sessions.

A. Maximizing the Value of an Open Source Business

If you are looking for a nuts and bolts "how to" session on building an open source business from the ground up, this is the type of session you need to attend. Benchmark Capital's Rob Beardon made it through only half his presentation on "Tactics and Metrics for Scaling an Open Source Business" because of the volume of audience participation. Beardon, along with assistance from Zack Urlocker (former MySQL VP) and other open source veterans in the audience, sketched the following blueprint:

Guiding Principle: the value of an open source business is directly proportional to the size of the community and the company's ability to influence and monetize it.

Key Areas:

1. Foundation - every open source business must start with the following attributes to be successful:

• Technology - must add value by solving a customer's problem
  
• Community - must attract the best in the field with the promise of innovation and disruption
  
• Business Model - choose between the "owner/builder" (innovation) and packager/distributor (commoditization) models
  

2. Tactics - position for rapid scalability with viral awareness, then generating adoption, THEN sales

3. Metrics - traditional metrics are not relevant. State of the art is to measure web traffic, customer acquisition percentage and lead nurturing tools

A successful open source business will be able to create a "closed loop demand management" workflow that fuels growth. It is important to note that this methodology is not much different that standard "Entrepreneur 101" tactics, but is highly tuned to the particular needs of an open source business with a goal of a liquidation event for its VC vendors.

B. Legal Matters in Open Source
I attended several legal sessions on Day 2 as well. I won't recount all the details of the discussions, but here are some of the most interesting points:

1. GPL Enforcement. Karen Sandler, General Counsel of the Software Freedom Law Center, gave a thorough review of common open source software license incompatibility. Of note was her helpful clarification on the requirements of the GPL (Sec. 3 of v2, Sec. 6 of v3). In particular, she confirmed that the common practice of including only a download link to source code is not enough to satisfy the "written offer" requirement of the GPL. However, she also emphasized that a download link might be enough for all practical purposes as long as it is relatively easy to find the source code. This is true at least for the SFLC, which is more interested in software freedom than litigation. This is likely a relief for many developers that try their best to comply, even when the details often elude them.

2. Best Practices. Virginia Tsai Badenhope of Big Fix provided some great pointers in her session on how to handle open source within an organization. Her comprehensive checklist consisted of 5 categories:

• Inventory and assess usage of open source
• Comply with terms of open source licenses
• Implement an open source policy to whatever degree necessary to meet the business needs
• Update outbound licenses to ensure they reflect the use of open source
• Update inbound licenses to ensure suppliers make proper representations and warranties for open source

The details under each of these categories will vary depending on the company and particular circumstances, but it is critical to have a set of procedures in place to ensure nothing slips through the cracks.

3. Affero GPL. In his session on Open Source Litigation, Catalin Cosovanu from Wilson Sonsini primarily discussed litigation on enforcement of the GPLv2, but audience questions quickly transformed the discussion into the legalities of the Affero GPLv3. For example, the lack of definitive caselaw on the meaning of "distribution" under the traditional v2 means that the more comprehensive notion of "conveyance" under the could trigger more legal claims and lead to more uncertainty, particularly in the Affero network context. The network terms of Affero also make the notion of "corresponding source code" more ambiguous, particularly in a cloud environment. Finally, even simple questions like "where should the written offer appear?" are not as simple in the Affero context.

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

Obligatory End of Year Post - 2009

Yes, I know it's already 2010, but this post is still my official "end of 2009" post. I've included some highlights from the posts on this blog along with my choice of top 5 open source stories and themes of the year. Please add your comments on what you think are the top stories for 2009.

Reflections on This Blog

The readership of this blog grew substantial in 2009 and I am very thankful for that. Visitors from 30 states, 29 countries and 6 continents came to this blog with the top 3 countries being the United States, Brazil and the United Kingdom. I have to admit, the prominence of Brazil surprised me. Visitors seemed to be attracted to a wide variety of subjects, but management of open source within a company and GPL enforcement seemed to be the favorites. Here are top 5 most visited posts of the year, beginning with the most popular:

1. In-House Counsel - Managing Open Source
2. FSF Motives in the Cisco Case
3. Obligatory End of Year Blog Post (2008) (emphasis on the FSF-Cisco case)
4. Highlights of the Open Source Business Conference - Day 1
5. Show Me the Money at OSCON - Venture Capital and Open Source

Top 5 Open Source Stories

Shifting to the industry as a whole, the top stories of 2009 also illustrated the importance of in-house open source management and GPL enforcement among many other themes. Below, I have provided my list of the top 5 stories and themes of the year:

1. Oracle Acquisition of Sun Microsystems - As a Sun employee, I have a deep personal interest in this deal, but it is also a significant event for the business of open source (not to mention the software and hardware business too), particularly the EU's competition investigation of the MySQL business. The deal could be characterized as a definitive affirmation of the importance of open source in that even companies whose success is perceived to rely on the traditional proprietary software model (such as Oracle), see open source as an important strategic element. Questions on the MySQL aspect of the deal even prompted industry heavyweights like Eben Moglen, founding Director of the Software Freedom Law Center, to explore the impact of the GPL.

2. GPL Enforcement Actions - The relative popularity of my blog posts on the Cisco-Free Software Foundation litigation (which has since settled) is one indication that GPL enforcement is a hot topic. This trend gained momentum throughout 2009 and will likely continue to do so in 2010. Examples include the Software Freedom Law Center's December announcement of litigation against Best Buy, Samsung, Westinghouse and 11 other entities on behalf of the owners of BusyBox, and a French court case in which users of GPL software got a ruling affirming their right to receive the source code to that software and modifications.

3. Microsoft Release of GPL Code - Few companies raise the ire of the open source community more than Microsoft. That's why open source proponents were pleased, and surprised, to see hear Microsoft announce that it would contribute driver code to the Linux kernel. It is not clear whether Microsoft's decision was based on necessity in the face of a potential GPL violation, or a strategic move to enhance compatibility with Linux. Regardless of the motive, Microsoft's actions indicate that even the most sophisticated of companies must pay close attention to their use of open source and honor the provisions of open source licenses. This is especially true in light of the recent enforcement activities discussed in the previous paragraph.

4. US Government Commitment to Open Source - The principles of technology neutrality have long been recognized in the European Union to the benefit of open source software usage by European governments. The United States federal government has not been as accommodating of open source, but at least two events in 2009 indicate a possible change in US attitudes. The US Department of Defense revised its guidelines on use of open source software in October to essentially give it a procurement preference over proprietary software when all else is equal. In addition, it appears that the Obama Administration is actively looking for ways to bring the benefits of open source to government operations.

5. Red Hat's 10 Year IPO Anniversary - Red Hat is commonly viewed as the most successful pure open source company with its status as a Fortune 500 company with a market cap of almost $6 billion and generating over $700 million in revenue in 2009. As such, it's longevity and success are significant barometers on the health of the open source business as a whole. With a lingering cloud over the economy, and the relatively slow growth trajectory of most open source companies, it seem unlikely that we will see any open source IPOs in 2010.

Please post your thoughts on the most important open source events of 2009. I wish the best of success to all of us in this corner of the world we call "open source."

[Note: The "Top 5" portion of this post was updated after the original post to make non-substantive changes for purposes of clarification and adding more reference links.]

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.

Not Your Ordinary Communities and Contributions

Few terms are more central to the free and open source ("FOSS") movement than "community" and "contribution." The common definitions of these terms are:

Community: a unified body of individuals as - a state or commonwealth; the people with common interests living in a particular area; an interacting population of various kinds of individual in a common location; a group of people with a common characteristic or interest living together within a larger society; a group linked by common policy; a body of persons or nations having a common history or common social, economic, and political interests; a body of persons of common and especially professional interests scattered through a larger society.

Contribution: a payment (as a levy or tax) imposed by military, civil, or ecclesiastical authorities usually for a special or extraordinary purpose; the act of contributing; the thing contributed

But these terms mean so much more in the context of FOSS. Anyone who sponsors, participates in or contributes to a FOSS project needs to understand not only the importance of these terms, but also how their meaning has changed over time.

Starting Point
The community is the core of any FOSS project. Consistent with the common definition, a FOSS community has traditionally been a self-defining group of people and organizations that share the common value of exchanging ideas and intellectual property in the pursuit of creating the highest quality software using an open development model. Until recently, there has been little need to define the community in any greater detail because membership was open to all and carried no obligation to participate, which resulted in the attraction of like-minded participants.

FOSS contributions have traditionally come from individual developers and companies alike. They typically included any materials submitted to the project under a standard set of terms commonly accepted and understood by the community. Again, because the community traditionally shared common values, there has been little confusion as to what constitutes a contribution and what the receiving FOSS project could do with it.

Where Are We Now?
With the growth of the open source movement, the concept of free software has taken on competitive and commercial traits, which has impacted the meaning of "community" and "contribution." Those who sponsor or participate in FOSS projects need to take note of the changes.

In the case of communities, we can no longer assume that the FOSS project sponsor and participants share common values. At a minimum, sponsors and participants might be divided between those that advocate for pure free software principles, and those that use the community for purely strategic purposes in support of a commercial advantage.

The nature of contributions has also changed. Some FOSS project participants might contribute for the purpose of advertising an alternative product or fork, or to incorporate code allowing for easier integration with a commercial product. In addition, the traditional "anything submitted" contribution model, which promoted free exchange of ideas and is the most beneficial to the community as a whole, is less relevant. More recent contribution models include the option for contributors to declare which of their submitted materials are deemed not to be contributions. The legal terms that apply to contributions are sometimes also subject to the influence of commercialization by being narrowly focused on the sponsor's objectives to the detriment of the community's needs as a whole.

How Should FOSS Project Sponsors Respond?
FOSS project sponsors (whether non-commercial or commercial) should carefully consider how to respond to this evolution in the meanings of "community" and "contribution". They should spend more time defining their FOSS goals, more closely monitor FOSS activities and contributions, and implement measures that will further their goals and ensure that the appropriate elements of the community work in their favor.

Specific actions for consideration by FOSS project sponsors include:

• Posting a definition of goals for content, community and participation. This might include a statement of purpose for the project, a definition of community values, and a code of conduct for participants.
  

• Creating separate discussion boards and mail-lists for contributions in support of the project, general discussion about the project without contribution, and discussion of other projects or any other matters not related to the sponsored project.

• Monitoring contributions and discussions to ensure that they are posted to the proper boards and lists, and to ensure that contributions do not contradict the applicable participation model and community values.

• Avoiding alienation of participants even if they appear to contradict community values. For example, even when a project participant uses a project discussion board to promote its own commercial activity, the sponsor should first decide whether to object to that practice. If it chooses to object, it should do so in a way thatfosters inclusion and participation in a rational, pro-community manner, while minimizing the perception that the sponsor is hindering project discussion or participation.

• Treating conditional contributions (i.e., contributions made under terms other than the sponsor's standard terms) as invitations for negotiation to be handled in the same manner as other commercial inbound licenses. Sponsors should not grant exceptions to conditional contributions because that risks contradicting community expectations and undermining the purpose of the project.
  

• Weighing a number of factors when faced with a choice between accepting a conditional contribution or not obtaining any rights to the contribution at all. Specific considerations include: the value of the potential contribution; the scope of rights offered; consistency with the sponsor's commercial strategy; consistency with community values and expectations; perception in the community; and consistency with free software principles. An assessment of these factors could lead to a number of outcomes from a decision that the contribution will not be part of the project, to a decision by the sponsor and contributor to enter into a commercial relationship.

Judgement Day for Commercial Open Source ... How Did I Miss It?

In a recent Business Week online article, Peter Yared, founder and CEO of San Francisco startup Transpond, describes "The Failure of Commercial Open Source Software". While Yared makes a case that the commercial open source software business hasn't lived up to the hype that it will "change the world," he reaches too far in declaring its failure. A more appropriate conclusion would be to recognize that commercial open source only recently reached broad acceptance as a business strategy and is on a strong growth trajectory. We must measure its success in that context.

Yared's arguments are diverse, but they fail to account for important indicators of open source success:

1. Minimal number of liquidity events for open source businesses. As identified by one of the commenters, several prominent examples of open source liquidation events are missing from Yared's list, including Zimbra, Trolltech and Sleepycat. In addition, the article uses 2003 as a benchmark year, allowing only 6 years to measure exit success. According to a September 2008 MoneyTree Report by PricewaterhouseCoopers and the National Venture Capital Association, the average seed-financing to exit life cycle of a venture-backed company is 8.6 years. As a result, any conclusions about the success or failure of open source businesses, many of which were started within the last 6 years, are premature at best.

2. Continued success of proprietary vendors. Not only is this irrelevant to measurement of open source success, but it fails to acknowledge the growing role of open source in proprietary companies. Companies like IBM, Microsoft, Adobe and Oracle, are milking revenue from their established proprietary business models while they also distribute open source software to generate revenue, influence development communities and drive broader adoption. In addition, measuring open source displacement of proprietary software misses the point, particularly in the short 6 year time frame here. Open source targets adoption opportunities through grass roots growth, which takes longer (but is less expensive) than the hard-hitting direct sales approach of proprietary companies.

3. Success is limited to commodity businesses; Enterprises are not likely to add open source businesses to their lists of approved vendors. These assertions fail to take into account the growing reach of open source throughout the software industry. While it is true that many of the more successful open source companies to date have been in the infrastructure and commodity business, we are beginning to see significant adoption of enterprise and end user open source applications (such as Alfresco, SugarCRM and others). Matt Asay further amplifies the limitations of Yared's assertion by identifying SpringSource as an example of an open source company that innovates and targets enterprise-friendly software development, which is outside the category of traditional commodity software.

4. Cost savings of open source are overstated. This contradicts the conventional wisdom that cost savings is one of the primary reasons companies adopt open source. In an April 2009 Forrester report, 75% of survey respondents said "Reduced IT costs" are critical or very important in their decision to use open source software. In addition, a panel of venture capitalists at OSCON proposed that open source companies can typically save up to 30% in sales and marketing costs as compared to proprietary companies, which leads to quicker profitability, quicker exits and happier investors. Even so, the article is likely correct with respect to mature open source businesses. In two March 2009 Open Sources blog posts, Savio Rodrigues compares the income statement of Red Hat to those of Microsoft and Tibco. In both cases, he concludes it is unlikely that mature open source vendors will be more capital efficient than commercial vendors.

5. SaaS will overtake open source. The general trend away from installed software applications to SaaS and cloud systems is undeniable. As Matt Asay explained on his Open Road blog in May, cloud computing is the natural conclusion of open source, because cloud computing is the ultimate expression of the open source principle that services, rather than the software supported by such services, are the most valuable component of a product offering. But SaaS and cloud business models are having significant growing pains of their own. Customers are concerned about the portability of data, freedom from vendor lock-in, security and standardization and other matters that must be resolved before achieving broader commercial acceptance. (It's a bit ironic that open source software might actually be the best way to address these concerns.) SaaS and cloud businesses appear to be subject to at least the same level of skepticism as open source. As a result, it seems unlikely that SaaS and cloud business models will replace the open source software business in the near future.

6. Open source benefits do not lead to monetary gain. Yared observes that his company uses open source but typically does not pay for it other than contributing code back to projects. This is a common practice and it implies an impending failure of commercial open source. Yared concludes that these factors do "not mean every successful open source project can sustain a commercial company, especially when they are delivering complicated applications rather than simple plumbing." No doubt this is true, but it is also true of proprietary business models and does not lead to the conclusion that commercial open source has failed.

It is fair to question when open source will become as reliable an investment as other technology businesses. In this regard, Yared's article raises some important points for discussion. However, rumors of the failure of open source business models are greatly exaggerated, and any pronouncement on the success or failure of open source is premature.

Show Me the Money at OSCON - Venture Capital and Open Source

To my pleasant surprise, Mark Radcliffe (notable open source attorney) announced last week on his blog that his law firm, DLA Piper, would host an open source legal track to run in parallel to the OSCON trade show in San Jose this week. The schedule included a diverse mix of topics that pushed the boundaries of typical legal presentations on the issue of open source. I found the talk on venture capital and open source the most interesting. The panel consisted of 3 seasoned venture capitalists (Josh Stein of Draper Fisher & Jurvetson, Mark Gorenberg of Hummer Winblad, and Vivek Mehra of August Capital) and an experienced open source attorney (Vicky Lee of DLA Piper).

Venture capital is a hot topic of discussion. Several tech publications and blogs are reporting, based on a report issued earlier this week by PricewaterhouseCoopers and the National Venture Capital Association, that venture investment has shrunk to pre-tech-bubble levels, the slow economy is putting a damper on venture capital, and venture funding in the tech industry is down over 50% year-over-year from 2008 to 2009. At the same time, however, the tech sector seems to be attracting more investment in recent months. The panelists at the OSCON session on "Understanding Venture Capital Investments in Open source Projects" seemed to have an enthusiastic view of investment in open source companies.

The panel described several elements that go into their determination of what is a good open source investment. The most fundamental points, however, came during the second session by Larry Augustin on "Choosing a License: Ensuring that Your Intellectual Property Strategy Matches Your Goals". Augustin emphasized that: (1) open source is only a tool and an open source business model alone is not enough to guarantee success or to warrant funding by venture capital firms; and (2) quality is critical to ensuring customers want to purchase a product regardless of whether it is open source or not.

Beyond these fundamental points, the panel discussed the following elements:

1. Successful Business Model

• Copyright Ownership - This is an immense benefit because it provides maximum flexibility as a company grows.

• Clear Distribution Rights - Ownership of all the copyrights in a product eliminates uncertainty about distribution rights. When third-party components are involved, however, clarity on rights is important.

• Disruption, Platform and Infrastructure - Venture investments are most desirable in quality companies that focus on specific areas: (1) market disruptors in an existing industry; (2) technology that can become a platform; and (3) technology that focuses on infrastructure (because it is most likely to help companies reduce costs).
  

• Free is a Negative - Serious customers do not find as much value in free products as products that they must pay for (Larry Augustin emphasized this point in the second session).

• Support and Services - Companies that do not own their code and generate revenue only from services are susceptible to competitors.

• Open Core - This is the current popular favorite of open source business models and it has a proven record of generating revenue, which is attractive to venture capitalists for obvious reasons.

• Community - Open source products that spring from existing communities or that are developed in parallel with newly created communities can both be successful, but they present distinct tradeoffs. Existing communities provide an available user base that drives quick adoption, but the likelihood of multiple contributors complicates the intellectual property ownership issues.

2. Benefits to Venture Capital Investors

• Lower Cost - While the first wave of financing is typically the same for open source and proprietary companies, the second wave often results in significant savings, which the panel estimated to be 30% or more. Specifically, the availability of open source software and related ecosystem allow open source companies to spend less on sales and marketing, which greatly reduces operating expenses.

• Quicker Adoption - Because end users always have access to open source software, companies are able to avoid the lengthy proof-of-concept and testing cycles that occur when releasing a product for the first time. The panel felt this could save open source companies up to 2 years of development and testing time.

• Easy to Build a Channel - Open source communities are well suited to perform localization, vertical market and other customization for products, which allows open source companies to enjoy the benefits of channel distribution without devoting sales and other resources.

• Early Revenue and Exit - The lower cost and quicker adoption enjoyed by open source companies mean that these companies are likely to begin generating revenue and profits more quickly, which means that investors are likely to reach an exit opportunity more quickly too.

3. Net Results for Venture Capital Investors: When open source investment opportunities are carefully screened with the business model considerations above in mind, the benefits inherent in open source companies make these types of investments relatively safe for venture capitalists. At a minimum, investors should not view open source companies as being inherently more risky that other startup venture investments.

In closing, the panel indicated that approximately 15% of their holdings are in open source companies. While this is a significant amount of investment, the percentage is likely to grow over time as new software companies arise and existing ones revisit their business models. At the same time, the 85% of holdings that are not in open source companies is a good reminder that a good idea will attract investors because it's a good idea, not because it's open source.