Riding the wave of its broad adoption, the eponymous company behind the open source Nginx Web server took a turn to the proprietary this week and announced a paid-only edition called Nginx plus. Nginx is popular as a simpler, high-performance server and is often used as a proxy load balancing other server software, as well as for embedded use.
The company had previously relied for revenue on large-scale and embedded deployers looking for expert skills, but this move signals a switch to an "open core" model. The move provoked widespread dismay in the free and open source software communities; Apache HTTPD veteran and Apache board member Jim Jagielski's comment deducing the proprietary is now the most important codebase for the company was one of the milder examples.
[ Also on InfoWorld: Nginx overtakes Microsoft as No. 2 Web server | For a quick, smart take on the news you'll be talking about, check out InfoWorld TechBrief -- subscribe today. | Track the latest trends in open source with InfoWorld's Technology: Open Source newsletter. ]
Of course, others couldn't understand that reaction; one voice said, "Nginx offers premium support to companies it is making millions for, gets hit w/ fountain of nerdrage because they're somehow less free now." But the switch to open core definitely diminishes the commercial value of open source software; "freedom" is not just conceptual. By withholding the flexibility to use for any purpose, study the source, adapt the software, and pass to anyone without permission, Nginx has paradoxically lowered its value.
Why open core is worth less
Consider the general case. When any business uses this model, they have an open source "community edition" of their software product, which lacks many features of the commercial versions. It is indeed freely available under an open source license and fully functional. There will be many happy deployers of this version. If this was the only version available, there would be no issues.
The proprietary versions are significantly different from the community version, perhaps with both the user interface and the functions. While paid licensees are often entitled to source access to this version, the proprietary licence is not perpetual -- if the customer ends their relationship with the vendor, they lose the right to use this version.
Since this version significantly differs from the community version, there is no fallback plan, and while the customer may have access to their data (if the vendor is sufficiently enlightened about open data), there's no software they can continue to use. They are unable to trade time for money, to use Mårten Mickos’ famous explanation -- they are locked in, and the open source core of the proprietary version delivers no freedom to them.
If this latter situation was described as "proprietary" (or avoided association with open source, as for example IBM's WebSphere does in its embedding of Apache HTTPD) there would be no practical issues either. If it's clear you're surrendering your flexibility in return for convenience, that's your choice.
The fact is, the community edition and the commercial editions have disjointed user bases. The community edition is used by a group of people who have the time and skills to deploy by themselves and who have no need of the many differences of the commercial versions. The commercial versions are feature-rich and effectively lock their users into a traditional commercial ISV relationship with the vendor. If these two were kept distinct, there would probably be no pragmatic issue. (Naturally, free-software advocates would still protest the existence of closed code, but that's not a part of this particular argument.)
But a vendor that mixes these two encourages exactly the market confusion that OSI was designed to minimize. If they claim to be an open source business and use the presence of the community edition as a credential to sell the proprietary versions, they wrap themselves in the open source flag and their actions are exactly the gaming of the maturity of open source that I believe should be challenged.
Will Nginx try to wrap itself in the reputation of its previous good open source citizenry while encouraging its customers to do without the flexibility of open source? Time will tell, but I strongly encourage the company to avoid this trap.
This article, "Nginx takes the slippery road away from open source," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.