Well, apparently I must not be alone in my disapproval of Ingres choosing GPL. I just noticed the following notice on the Ingres Licensing page:

Important Notice on GPL Licensing
Posted February 12, 2006
We have had significant feedback from many of you who would like to bundle access or include the Ingres access technologies (JDBC, ODBC, .Net, OpenAPI, ESQL etc.) with your non-GPL products, or link with these technologies, but are concerned about the viral aspects of the GPL.

We understand this important customer/partner requirement and are working to make this possible without limiting the needs of GPL partners and customers, or for end customers to get support.

I value this feedback from the Ingres community and the level of interest in using Ingres as an embedded or bundled database in applications as diverse as appliances, printers, and ERP solutions. Please check back in the next few days for an update on this topic.

To receive email updates on this topic, please email info@ingres.com with the subject GPL.
Dev Mukherjee
Chief Marketing Officer
Senior Vice President of Business Development

Hopefully this will be one of those cases where the community gives tough love, and it turns out in the best long term interest of the project. We’ll see!

I met with the CTO of a company leveraging open source projects to build a compelling offering in the BI/DW space. Their secret sauce is staying closed source, but they are contributing some good stuff back to the core projects which they are leveraging.

We were discussing the dual licensing GPL/Commercial strategy and he put it quite nicely:

For business focused projects that have little or no value to hobbyist projects, it’s almost antagonistic offering GPL

This echoes my thoughts on the Ingres move to GPL. Business focused open source projects know that they have to exist in an economy of open and closed source applications so offering a GPL version of their project could be considered insulting! In practice, it becomes shareware (try for free, but use for money). For instance, Ingres corporation is saying that you are free to use our database if your product is GPL. This is like offering a scholarship to an underprivileged inner city youth for a PhD program in Astro Physics when they only just passed their GED. They can claim they are being benevolant but they know that student will never get accepted to the program.

My advice to “business focused” open source projects: If you want to flourish, you must have a business friendly license otherwise your community will not arrive. The hobbyists don’t need advanced business workflow processing, and companies that could invest in your technology won’t because they need business friendly licenses.

MySQL works because it actually benefits the community because “Joe’s MP3 collection manager” does need a simple database for it. MySQL is on the “cusp” of a business application. There is a reasonable value add for MySQL in GPL and vice versa.

I’m continually amazed at how the words “open source” and the actual practice of “open source” are getting twisted, turned, mauled, and misused to make a buck. It’s entirely possible for someone to choose GPL and not build a great open source project… Community (developers, companies, users) is the secret sauce so your license, posture, philosophy must engage your potential or existing community with the idea that getting some invested in your project (ie, hard working hours of coding, testing, and leveraging your project) will far surpass any tricky antics to force people to pay you some money.

IMPORTANT: Some people have commented/emailed that I’m off my rocker by asserting using a GPL database triggers the viral nature of GPL. I should make the VERY CLEAR distinction that the reason it triggers the GPL (I believe) is because the CLIENT ACCESS LIBRARIES are GPL licensed (the client code is embedded into the CLIENT applications). I don’t think it really matters what the server in a different process is licensed as, it’s the JDBC drivers that cause GPL to kick in. Refer to the MySQL interpretation of this (LGPL to GPL)

UPDATE: I’ve been told that the announcements on GPL may have been incomplete. There is possibilty that interface code may be LGPL to allow for use in the ISV/OEM apps without GPL restrictions. I’ll update this if/when there is an actual announcement on LGPL stuff.

I was quite optimistic when Ingres was divested from CA. Here was an opportunity for Ingres, a mature feature rich database, to make a real dent in the world. Instead, Ingres (the codebase) has made the same mistake AGAIN by choosing a license which will ensure it never becomes a “real” open source community, project or sustainable business model.

CA made the mistake of picking a funny license when they open sourced Ingres: CA-TOSL was an off color license that many people passed up even considering Ingres. CA squandered an opportunity to create a real open source project, which is just disheartening. There is SO MUCH in Ingres that with “two cups and two tablespoons of community” Ingres could have been the leading open source database. Instead, they came up with a “pro-CA” but relatively business friendly license that meant Ingres, it’s source repository, etc remained decidely in the fortress of CA.

Ingres was divested to a lean, mean Ingres company with the sole purpose to making Ingres the leading “business open source.” This was truly exciting, and the potential of what Ingres could become was palpable. Parallel query execution, intelligent join operations, replication, distribution, table partitioning. A robust feature rich RDBMS primed for the ISV/OEM and early adopters needing an open source RDBMS worthy of their applications. Forget the GUIs, marketing materials, and blackbox functionality: Ingres was primed to be the tool of choice for companies willing to overcome some of the rough edges to power their platforms. It could have been the “Kleenex” of FOSS DB. The “Hobart” of FOSS DB. The “Phillips Screwdriver” of FOSS DB.

Terry, I’m sorry to say, you must have received some bad advice. Actually, let me clear here: REALLY BAD ADVICE! The GPL is the nail in the coffin that will make the long drawn out history of Ingres final. It will fade to obscurity because NO ONE will touch it with GPL. Let me explain and I hope for your investors and customers that I am wrong!

The days of being an RDBMS for general purpose are done!
You are going to be used as a component in an application or service. If people are purchasing their DB first and they plan to build extensively on a database they are choosing commercial vendors. Quite simply put, if someone wants to build their application and the database is the most important piece of that puzzle (think PL/SQL, triggers, etc) then it’s not an open source database. ISV and OEMs are the ONLY ONES that are going to build sustainable economic conditions for an open source database. Your company identifies this in the “Three Degrees of Seperation” whitepaper posted on your site.

GPL means that companies building applications for BUSINESS won’t use you!
Why do you think that most BUSINESS ORIENTED applications considering an open source database have chosen Postgres? The GPL is quite frankly, really really scary to companies and so NO ONE who is building any sort of “Pro” edition, building applications with significant amounts of their own capital, or using other business friendly open source license (which is one of the valid open source business models) will use it. Quite simply put, the GPL ensures that Ingres will not be used by companies building business applications.

Partners/ISVs/OEMs willing to purchase your license will choose SOMEONE ELSE!
Knowing that your GPL option is entirely unsuitable for embedding into an application why would anyone choose to PAY the licensing for Ingres when embedded proprietary licenses are cheap? ie, Knowing that customers aren’t going to get the benefit of an open source database it may as well be a black box that an application runs on and that’s it. Why choose to pay for a product that is technically behind Oracle when the “embedded” commercial version terms are comparable? If it costs the same amount, both are proprietary licenses, why would someone selling a business application forego the “powered by Oracle” to choose a proprietary Ingres license?

Zero chance at “community”
Ingres (the project, not the company) had failed to build any sort of community in more than a year. By ensuring that the entire Ingres codebase remains copyright Ingres Corporation you pretty much ensure that any features people may build into Ingres won’t see the light of day. This is the secret sauce of open source. Inventors inventing, leveraging the ideas and efforts of people all over the world. Well then, what about the GPL projects of the world that will use Ingres and contribute their time testing, qa’ing, bug fixing, etc? See next bullet.

The GPL “database of choice” is already decided
Every GPL project uses MySQL (not every, but close). Community, applications, knowledge, support, training, brand awareness. Done, finished. GPL projects needing a DB don’t really think about it. It is the de facto standard for GPL projects. Why would anyone writing Joe’s Open Source Scheduling and Management Toolkit choose Ingres that has NO community outside of Ingres corp and will NOT develop one (see previous bullet). Anyone needing your “enterprise features” above and beyond what MySQL provides will fit the category mentioned above (ISV/OEM) and find your license unsuitable.

Quite simply put, the CA-TOSL was bad for Ingres but the GPL is just horrendous (not necessarily because GPL is, just GPL for Ingres). Anyone who needs your features won’t use your commerical license (think integrated health care application X) when they can use other proprietary RDBMS and open source projects that COULD use Ingres won’t because they don’t need the features and MySQL is 10x better from a community/FOSS perspective.

I’m sad actually, I was quite excited about Ingres. RIP, Ingres. I hope the death comes swiftly and customers find little pain in their migration to other sustainable RDBMS projects/products.

Nanoblog (which has nothing to do with Nano technology) has good advice for Commercial Open Source Companies. I know the Nanoblog author and he is working in an IT organization that is trying to make OSS work in their environment so he’s formed these opinions working with multiple OSS companies.

Some comments:

“Let go of the control on product vision.”
Product vision is what helps COSC make money… If there is zero revenue in feature X then the company shouldn’t fund that. Now, flip side, the company should not stand in the way if someone who cares nothing about revenue wants to build feature X themselves. There is nothing evil with COSC prioritizing their contribution to OSS according to their revenue as long as they aren’t dictating standards/interfaces/etc that exclude the collective community will.

“Play well with other open source products.”
This is, easier said than done. It’s tough enough to assemble products with expertise on call (companies) and thorough and complete documentation and integration “road maps.” However, the “integrator” in open source almost always bears the burden on both sides of the projects… Someone wanting to play nicely with other OSS projects would have to become quite knowledgable about t’other to be successful int hat integration.

“The community is your number one customer”
I think this makes a good sound bite, but just can not be true for a company. Right or wrong, a companies purpose it to generate profit. It’s not a company (it’s a trade org, or co op, or association, or non profit) if it serves another interest (perfectly valid right? Mozilla Foundation, yes?).

I think Nanoblog omits some of the important, mutually beneficial aspects of COSC. Open Source “projects” at their core, are interesting and useful to engineers as they put together solutions. However, it is the application or solution that is of actual value to society, people, and business. ie, the Mozilla XUL package is valuable to the engineer, but it’s value to the world is actually as Firefox. ie, TCP/IP is cool to the engineer but email changes the world. Thinking of money as a currency of reward for value, people/societies/biz aren’t willing to pay for pure engineering genius. Unless of course, it’s an act of charity. They ARE willing to pay for something that makes their life better, easier, less expensive or provides an emotional experience ($20 toilet designer brush at Target).

The commercialization of open source provides the actual benefit of the inventors work to society… it validates the inventors passion with mass adoption or value; I can think of nothing more gratifying to the inventors spirit than to “change the world” for billions of people. This actual benefit is what people are willing to provide contribute back to the company/community. This, in theory, should provide the needed capital for the inventor to continue the pursuit of passion to provide the world his/her talent. This is not always the case; some productizations of open source don’t necessarily reward the actual inventions for their worth. How much profit should the person bringing technology X to the market reap, when they did nothing more than “apply it” instead of “invent it.”

Herein lies the paradox of Commercial Open Source that is the most interesting “tech” debate of the 21st century. Commercialization of open source projects brings sustaining capital as reward to these projects (in terms of comitters, paid OSS developers, testing, QA, conferences, etc). However, commercial direction in Open Source is considered in opposition to the freedoms of OSS and the inventors spirit. Ie, commercial application of OSS (whether for internal engineers or commercial open source applications) pay the bills of the inventors while they invent. This has always been the case (ie, Bell Labs was able to function b/c of huge profits by the commercialization of technology at AT&T).

The tsunami of open source “VALUE” is just beginning. Microsoft didn’t invent the mouse, they made it valuable to you and me. etc. I think it’s very much “black and white with 1000 shades of grey” on how companies are balancing this. Some do well, others do poorly. Time will tell what makes up the real secret sauce of “commercial open source.”