Open source projects typically start life in one of two ways. They can be born of the open source development community and grow organically in open source. Examples of this include Apache Tomcat, PostgreSQL, and Linux. Or they can start life as a closed source product that is contributed to the open source community at some point during its life cycle, such as Eclipse, Apache Derby, and Ingres.
The story of how Ingres prepared for its contribution to the open source community, tells one company’s successful process and touches on some of the lessons learned along the way.
Ingres’ open source roots
The original INGRES project, founded at UC Berkeley in the 1970s and funded in part by the Air Force Office of Scientific Research, the Army Research Office, and the Navy Electronic Systems Command, was the foundation on which a number of commercially successful relational database solutions – Ingres, Sybase and Microsoft SQL Server were built. Developed as an open source solution under the Berkeley license, the original University INGRES is still in existence today.
The commercial branch of the University INGRES project, which was also called Ingres, was acquired by Computer Associates (CA) in 1994. As well as having its own users, Ingres was also provided to CA customers as the embedded database within CA’s infrastructure management product lines including Unicenter, BrightStor and eTrust.
In mid-2004, following a period of significant investment in the development of the Ingres technology, CA decided to contribute Ingres to the open source community in an effort to speed up the pace of innovation. CA also wanted to leverage the open source development model to respond to customer needs more rapidly and effectively by engaging customers in the process from design through delivery.
At that time MySQL and PostgreSQL had proven there was a demand for an open source, lower cost alternative to Oracle, Sybase, SQL Server, and so forth, but neither product had the feature set required for mission critical, enterprise deployment, nor did they have the ability to provide 24×7 support.
Ingres was different. It had proven itself in mission critical deployments for over a decade, and had a global support team that understood what it took to provide round-the-clock support to the enterprise where a minute of downtime can equal losses in millions of dollars.
Tracing every line of code
Before a project can be contributed to the open source community, one must first understand the Intellectual Property (IP) ownership and provenance of every line of code.
In 2004 the notorious “SCO Suits” were raging, and it was important to us to be able to provide indemnification, an insurance against IP infringement issues, to our customers.
The Ingres team used a combination of automated tools, as well as a visual inspection of the code to ensure that the origins of every one of the millions of lines of source code were clearly understood.
We performed an additional scan of the code to ensure that no customer names were inadvertently divulged in the code, and that any inappropriate comments were removed.
We had to make a decision about a piece of Ingres functionality, the code for which had been licensed from a third party and could not be contributed to open source. In addition, a GUI database administration tool-set modeled after CA’s Unicenter Database Management Tools was of concern; opening this source could provide Unicenter’s competitors with an edge.
We ultimately decided that both pieces of functionality would be provided on-demand to the end user in binary form, but the source for them would be excluded from the project.
Picking the right license
Choosing the right license is critical to the success of an open source project.
CA reviewed the complete inventory of open source licenses approved by the Open Source Initiative (OSI) at that time. CA found that there was no single model that met its specific needs, which was to sustain and promote the collaborative open source development of the code base, while maximizing the code’s ability to be used and integrated with software licensed under other licenses, including many commercial licenses. It was also important to CA to be able to provide CIOs with an assurance that CA would guarantee the provenance of the source code and would provide indemnification.
CA set about creating what is now the CA Trusted Open Source License.
In hindsight this was a mistake.
The open source community was suspicious of CA’s motives and was deeply skeptical of CA’s commitment to building an open source community around Ingres. Creating a new license increased their skepticism.
In 2005 CA divested the Ingres product line, and one of the first product-related decisions that the newly formed Ingres Corporation made was to release the product under the GNU General Public License (GPL).
The GPL is one of the most widely adopted open source licenses and is well understood by the open source community.
Adoption of the GPL also enabled a dual licensing strategy, which means that Ingres partners and customers can also license Ingres under a business license if they choose.
This means that acquiring Ingres under a business license permits the distribution of products incorporating Ingres source code to be distributed without such products being themselves open source.
Appealing to the open source community
CA had no real hands-on experience running an open source project. They made a number of mistakes with its first and only product contribution to open source – the license was one, the Ingres Million Dollar Challenge was another.
To encourage participation in the Ingres open source project, CA established a competition for open source developers with a million-dollar prize pool behind it.
Contestants had to create a toolkit to enable the migration from a competing database technology to Ingres.
In hindsight, believing that one could buy the affection of an open source community was a mistake and, while there were about a dozen reasonable submissions received, the interest of the contestants waned when the contest ended. Instead, they should have put their focus on and investment in creating a collaborative community development environment that encouraged participation.
Convincing customers
In 2004 the typical Ingres customer was unfamiliar with open source, and many reacted negatively to the announcement that Ingres was to become an open source project.
Customers feared that the integrity and security of the product would be compromised by exposing the code. Many assumed that as an open source project there would be no ownership or stewardship of the code and that anyone could make changes on a whim.
An educational “roadshow” was conducted to debunk open source security myths and to educate the user community about the open source development process.
As a closed source product, Ingres was developed by engineers in over a dozen development centers, and the distributed development process that had proven successful was adopted for the open source project.
All changes are subject to peer review and a rigorous set of acceptance tests must be passed before a change can be accepted into the project.
Open source development is a meritocracy and only those contributors who have earned the trust of the project team are awarded committer rights with direct access to update the source tree.
Advice for software vendors
For companies thinking of making the move to open source, it is important to consider the importance of incorporating the security features that you would expect to use in a mission critical development project including user-, group- and role-based security, discretionary access control, encryption and fine-grained auditing of all system and data access. Most security vulnerabilities are found through reverse engineering, rather than by reading the code, thus the number of security vulnerabilities should be inconsequential when compared to that of closed source competition.
A successful open source project will provide CIOs with a real alternative to prohibitively expensive, closed source solutions, and continue to win new customers and partners, as well as build a vibrant open source development community. Community contributors provide input into roadmap planning, test new releases early in the development cycle, report bugs and work together with the engineering and support teams to deliver new features that benefit the company’s community at large.
I believe that the Ingres open source project can be declared a success. It has met the goals that were set in 2004 when it was first contributed to open source and now provides CIOs with a real alternative to prohibitively expensive, closed source, database solutions.
Ingres has enjoyed many successes as an open source project, winning new customers and partners, and building a vibrant open source development community.
Those customers that were wary of open source in 2004 embrace it today, and have expanded their use of open source beyond the Linux operating system and the Ingres database.
Emma McGrattan is Senior Vice President of Engineering at Ingres.