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.

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.

Word Play

Judge Learned Hand, among the most celebrated American jurists, once wrote, "The language of law must not be foreign to the ears of those who are to obey it." Yet, law is very complex. Lawyers are in a never ending quest to express complex thoughts in as simple a way as possible. Words are a lawyer's tools of the trade. Some of the commonly used words are descriptive, some are fanciful, some are latin, and some are beyond explanation.

Here is a short selection of legal terms I have always found interesting -- not necessarily because of their legal import, but sometimes just because I like the way they sound. Also, please take the survey on the right and tell me which of the words on my list is your favorite, and leave a comment if you have others you would like to share.

Caveat Emptor
Meaning: Buyer beware.
Interest Factor: This deserves to be on the list if for no other reason than it played in prominent role in a Brady Bunch episode, no doubt inspiring an entire generation of children to choose a career in law. Aside from the pop culture reference, it is good advice.

Clawback
Meaning: A provision in a financial arrangement that enables the recovery of prior payments. (Clawback is more appropriately categorized as a financial term, but it is directly related to legal documents.)
Interest Factor: Much of the discussion on our current financial crisis revolves around clawbacks on executive compensation, particularly for executives from failed companies or companies receiving government subsidies.

Cramdown
Meaning: A bankruptcy term describing a situation in which a court imposes an involuntary reorganization plan at the expense of some classes of creditors.
Interest Factor: This term immediately caught my attention in bankruptcy class in law school. Not only is it perfectly descriptive of what happens in bankruptcy, I also always though it would make a great name for a rock band.

Disparate Impact
Meaning: A theory of liability in employment discrimination cases that relies on a showing that a protected class of people is wrongly treated differently even though employment policies are applied equally.
Interest Factor: News reports on Judge Sonia Sotomayor, President Obama's Supreme Court nominee, frequently include references to her role in a ruling by a panel of Second Circuit Judges in Ricci v. DeStefano, a case concerning whether a test for hiring firefighters in New Haven, Connecticut had a disparate impact on minorities.

Expressio unius est exclusio alterius
Meaning: The expression of one thing is the exclusion of another.
Interest Factor: This latin phrase is one of the foundational elements of logical thought and has applications well beyond the law. When interpreting contracts, it stands for the important principle that parties agreeing to include a list of items are presumed to have intended to include only those items, and other items must not be inferred. Applying this in a broader context, the more detail one provides, the more exclusive the description. Simple, powerful and true.

Jus Cogens
Meaning: A fundamental principle of international law accepted as a norm. Genocide and slavery are common examples.
Interest Factor: I will always remember the distinctive German accent in which I first heard this term spoken ("juice kookens") . A guest German law lecturer introduced this legal concept to our international law class in law school. While this term is valuable in its recognition that certain principles are almost universally recognized as boundaries of conduct, care should be taken to ensure the term is not mistakenly applied so broadly that it interfere with legitimate discussion and dissent.

Res Ipsa Loquitur
Meaning: A thing that speaks for itself, often abbreviated as "RIL".
Interest Factor: Along with "expressio unius...," this is one of the classic latin terms used in legal writing. The term is most often seen in the context of tort law when the cause of an injury is apparent on its face, but direct evidence is difficult to find.

How does this tie into open source? It doesn't ... at least not directly. However, it is interesting to note that many of the most popular open source licenses avoid the use of traditional legal terms and virtually all avoid latin terms. This is likely due to the fact that developers rather than lawyers wrote the first comprehensive free software licenses (like GPL).

This is just a small sampling of the wonderful world of legal terminology. Please share your favorites!

[Note, the "meanings" above are drawn primarily from the Nolo Press legal glossary, the Law.com dictionary, the FindLaw legal dictionary, the free legal dictionary, and Wikipedia.]

Back to Basics

Open source business models are a hot topic these days. Blogs are filled with in depth discussions on open source topics such as choosing the right license, building a strong community, and deciding which software should be open and which should be closed. This blog is no stranger to open source business models. While it's easy to jump right into the intricacies of open source (for an example of the level of minutia that arises in the open source business model conversation, see this link with a "simple" chart summarizing the different types), the truth is that open source means nothing unless is fits within a good business strategy. That's why I say it's time to get back to basics.

The most basic question for any business is, "how will we make money?" The answer is never as simple as "use open source." In the software industry, like any other business, a good business strategy starts with at least three fundamental elements: developing a product, attracting attention, and delivering value. Open source is simply a new spin on traditional approaches to implementing a good strategy and it can play a role in each of these ares.

Developing a Product: Regardless of whether a software product is open or closed source, it still goes through the same types of development milestones from concept phase to general availability. Throughout this process, the developer must decide how to allocate resources for quality testing, bug fixing and feature inclusion. One of the great virtues of open source as a development model is that it can speed development time and product quality by leveraging the community's input particularly in identifying and fixing bugs, but also in identifying high-priority features.

Attracting Attention: A great product isn't worth much unless people know about it. The mere mention of "open source" attracts attention, which makes it a fantastic marketing tool. The freedom that comes with open source software ... freedom to try it, modify it, play with it ... makes it easy for users to choose your software over the competitors' offerings. Even better, open source freedom includes the freedom to distribute, which means users can deliver your software to even more potential customers.

Delivering Value: Finally, it's not enough to develop a product and attract attention. Ultimately the product must provide users with something valuable... something worth paying for. Having a strong relationship with an open source community means that a software developer has a clear view into what users deem important. The open source development model allows developers to deliver products that address customer needs directly, which makes those products more valuable to users.

Adopting an open source business model is not a guarantee of success, but its disruptive power can complement a traditional business strategy and improve chances for success. For lawyers advising clients on open source strategies, it's very important to avoid the paralysis of legal analysis that comes with open source. Lawyers need to understand the fundamental business strategies of their clients and the industry as a whole. In short, never forget the basics.

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.

Cloud Nitty Gritty

The cloud industry is in the process of defining itself. Experts are organizing seminars and presentations to discuss best practices for the cloud business. This is true for the legal industry too, but the legal issues commonly discussed for clouds are similar to the issues seen in connection with service bureau, outsourcing and software as a service initiatives: Privacy, Security, Ownership, Intellectual Property, Jurisdiction, Applicable Law, Service Levels, Export Compliance. While these issues present unique concerns in a cloud context and are worthy of significant discussion, I would like to focus on a less discussed issue: how open source might be implemented within a cloud computing context.

Two important questions come to mind: (1) When does distribution to a cloud trigger the viral source code disclosure obligations under the GPL?; and (2) What is subject to the viral source code disclosure obligations under the Affero GPL?

1. Distribution to the Cloud

Consider what would happen if a developer creates a proprietary application, incorporates code licensed under GPLv2, and distributes the combined application to a cloud provider. We can narrow the answers down to 3 possibilities: yes, no and maybe. I'm not trying to make a joke ... this circumstance is not well settled from a legal standpoint and each of these answers might be valid.

a. Yes - viral obligations should apply because code distributed to a third-party is a "distribution" for purposes of the GPLv2.

b. No - Using a cloud to host an application is no different than using a leased server to provide end users with access over a network or hiring a service provider to act in the same capacity as the developer itself. In such cases, the cloud provider is nothing more than an extension of the developer itself. While this conclusion makes logical sense, it's not clear whether the Free Software Foundation would agree with the end result.

c. Maybe - Because both the yes and no answers can be legally supported or refuted, it would help to clarify the legal treatment in some way. Because the cloud provider would be the only party with standing to demand source code in this case, one option might be for the cloud provider to add a clause to its service agreement stating that it will not require disclosure of source code for applications submitted for operation on the cloud. The Free Software Foundation and a significant portion of the free software community would likely object to a cloud operator's affirmative refusal to enforce the freedoms provided by theGPL.

I believe "Maybe" is likely the right answer because it makes the most sense from a practical perspective. Operation of GPL-licensed software on a leased server does not interfere with any of the freedoms that the Free Software Foundation intended to promote with the GPL. This argument is strongest when the developer's cloud code is an application that could just as easily be operated on the developer's own requirement. By contrast, the argument is weaker the more the developer's cloud code relies on the infrastructure provided by the cloud operator such as in a "platform as a service" model.

2. Scope of Affero GPL Coverage

While end user interaction with applications licensed under GPL and hosted on a cloud do not trigger any source code disclosure obligations, use of the Affero GPL code instead of GPL leads to a different result. Such end user interaction occurs over a network, which constitutes distribution for purposes of theGPL. Clearly, the developer application containing AGPL code would need to be available for disclosure on request in that case.

One of the advantages of the cloud for developers is that cloud providers offer much of the software and hardware infrastructure needed to run developer applications. Consider whether any aspects of the cloud code itself should also be subject to the AGPL's code disclosure requirement. The "Maybe" answer above likely applies here as well, but for different reasons. Cloud components that are integrated with developer applications such that the cloud component and developer application are deemed a derivative or a work based on the developer application would also be subject to theAGPL's viral source code disclosure obligation. This is similar to the the type of GPL analysis we typically see in determining whether a derivative work is covered. Operating systems available on the cloud likely would not be at risk, but libraries and utilities essential to the operation of the developer application could be.

The emergence of cloud computing not only places the freedoms identified by the Free Software Foundation at risk, but it potentially undermines the ability of open source vendors to maintain a viable business strategy as their applications move to the cloud. In this context, it's clear whyFabrizio Capobianco, Funambol's CEO, is such an advocate for use of the AGPL instead of the GPL as new projects are rolled out ... not just for each open source vendor, but for the industry as a whole.

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.

In-House Counsel - Managing Open Source

In addition to attending the 2009 Open Source Business Conference in San Francisco, I had the pleasure participating in a legal panel presentation - Managing the Use of Open Source Software in a Proprietary Environment: Lessons from In-House Counsel. Virginia Tsai Badenhope from the Smithline Jha law firm moderated the panel, which included Joyce Chow from Apple, Angela Ziegenhorn from Symantec, and Duane Valz from Yahoo!. We discussed the building blocks of good open source policies and business strategies.

The companies represented on the panel each had a unique perspective on the issue. Apple's open source policies evolved over time from ad-hoc e-mail requests to a fully automated workflow review process. Yahoo! relied on a number of employees who were active and well respected in the open source community to formulate an appropriate open source policy. The importance of cross-product security and technical reviews for Symantec products led Symantec to the creation of an open source review board to address its open source policy needs. Finally, Sun serves as an example of a company that has made open source as a core strategy supported by a robust open source policy, but many details of the policy required significant adaptation after the acquisition of MySQL.

All companies need a strategy for handling open source including bringing open source components in house, distrbution of products as open source, and relationships with the community. The following building blocks are worth considering as a starting point:

• License Matrix: Analyze and categorize common open source licenses to create a more consistent and efficient review process for inbound and outbound open source.
  

• Review/Approval Process and Tracking System: Establish a review process that gathers relevant information and archives approvals including a copy of relevant open source licenses. This process should scale based on need, which could range from a simple spreadsheet to a searchable database coupled with an automated workflow approval tool. Consider whether the review process should also include a separate technical and/or security review of the applicable code.
  

• Written Open Source Policy: A written policy aligned with an organization's business strategy and risk tolerance sets a common set of expectations for everyone. These policies are most effective when developed with input from engineers and business owners.

• Open Source Officer and/or Open Source Review Board. An open source officer is a necessity for any organization that is regularly involved with open source. Also consider whether a cross-functional open source review board is appropriate. Such boards should include business, engineering and legal members. The open source officer or review board often resides in a chief technology office or similar functional group and is responsible for defining high level strategy and initiative, and can also be involved in the review/approval process for particular usage of open source.
  

• Internal Training and Guidelines in Support of Strategy. Formulate internal training materials and guidelines to maintain consistency in application of strategy. This is particularly important in organizations that decentralize decision making authority on open sourceissues rather than centralizing it in a review board or similar body.
  

When considering what to include in a policy, the following principals might help in prioritizing objectives:

• OS policies and processes must continually evolve. Don't assume your policy will serve all your needs indefinitely, and don't be afraid to modify it to address new issues.

• Settings goals and defining strategy are critical to good open source decision-making. Because open source issues are often ambiguous with no inherently right or wrong position, decisions cannot be made in a vacuum.

• No matter how many policies, processes and tools are in place, each open source decision requires the application of independent judgment by someone with a functional understanding of open source issues.
  

I hope this discussion will help clarify thinking and provide some inspiration for finding the right strategy for your organization. Please leave your comments with other ideas that might help in developing an open source policy or business strategy.

Highlights of OSBC 2009 - Day 2

The second day of the Open Source Business Conference in San Francisco again had many thought provoking presentations. The day started with a trio of keynote presentations from executives from Sun Microsystems, Microsoft and IBM. In my opinion, Sun CEO Jonathan Schwartz's keynote address on Clouds was the best presentation of the Conference. (Disclosure: I work for Sun.) As a result, instead of summarizing the entire day, this post focuses on clouds.

As the hot new technology trend, Cloud computing attracts a good bit of interest and was mentioned in virtually all of the keynotes to some degree. I have been caught in the cloud hoopla too, but have had difficulty identifying what makes it different from software as a service. Until this morning, I have not been able to find an answer, but Jonathan Schwartz's presentation pulled together many of the missing pieces.

Schwartz explained Sun's vision for clouds, which includes 3 types of clouds each of which can be deployed in public and private environments. The three clouds are:

1. Infrastructure as a Service - This is a packaged operating system for use in a data center. Amazon's EC2 is a good example.

2. Platform as a Service - These types of clouds go a step beyond infrastructure while trading high switching costs for enhanced value. Google's docs and related services are an example.

3. Application as a Service - This is the type of cloud many enterprises have already experienced. It extends from a platform to implement a fully functioning application over a network in a manner similar to what we already experience on our computers. SugarCRM's offering is a common example.

The public/private distinction is important. While many enterprises will be able to utilize a public cloud and avoid the IT overhead, some enterprises will require private clouds behind their firewall to address security concerns and regulatory requirements (such as HIPPA and GLB in the health care and financial industries). Schwartz sees each enterprise utilizing a "network of clouds" that are mixed and matched to meet its needs.

While this taxonomy of Sun's vision of clouds made them relatively easy to understand, my moment of gestalt came as Schwartz explained that the cloud is not only the ultimate embodiment of super computing, but it is the next logical step beyond open source. As open source becomes a mainstream business strategy, I have struggled with the question of "what happens next?"

I now understand how the benefits of the open source in the application space can be amplified when applied to clouds. (On the point of open source as mainstream, Matt Asay, GM and VP at Alfresco, and co-founder of the OSBC, described the state of open source as reaching the end of the "cancer" phase and beginning the "pragmatism" phase, with a continued need to emphasize evangalism.) I also understand that the vision of clouds (not just Sun's vision) goes well beyond traditional SaaS offerings to encompass a much larger, interconnected infrastructure with much greater potential for a qualitative leap in how business is conducted and problems are solved. No doubt, cloud computing will keep the legal community busy for years trying to understand how to adapt our old methodologies to this new environment.

Matt Asay has his own post that emphasizes other elements of Schwartz's presentation that is worth reading.

For more details on Sun's cloud computing solutions, check out their web site.

[Updated to fix some typos.]

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.

Open Source Prime Time? Sometimes...

No doubt the open source movement is having a significant, tangible, positive impact on the technology industry. It's success grows every day as we see it moving up the priority list of IT Managers and CIOs in large part because of the cost savings it offers. Even though open source has arrived on a macro scale, I see plenty of difficulties on a micro scale, which reminds me open source needs to make significant strides to be truly mainstream.

The micro level difficulties range from quirky annoyances to significant impediments to performing necessary activities. For example, I spoke at a PLI legal continuing education course on open source licensing a few months ago, and I will speak on a panel at the Open Source Business Conference next week. Both presentations required submission of slides and associated documentation prior to the presentation. A message went out to presenters: "Our presentation machines *do not* support OpenOffice." Microsoft PowerPoint and Microsoft Office were the only supported formats (in fact, sometimes even PDF is not supported). In addition, when collaborating with colleagues, no matter how carefully one converts OpenOffice documents to Microsoft Office formats, formatting and content problems are almost certain to occur.

[Update: OSBC presenters received an e-mail update today notifying us that OpenOffice documents are in fact supported for the presentation. Great news! One small step towards making open source practical for everyone in all circumstances.]

On an even more granular level, while open source tools are generally pretty good, they are not quite ready for full product use. Redlining, for example, is a critical tool lawyers and others use for tracking changes between different versions of contracts. While I use OpenOffice a majority of the time and am largely satisfied with it, the document comparison feature is inaccurate and unreliable. (For a positive spin on use of OpenOffice and other open source software in legal workflows, check out the Open Source for Lawyers website.)

My point is not to steer you away from open source. On the contrary, I am a heavy user of open source applications for my work and personal projects including Mozilla Thunderbird and Lightning for e-mail and calendar, and GIMP as a Photoshop alternative. However, I am acutely aware of the limitations of these applications when it's crunch time. When I have 15 minutes to produce a redline that will properly display all the sneaky changes an opposing attorney has made to a contract, I simply can't rely on OpenOffice. I hope this changes sometime in the near future.

Magic and Fear vs. Open Source Reality

I am surprised at how easy it is to let the magic or fear of open source sidetrack discussions that should be firmly rooted in legal considerations. Maybe this is because open source evokes such polarized reactions ... true believers show fanatical devotion to the open source movement as if it is a religion, while technology dinosaurs grumble about risk and cling to the notion that open source is a fad. The reality, of course, is that the majority of us fall somewhere in between these extremes and are in a constant state of assessment as to how best to use open source to our advantage. In making these assessments, we need to take care that we don't let the rhetoric around us cloud our judgment.

Attorneys need to pay special attention to this because one of the critical roles we play is to give an honest assessment of the facts and risks. Unfortunately, even the most experienced attorneys can be distracted by the level of rhetoric around open source, particularly when open source isn't a primary practice area. Like all legal issues, analysis of open source issues requires a disciplined approach. Here is short hierarchy of things to consider in order of priority (using GPL as the context in some cases):

1. Know the law. This is obvious, yet open source discussions often fail to include an explicit discussion of basic legal issues. In his 2001 essay on Enforcing the GNU GPL, Eben Moglen (then General Counsel of the Free Software Foundation) made it clear that even though the idea of free software is unusual in the world of proprietary intellectual property rights, "as a copyright license the GPL is absolute solid." Contract law is as important to open source as copyright law. The Federal Circuit Court of Appeals used contract law to reach its ruling in the recent Jacobsen v. Katzer case. Finally, the increased litigation surrounding the GPL (such as the Busybox line of cases and the FSF v. Cisco case) are as important a reason as any to make sure you know what the law says about open source.

2. Know the GPL. The basic concepts of copyleft and the goal of the GPL seem easy enough to understand - if you modify GPL-licensed code, you must distribute your modifications in source code. While this is generally true, the details of the GPL are critically important to determining how to comply with the license. The Software Freedom Law Center's Practical Guide to GPL Compliance provides a list of details that could be the subject of claimed violations. Truly understanding the GPL can be an impossible task when we consider the flexibility and ambiguity intentionally built into the GPL. Reading and understanding the SFLC's Practical Guide, FSF's FAQs on the GPL and other resources is important in interpreting the GPL.

3. Understand the community's priorities. One of the distinguishing elements of open source is the deep involvement of the community. Even if you think you have the "right" answer to a particular open source question under the law or based on a valid interpretation of the GPL, the community might reach an equally valid answer under its own analysis and interpretation. As a result, open source activities cannot be considered in a vacuum.

4. Evaluate where your business goals fit. Don't let irrational exuberance or paralyzing fear over open source rule your decision making. Open source decisions are business decisions like any other within an organization and should be subject to the same types of review and decision making considerations. Open source is a tool for use in achieving business objectives, but is not an objective in itself.

Admittedly, none of this is new ... these tips are considerations businesses evaluate every day. Even so, consider this a friendly reminder that open source is neither magic nor the bogeyman. It is just another tool in your toolbox and should be treated accordingly.

From User to Contributor

As open source software becomes more widely used, the flow of contributions back to open source projects become more important. Contributions back to an open source project are not only an indicator of the health of a particular project's community, but they are critical to ensure these projects are able to grow and realize the benefits of community involvement. Matt Asay noted in a recent Open Road Blog posting, a lack of contributions from enterprises "may have serious, negative consequences for the long-term health of the open-source ecosystem."

A recent article by Dan Woods in Forbes explains that this is the result of a gap between the "enlightened self-interest" of individuals who contribute for their own benefit, and institutional collaboration, which is "much lower than expected and hoped for, based on patterns of individual participation." While the Forbes article provides some excellent background on the problem and how we reached this point, I would like to dig a little deeper into the reasons why enterprises don't contribute, and what changes are needed to encourage more contribution.

Enterprises (primarily for-profit corporations, but also government entities and foundations) often have few incentives to contribute to open source projects, and many incentives to not contribute. At a fundamental level, the traditional thinking of enterprises has been that ownership of intellectual property is an important part of preserving corporate assets. Though the open source movement is changing these views, ownership and tight control has also traditionally been seen as crucial to preserving a competitive advantage. In addition, enterprises often suffer from the failings of bureaucratic organizational structures, which make the process of obtaining the multiple layers of necessary approvals for release of intellectual property rights difficult if not impossible. Finally, another basic concern of for-profit enterprises is that any time spent on open source projects is time taken away from core, for-profit activities.

No doubt the above described bias against open source contribution is the product of short-sighted thinking. While we should not expect that enterprises would change their position on openness in a short time frame, we can propose short-term, high-impact fixes that quickly and strongly demonstrate the benefits of open source and encourage more openness. Some specific examples include:

• Appeal to employees of enterprises to voice their desire to participate in open source projects, and use resulting the groundswell of employee requests as a way to incent enterprises to develop a well-reasoned participation policy rather than perpetuating ad-hoc or unknown participation.

• Create model policies that enterprises can easily adopt to permit employee participation and facilitate enterprise contribution, with an emphasis on the benefits of participation over the traditional focus on ownership and control of IP rights.
  

• Clearly demonstrate cases in which contributions create a win-win situation for enterprises and communities, possibly in a public white paper format.
  

• Begin with the low-hanging fruit: contributions related to internal IT infrastructure components rather than contributions that are perceived to compromise competitive advantage; tackle the issue of contributions related to competitive-advantage at a later time after the benefits of contribution are clear.

• Acknowledge that strategic and competitive situations might exist that warrant withholding or delaying making contributions, while emphasizing that it is a rare case when choosing not to contribute is the best course.

Some of these are aspirational, but the underlying themes are important: (1) Every technology company has a massive base of employees who are interested, if not heavily involved, in open source, and these employees can be the agents of change within enterprises. (2) Enterprises need to better understand the economic and other benefits of contribution, and the lessening importance of ownership and control of IP rights. (3) This movement should occur incrementally by starting with the types of projects that are least likely to encounter the traditional organizational resistance.

These changes will happen on their own over time, but we can establish an environment that encourages enterprises to speed progress. At stake is the ability for open source projects to survive and reach the critical mass necessary for all community members to realize significant benefits of the open source movement.