The Rise and Evolution of the Open Source Software Foundation

Paula Hunter,a Stephen Walli,b

(a) Executive Director, The Outercurve Foundation: (b) Technical Director, The Outercurve Foundation.

DOI: 10.5033/ifosslr.v5i1.64


Free and open source software (FOSS) project communities continue to grow and thrive.  When such projects reach a certain critical point in their growth, corporations express interest in participating.  Corporations have more stringent and robust software intellectual property (IP) management needs, however, and projects are not always up to the task.  Neutral non-profit FOSS foundations have proved to be a solution to these problems, providing for the IP management needs of corporations while offering additional business and technical services to the project communities to encourage further growth and adoption. This article reviews how such neutral non-profit organizations have grown to meet the evolving legal, business, and technical needs of FOSS communities and businesses.


Law; information technology; Free and Open Source Software; foundations



The growth and global participation in open source software development, aided by inexpensive and pervasive Internet access, has created a community of collaborators on whom software developers and IT professionals depend as a vital element in the software development process. As software intellectual property (IP) practices have matured, free and open source software (FOSS) communities have kept pace.

FOSS licensing has evolved over the past thirty years from the more liberal academic do-as-you-will licenses and initial ideas of software freedom to reflect the advancement of the general software landscape and include more complex methods of keeping software free.  For example, with  U.S. law recognizing software patents and the consequential risk involved with this, FOSS licenses began to introduce patent related clauses. As corporations became more interested in contributing to and using FOSS-licensed software, FOSS licenses were written using more traditional license structures and language.  One of the key tools in this maturation has been the evolution of the non-profit technology foundation as a software IP management mechanism, as well as a hub for communications and collaboration.

Many volunteer-led and community-centred FOSS-licensed projects reach a point in their technology growth and evolution where corporations want to participate as well. Corporations have very different needs with respect to IP management, provenance tracking, and governance, as they are concerned with managing exposure to their patent portfolios and want to minimize to the potential for litigation.  FOSS foundations provide such structure, as a number of key FOSS projects illustrate.  

The Apache Software Foundation (ASF) formed around the Apache project as a non-profit charitable organization in 19991, adding a new, more structured license (Apache License 2.02). This step happened as IBM became interested in participating with the intent to embed the Apache http daemon software in its Websphere product line.  Likewise, the Open Source Development Lab3 (OSDL) formed to support the Linux project in 2000 as a non-profit trade association to better manage IP risk as the Linux operating system became the cornerstone of a number of product lines from vendors that traditionally competed in the UNIX systems space. This non-profit later merged with the Free Standards Group4 a non-profit trade organization responsible for specifying Linux programming interfaces to form the Linux Foundation5. The Eclipse Foundation6 formed around the Eclipse IDE project in 2004, and has been the caretaker of the rigorous Eclipse software IP management process and the evolution of their FOSS license..  

Each foundation represents different values and objectives to its constituency. Yet, what foundations have in common are governance structures to provide IP management and committer indemnification, as well as support mechanisms for community and collaboration.

The Outercurve Foundation was recently established to take this well-defined model and apply it forward for FOSS projects in such a way as to give vendors the benefits of such non-profit FOSS foundations without the expense and risks of creating their own foundations. The Outercurve Foundation provides the IP management and business operations associated with FOSS foundations as a non-profit trade association. It is technology, forge, and FOSS license agnostic (as long as the license is approved by the Open Source Initiative).  

Public Good or Membership Benefits?

Many of the original FOSS foundations (e.g. the ASF and the Linux Foundation) were incorporated in the United States. An early decision for any FOSS foundation is whether to establish itself as a non-profit trade association (501(c)6 under U.S. tax law) or a non-profit charitable organization contributing to the public good (501(c)3 under U.S. tax law).7  The FOSS community at large is very focused on the distinctions between these two types of non-profit organizations.    
There are two major factors often discussed when evaluating these options: financial implications and control of the organization, in terms of who benefits.  Many FOSS projects like the ASF or the Free Software Foundation are looking for a means to distance individual developers from the finances of the organization while encouraging donations to the entity. The charitable organization status allows the organization to accept funds, which are tax deductible, and can be used to cover the basic operating expenses of the organization and, in some cases, fund development or specific project work.  In many cases, a strong governance structure has evolved with the growth of the project (e.g. the ASF8), and thus codifying it with a formal charitable non-profit structure is a logical step in its lifecycle.  The notion ofpublic goodis also very complementary to the philosophies of some FOSS communities, and thus the charitable organization is often chosen for more than simple accounting purposes.  
The trade organization designation is frequently chosen by a collective of vendors, i.e. software companies, that want to collaborate on a project, jointly fund the effort, and establish a structure that ensures balanced control.  While the primary distinction here is that the members are the beneficiaries of the efforts of the organization, in most cases a broader community can participate in and enjoy the fruits of the labor.  The Linux project is an excellent example of a FOSS project that has benefited from significant vendor investment through a foundation.  The Linux Foundation (a 501(c)6) trade organization under U.S. tax law) balances the needs and interests of its members in a very large community through its member programs9 and membership bylaws.10  In most cases, the tax implications are not a major factor; governance structure and IP management are far more important.

The Value of Foundations

Regardless of whether a FOSS foundation is organized as a trade organization or a charity, non-profit FOSS foundations offer projects three distinct types of services.  First, they provide participants with a legal framework for software IP management in which commercial companies can work with FOSS projects and contributors.  Foundations also provide technical services, such as software repositories and issue tracking, code signing certifications and technical mentorship.  Lastly, foundations provide business operations and governance support, such as financial and banking services, membership management, and communications and PR around projects.

Legal Framework for IP Managment

Ownership Neutrality

One of the key benefits of using a non-profit FOSS foundation for project IP ownership and management is that it creates a neutral place for collaboration.  Many corporations are loath to participate in FOSS projects held by other corporations that may be competitors or partners.  There is a concern that their intellectual investments will go to other benefactors and they will see a poor return on investment.  A neutral foundation holding the IP ownership allows all corporate sponsors to participate on equal terms. No one corporation owns the project software so partners and competitors alike can feel they are getting the best return on their contribution investment without giving others a significant advantage.  

Foundations own the open source project's IP and have no commercial interests in the software, i.e. the foundations sell no products or services based on the software.  Software copyrights are assigned or licensed by contributors to the foundation in a variety of ways through membership agreements, assignment or license agreements, and sometimes the project open source license itself. Patents are often licensed to the foundation. Providing a neutral place for companies and individuals to co-operate often leads to growth in the community of contributors. Well-managed IP also leads to growth in project acceptance and adoption as other parties become more confident adopting a project with well understood software provenance. Indeed, all of the largest and most active FOSS projects are managed by FOSS foundations.11  Whereas, the next most active projects smaller by an order of magnitude than the leading projects are managed and owned by single corporations.
That FOSS projects run by a single corporation tend to be smaller may be due to concern around the consequences of a change in IP management or ownership. When a single corporation controls a FOSS project, what happens to the IP if the corporation changes direction or gets acquired?  MySQL may be one of the most successful FOSS projects, but subsequent acquisitions by Sun Microsystems and then Oracle have left the broader project community confused.12 13  MySQL AB had rigorous IP management practices, but this means all the IP is now owned by Oracle, and they are rightly using it to corporate benefit.  Over the past couple of years a number of competing FOSS-licensed database solutions are growing and interest in MySQL is waning.14 If the ownership of  MySQL had been held neutrally, none of the participants and users would have felt disenfranchised to the point of beginning their own projects or forking the MySQL software base, and the community may have continued on as strong as during its early years.

Liability and Risk Management

Foundations can also serve as liability firewalls or shields.  Many companies are uncomfortable with publishing, sharing, and collaborating on open source software if they are the only copyright owner.  Having a neutral third party hold the copyright ownership reduces some of that liability risk.  A foundation, as a legal entity, acts as a shield that generally protects its members against liability for the contracts, commitments, and possible negligence of the foundation itself.  The foundation (legal entity) may also protect the members that were not participating in a given activity for liability from other members’ actions in a given situation (e.g. the introduction of infringing software into foundation owned software).  

All FOSS licenses disclaim liability.  Many vendors develop products out of FOSS-licensed projects (e.g. Red Hat Advanced Server is the product developed using software from the FOSS-licensed Linux project). Vendors are comfortable having product performance liability discussions with customers that have paid for the product and embed liability clauses in their product licenses.  Many vendors, however, still feel there is the perception of liability risk for FOSS-licensed projects they own from unpaid users.  Assigning the copyright ownership of a FOSS-licensed project to a non-profit foundation is a clear message ofnon-copyright ownership”.  The vendors may still control the project direction through participation in the project governance and by supporting the primary developers and committers on the project, but there is a perception that they have reduced the liability risk as they dont own the project’s software copyright.  The foundation ownership acts to divert claims away from the original owner.

Additionally, the use of a legally incorporated foundation may provide certain soft benefits by playing to the perception that the legal issues and operations have been more carefully vetted and discussed with respect to members, contributors, and committers.15  

As well as acting as a legal shield for members and contributors, foundations can also act to protect individual participants in the FOSS project by indemnifying their actions.  This indemnification takes a number of forms.

FOSS project committers are primary developers on the project who have full write access to the software repositories, i.e. they are in the position of committing changes to the software.  Committers may be individual software developers, and/or employees of independent software vendors (ISVs) or large corporations. Foundations can serve an important role indemnifying their committers depending on other governance and membership structures in place such that individual committers are not held personally liable for the software, regardless of the liability clauses embedded in FOSS licenses.  This is certainly the case with the Outercurve Foundation and the ASF.16
Foundations typically explicitly indemnify their board directors and members as well in their governance policies. This is the case with the ASF17, the Eclipse Foundation,18 and the Outercurve Foundation,19

Code Provenance

Foundations may provide governance processes to track code provenance. A variety of legal opinions and practices discuss whether software contributions should be copyright assigned to a foundation, or copyright licensed into a software projects collaborative community or neither. Some believe in assignment of all rights under copyright (e.g. the Free Software Foundation20), while others believe a license of rights under copyright is sufficient (e.g. the ASF21). Still others feel all necessary rights are embodied in their open source license and membership agreements (e.g. the Eclipse Foundation22).

Each position and practice is defensible. Having all the rights of copyright ownership would allow the single owner to directly handle any litigation involving the software.  It would also give the single owner the ability to unilaterally change the licensing terms for the software.  This is what causes many developers concern if they are required to assign their copyright to a single entity when they contribute to a FOSS-licensed project, as it requires the single entity to be in a strong position of trust.  Non-profit neutral foundations act in that capacity far better than for-profit corporations.  

The opposite position where everything is licensed and the community of licensees collectively owns the software makes it difficult to act on such items as changing the licensing terms.  Some view this as a re-enforcement of the community and the communitys values.  

The acceptability of contribution assignment and license agreement practices within communities of developers can be easily seen when you compare non-profit neutral foundations and for-profit corporations.  Developers raise concerns that code assignments for FOSS contributions to corporations are at risk if the corporation chooses to close the project back behind its ownership wall or relicense them for its own corporate gain.23  Again, MySQL stands as an excellent example here.  MySQL AB required copyright assignment of all contributions to the for-profit company and made a considerable percentage of its profits selling closed licenses to its otherwise GPL-licensed software.  This sole for-profit ownership caused a lot of concern through the two subsequent acquisitions by Sun Microsystems and then Oracle Corp. and ultimately led to the forking of the code base and new FOSS-licensed projects to replace the MySQL database.24  Assignments and licenses to legally neutral non-profits remove such concerns.  

It is important to note that regardless of the legal structures in place, software development practices to track the software contribution flow are also a critical and necessary part of the process of provenance tracking.  Version control systems, issue tracking, and email archives all contribute to ensuring the software contributions themselves can be tracked, as well as the contributors assignment or license agreement.  The ASF, Eclipse Foundation, Linux Foundation, and Outercurve Foundation all ensure such practices are in place for the projects they manage.

In any approach to assignment and contribution licensing practices, well managed IP with clear provenance tracking processes encourages adoption of FOSS projects by other organizations and grows the community of users and possible future contributions.

The License of a FOSS Project and License Curation

The license a FOSS project uses is often seen as more than a legal agreement for licensing the software.  The license defines the project communitys values for how they want to collaborate together and share the results of their work.  Whether a project community believes all participants and contributors must license contributions and derivatives under the same license is wired into the choice the early community makes about the software. How the community wants to talk about patents that may relate to the software is embedded in the license, from the lack of discussion in such licenses as the BSD license to the various discussions of patents and patent retaliation embedded in licenses such as Apache License 2.0, the Eclipse Public License, and GPLv3.  

Key current FOSS licenses evolved within foundations.  As the Apache project evolved into the ASF, the simple BSD-like Apache 1.0 license evolved into the Apache  License 2.0, which was a much more traditional license with respect to structure, and began to deal with discussions of patents.  Likewise, the evolution of the Eclipse projects licensing has evolved with the Eclipse Foundation's governance over time,25 from a project begun and anchored by IBM and the newly created IBM Public License, to the Common Public License as the Eclipse Foundation was created,26 and most recently the Eclipse Public License as the Eclipse Foundation became the steward of the license.27  The evolution of the GPL has been tightly bound to the Free Software Foundation and its evolving articulation of software freedom over the years, most recently culminating in the GPLv3 which attempts to set the concept of software freedom against the background of the modern Internet, the growth of the World Wide Web, and explicit clauses regarding patents.28
While FOSS licenses can be very foundation-centric based, nothing requires this to be so.  For example, the Outercurve Foundation only requires that a project under its management use a FOSS license approved by the Open Source Initiative (OSI).29  The Outercurve Foundation is not tied to a particular project and thus has the freedom to be agnostic as to a projects choice of license. Tying the choice to licenses the OSI has recognized as conforming to their Open Source Definition is a reasonable decision in light of the Outercurve Foundation's mission to support the growth of free and open source software projects and communities, and the OSI mission to be advocate for the benefits of FOSS.

Technical Services

The Forge and the Communications Channel

Every successful software project, regardless of how it is licensed, is supported by a software construction discipline that involves proper version control, configuration management, and build scripting, test automation, and issue tracking.  These are the tools that enable consistent software delivery.  Most of these tools are provided by modern internet-based forge sites (e.g. SourceForge, Codeplex, Github).  As these are essential tools to supporting complex collaborative development, some FOSS foundations provide the tools as well, most notably the ASF and the Eclipse Foundation.  The Linux kernel team has evolved their own infrastructure for handling this level of software construction discipline, but the Linux Foundation ensures the hosting.  The Outercurve Foundation does not provide such toolsets, remaining forge “agnostic” and ensuring that projects are using the tools appropriately during the project proposal vetting.  

Collaborative development requires strong communications channels as well.  Developer email lists, IRC channels, forums, and wiki software all provide the basis of such communications.  Foundations again can provide the infrastructure to support these channels.  

Mentorship and Incubation

Software construction discipline is part of a project's culture.  So too is the way a project makes decisions and communicates those decisions.  Having a strong culture of sound software development practices allows a project to scale properly.  New projects often come to a FOSS foundation in a stage of growth where they may not have instituted good practices, and to be accepted into the foundation the project needs to be educated in how the foundation's projects comport themselves.  

The ASF and Eclispe Foundation run incubation phases for their new projects.  New projects are assigned mentors and not allowed to graduate out of the incubation stage until they have demonstrated they adhere to the foundation cultural norms.  The Outercurve Foundation did not grow up around a specific FOSS project with a history of specific practices in how to scale in a disciplined manner.  Instead, projects are assigned a mentor to ensure the project is scaling in a disciplined way with appropriate practices.  

General Management and Operations

Support Across the Project Lifecycle

As well as supporting a set of  IP management mechanisms, foundations provide a set of business operational services to meet the needs of their managed projects at different stages of the project lifecycle.  Historically, foundations created around existing projects had already evolved a set of software management practices essential for the software community to scale out to many developers, users, and releases of software.  These collected software management practices became known as the Apache Way30 at the ASF, and are likewise referred to as the Eclipse Way31 at the Eclipse Foundation. Each of these foundations also hosts the original forge sites that support the software development processes, where the forge is the collection of software development tools (e.g. version control software and repositories, issue tracking) necessary for the development process.
While the foundations supporting the Apache and Eclipse projects each started around a single project, they have expanded to support new projects, in much the same way that the Outercurve Foundation was created to welcome FOSS-licensed projects that had reached a point in their evolution to need a foundation to support the next growth.  Each of these foundations has developed mentoring processes to support new projects.  The ASF32 and Eclipse Foundation33 each bring new projects through an incubation process to teach their respective development processes and IP practices and ensure over a period of a year or two that the project and the foundation are a match for one another.  The Outercurve Foundation34 instead directly matches a mentor to the project to ensure that the project leadership gets the best grounding in open source community collaborative and development techniques that meet its needs.

Different projects have different needs depending upon where they are in their life cycle and the experience that may already exist within the projects participants. Some projects, for example the Outercurve Foundations CoApp project, come into foundations in the concept phase, without a single line of code written. Other projects, such as the Outercurve Foundation supported Chemistry Add-on for Word, are mature projects with many downloads and users. These two projects have vastly different needs, from IP management practices to governance, operations, and marketing support, as well as technical mentorship and expertise to help organize and support collaborative development of software projects.

CoApp chose to license all software into the project (similar to the ASF projects), has run contests to encourage usage, and was started by a developer with a lot of experience in running an open source development community.  In addition to using the Outercurve Foundation to manage the contest, most recently the CoApp project used the Foundation to pay a student to work on a summer work proposal similar to the Google Summer of Code programme run by Google. The Chemistry Add-on for Word, on the other hand, began with an assignment of software from Cambridge University and Microsoft Corp.  It has not taken advantage of the business operations of the Foundation, but has required more mentorship as it evolved, because there was not a lot of experience with open source community development practices. In addition, the project has also had to survive a transition in project leadership.

Each of these two projects uses the services provided by the Outercurve Foundation in different ways to match their needs.  

Funding: Members, Dues, and Donations

FOSS foundations as organizations rely on the donations or dues of members and a volunteer workforce to get much of the work done, regardless of their non-profit organization.

The ASF is an excellent example of volunteer-led membership.  The ASF is organized as a charitable non-profit organization and as such accepts donations, but it is volunteers that provide the majority of work in delivering against its mission, thus keeping operating costs relatively low. Donations cover the costs of items like the systems infrastructure used to support the forge.  

When vendors invest in a non-profit trade organization, their expectations as members are different than what they would expect from a tax-deductible donation to a non-profit charitable organization. In addition to formal governance and operational support, members expect a staff to help drive programs and marketing.  This staff can be comprised of full-time employees, employees assigned from member companies, and staff from firms that provide association management services (AMC).  The Outercurve Foundation employs a hybrid model, with several full time staff members, while leveraging an AMC to provide financial, operational, administrative, and program management functions. This model allows the foundation to be nimble and scale as its project portfolio grows.  Regardless of the staffing model, membership driven FOSS trade organizations are more expensive non-profits to operate than volunteer led charitable organizations working for the public good.


Developers have shared software since they began writing it, and the Internet has accelerated this process of shared collaboration.  That said, collaborative software development needs more than the bandwidth of the Information Superhighway.  To grow and thrive, projects need formal governance and legal structures that allow corporations to share the development work and contribute to the growth of the software and its community.  

Collaboratively-developed software shared under liberal open source licenses continues to provide an enormous productivity boost for developers, speeds time-to-market for corporations, and delivers value to users. Open source foundations are a crucial part of the FOSS ecosystem. Foundations provide a simple, elegant mechanism through which corporate organizations can contribute to FOSS communities and develop their own projects by providing a neutral space for collaboration while mitigating legal risk; they also provide a safe haven for individual developers and projects of all sizes.

Perhaps most importantly, foundations support and enable community growth. An open source software project is only as good as its committers. Committers provide leadership and direction to their projects. Committers create the software but are also responsible for the discipline and quality of the software. Foundations provide the structure, governance and IP management to make it simpler for project communities to grow and flourish beyond their initial developers and users, as corporations become interested in participating. Foundations encourage communities to grow by providing an entity to hold the software property, ensuring no one person or entity throttles project growth by tightly holding the IP. Joining an established foundation also saves companies, and projects, the costs of starting a foundation from scratch, which is an expensive ordeal requiring a lot of expertise to avoid costly mistakes.

About the authors

Paula Hunter brings a compelling combination of industry insight, executive-level business savvy and experience working with not-for-profits to the position of Executive Director of the Outercurve Foundation. Previously Hunter served as Director of Operations for SEMPO, the Search Engine Marketing Professional Organization, a non-profit professional association working to increase awareness and promote the value of Search Engine Marketing worldwide. Prior to SEMPO, Hunter was director of worldwide marketing and business development for the Open Source Development Labs, where she was instrumental in driving membership growth of industry advocacy group and lead initiatives to increase industry awareness and engage large enterprise IT organizations with OSDL programs. Previously, Hunter was general manager of UnitedLinux, a joint venture formed to create a unified Linux offering. She began her career at Digital Equipment Corporation, where she managed marketing programs for DEC's UNIX Workstation and PC product lines. Hunter received a BS in Computer Information Systems from Bentley University.


Licence and Attribution

This paper was published in the International Free and Open Source Software Law Review, Volume 5, Issue 1 (MARCH 2013). It originally appeared online at

This article should be cited as follows:

Hunter, Paula; Walli, Stephen; (2013) 'The Rise and Evolution of the Open Source Software Foundation', International Free and Open Source Software Law Review, 5(1), pp 31-41
DOI: 10.5033/ifosslr.v5i1.64

Copyright © 2013 Paula Hunter, Stephen Walli.

This article is licensed under a Creative Commons UK (England and Wales) 2.0 licence, no derivative works, attribution, CC-BY-ND available at

As a special exception, the author expressly permits faithful translations of the entire document into any language, provided that the resulting translation (which may include an attribution to the translator) is shared alike. This paragraph is part of the paper, and must be included when copying or translating the paper.

Stephen Walli is the Technical Director of the Outercurve Foundation.  Walli has worked in the IT industry since 1980 as both customer and vendor. He was most recently a consultant on software business development and open source strategy. His customers included Microsoft, the Eclipse Foundation, the Linux Foundation. He's an adviser to Ohloh (acquired by BlackDuck), Bitrock, Continuent, and eBox. He organized the agenda, speakers and sponsors for the inaugural Beijing Open Source Software Forum as part of the 2007 Software Innovation Summit in Beijing. Stephen was VP Open Source Development Strategy at Optaros, a business manager at Microsoft on open source, and VP R+D and founder at Softway Systems, a venture-backed company that developed a UNIX portability environment for NT using free and open source software in combination with Microsoft-licensed Windows software, before being acquired by Microsoft. He was a long time participant and officer at the IEEE and ISO POSIX standards groups, representing both USENIX and EurOpen (E.U.U.G.) and a regular speaker and writer on open systems standards since 1991



3Weinberg, Bill.OSDL: The Center of Gravity for Linux. Presentation to the Silicon Valley Users Group. May, 2005.


5Walli, Stephen R.Repeating History: The OSDL and Free Standards Group Merge. 25 January 2007.



8How the ASF Works:



11Henrik Ingo studied open source projects size and vitality and published his results on his website: (Valid: 2-May-2012)

12First Sun:

13Then Oracle:


15Personal correspondence with Andrew Updegrove of Gesmer, Updegrove LLP, Boston, MA, USA.

16The Outercurve Foundation announced governance changes 1 November, 2010:  The president of the Apache Software Foundation, Jim Jagielski, confirmed similar support for Apache project committers in personal communication 18 June, 2012.

17The Apache Software Foundation Bylaws:

18The Eclipse Foundation Bylaws: %202011_08_15%20Final.pdf

19The Outercurve Foundation Bylaws:

20Eben Moglen answers the question as to why the Free Software Foundation expects copyright assignment for contributions: (Valid: 2-May-2012)

21The Apache Software Foundation has contributors license their contributions to the foundation: (Valid: 2-May-2012)

22The Eclipse Foundation doesnt use contribution license agreements, relying instead on the Eclipse Public License and membership agreements. (Valid: 2-May-2012)



25The IBM Developer works FAQ on the Common Public License is informative on IBM’s public statements about license evolution:

26The Eclipse Foundation is formed 2 February, 2004 (

27IBM made the Eclipse Foundation custodian of the Eclipse Public License, 25 February, 2009:

28A history of the General Public License:

29Outercurve Project Proposal requirements:

30The Apache software management process is described:

31The history of the Eclipse practices or Eclipse Way is described:

32The Apache Software Foundation incubation process:

33The Eclipse Foundation incubation process:

34The Outercurve Foundation mentorship program: