But open-core shifts motivation of the developers away from something the community at large can profit. Whenever a new feature is debated internally, it will have to be placed in the closed or open bracket. The more complicated the feature, the more likely it's going to be closed. The more time spent on closed features, the less time is available for open ones.
Worse, when people want to submit patches (it's still open source after all), their patches aren't just vetted for quality and whether they fit the overall product vision. They are now also vetted against an internal roadmap of planned commercial features, making it impossible or highly unlikely for a feature on the internal roadmap to ever by accepted from outside sources.
This has a huge potential to diminish the product as it's available for the community at large.
Combine this with the fact that purchasing the pro version isn't really possible without talking to sales (heck - it's not even possible to learn the price without talking to sales), the full product won't even be available for most of us (unwilling to deal with sales people) which makes this even more painful.
I'm not saying I'll be looking to move away quickly, but I think it might be time to start evaluating possible alternatives as they come along.
To add something constructive: I would have much preferred them to move into a service business based on their knowledge about nginx and do something like a cloud flare competitor or other stuff related to serving HTTP, so basically anything they are now using as arguments for buying the pro version, but as a service.
They would still be able to a) use their good name related to the backend technology and b) profit from their huge know-how of the internal workings of nginx to create patches and features for internal use. That would still drain some development time, but it wouldn't be wasted on polish and UI which is needed in this open-core case. :-)
Automattic themselves contribute a hell of a lot of time and effort back to WordPress. There's tonnes of plugins that they've contributed back (http://profiles.wordpress.org/automattic), they often test patches that might break things (with the scale of WP.com meaning they do break, and quickly), and they employ people to work full-time on WordPress. Automattic is pretty much the worst example of a company that doesn't contribute back.
As for the ticket you mention above, that has been deferred because we're still working on the specifics on how to handle that in a backwards compatible manner. This is being handled in a plugin at the moment, with hopes for integration later: http://wordpress.org/plugins/wp-db-driver/
(If there are any specific tickets you want to point to that haven't been accepted, please let me know and I'll re-review them for you. Intense Debate is not an excuse for the built-in commenting sucking, especially since ID is basically dead.)
There is always a "backwards compatible" argument that pops up, but the solution is simple: persons that dont want to upgrade from their 2002 PHP installation can use legacy WP. Everyone that wants a new WP site can just do so using modern server software.
We tried a long-term support branch. It doesn't work with WP's development process, and it's a lot of extra effort. It's not too hard to maintain backwards compatibility on the other hand.
Even automotive manufacturers have to supply parts for cars they manufactured for X number of years after the final production. I hope new 2014 cars don't include parts from the 1940's era for "compatability" reasons.
No 1940s vehicles didn't come with ABS, front and side panel air bags. But linkage in the suspension was at least metal, and wasn't known to fatigue every five years. If I were so inclined I could bring my hick mechanic in here and he would have volumes of corner cuts to cite that have resulted in unnecessary deaths over the years.
Some advancements have been great but overall legacy parts don't engulf vehicles in flames. Hodge-podge workarounds do.
SVN repository: http://plugins.svn.wordpress.org/hyperdb/
SVN changelog: http://plugins.trac.wordpress.org/log/hyperdb/
Yes, it's not on Github (which is a shame), but that's a long way away from being closed source.
It is possible that having a commercial offering, or a way to actually make money off nginx, will simply increase development time over all. Yes, some (most) of that will be towards the commercial product, but if they are making a reasonable amount of money off this, it may mean more time spent on the open version as well.
Also, with the nature of git it is possible for someone, or a group of someones, to fork nginx and run that fork as the 'new' open source nginx. What I mean is someone could fork the repo and if that one is getting enough attention from open source devs, it is possible that the fork would become the recognized version of nginx in the future. Not saying this is overly likely to happen, but it is possible.
From my cursory reading, it actually adds some significant features. Perhaps it's worth considering.
Doesn't seem like we've lost much here. Does seem like we've gained a lot more likelihood that this piece of software will be maintained for the foreseeable future.
From the other side it is a "group o' dudes who freely share" becoming a "group o' dudes who allow a little bit of access but otherwise don't share". If you are big believer in sharing then it is sad they don't want to share anymore.
Clearly nginx has gotten along fine for years without any of these features, but there is a difference between features that are missing because they're not ready yet or a bad idea, which usually have some sort of best practice workaround, and features that are missing because you need to pay. Although Nginx theoretically has a strong incentive to maintain a strong open source version and not make the limitations too onerous, open core doesn't have many success stories in practice. And there's a big psychological difference between "best of class software" and "intentionally limited software".
To reply to one of the children commends, the idea that Nginx does not owe its users anything is a red herring: it doesn't, but in the so far, hypothetical situation where nginx starts to unacceptably resemble crippleware, neither do the users owe Nginx the continued use of its product rather than a competing open source alternative or fork. Your own question, whether it's philosophically better for Nginx to be able to make money this way, is probably the better one to ask. I don't know. For such a popular piece of software, there are certainly potentially viable business models that do not depend on making users pay for features - for example, there are probably numerous companies that depend on nginx enough to employ its developers to work on it, like Linux or Python; alternatively, support (including hotfixes) from the original authors of the code is really valuable, and might make the product worth it for many users on its own. But without that hypothetical situation actually occurring, it's unclear that there will be anything really wrong with this model in the long run.
That said, you make good points. I think it's possible to make it work for them but for this they'll need to have explicit guidelines they apply internally to avoid conflicts of interests when accepting patches for example.
I hope however that the increased amount of revenue they will get will help them finance more development work for both the open core and the pro feature
Selling additional features I feel will generate more revenue for Nginx than just going the support route. It may not be great for those that use the free product now, but I see it as a solid business model.
As far as having to go through sales, I see this product being geared towards IT people, and those that are strictly sysadmin/IT are much more accustom to working with sales reps to buy products they will be using. Not saying I like it, but it's just how things are.
The problem with doing such a move is that it requires a whole different skill set than just being software developers. They would have to be a much more operationally focused company handling all the hurdles that a CDN handles (DDOS, routing, conf mgmt). Besides, it would be a volume game and they would be pretty late to this game.
They don't necessarily have to do "open core" though. How well something works isn't necessarily the measure of whether or not a customer would want a support contract. The real issue is "how important is this application (of nginx) and what's our tolerance for risk"? When customers buy the "enterprise" (or "supported" or "certified") version of an OSS project, they aren't necessarily buying it to get features they can't get otherwise... they're buying it to get the comfort and the risk management and the surety of knowing "if this breaks, there is somebody I can call that will be on the hook to provide a fix". Also, people think things like: "will I lose my job if a I deploy an unsupported OSS product in my enterprise and it breaks? But what if there's a vendor backing it?"
The nginx developers obviously have to make their own decisions based on their knowledge and research and feelings, but I will posit that for many OSS projects, there is no need to go "open core" in order to provide a commercial/paid version.
(Disclaimer: I'm a founder of an OSS enterprise software startup, and am pretty opinionated / biased on this topic).
$1350 a year for 1 server, standard support.
Edit: I realise others have mentioned price, but no URL.
As a developer myself, I do understand that open source alone is very hard to live from, specially when comparing salaries between both worlds (closed vs open).
So I rather have all options available, and won't steer from a product just because it is closed source.
People have been using Nginx, saving money and time over the years. And not paying for a single dollar. And as you see from all these post, No sign, signal or movement of appreciation what so ever.
Now you make enough money out of/with it. They want to survive and charge for some advance features. MOST of it are already being done with a few more simple scripts and manual setup.
And you shout foul. Most of you didn't even need Adaptive Streaming Media Support. And so most of those features in Plus are already being used by you in some way or another.
And if you really did need Adaptive Streaming Media Support, how about paying for it? And if you dont want to pay for it, how about some meaning donation to Nginx for something that you have used and take it for granted?
Sometimes i really do understand why folks swear by GPL, or AGPL.
And if anything, I really expected better, especially from HackerNews where StartUp gathers around. And StartUps are all about creating values, not destroying it.
The responses in here are mixed, but seem to be predominately supporting. A few mention the conflicts of interest that may arise, and of course they should: They're real and should be considered.
I'm not necessarily thrilled at their move either (though I understand it completely) because the automatic expectation is that they're going to dilute the free product and focus only on the paid product. Other commenters have hashed out examples dealing with MySQL and Wordpress so I won't bother restating them.
That said, being GPL or not wouldn't matter because they have the right to relicense their code under whatever terms they like. There's nothing that stops the owner of the code to put out a commercially licensed release along side a GPL version. Example: http://www.mysql.com/about/legal/licensing/oem/
The overall responses didn't strike me as overly negative; most of the people saying "this isn't a good idea" are suggesting other ways the nginx devs could build a for-profit business around it...
Investment to learn some software tool at expert level can easily be $10,000 - $30,000 when you distribute the cost of learning all the details over several years.
This has lot to do with the reason why people start using open source products. They are not just looking if the code is open source just now. What they want is community that guarantees the long life and continued development that justifies the continued investment to learn and keep up with the tool.
I have invested significant amount of personal time for learning to use stuff like Gnu Emacs, Linux, coreutils, C, R, Matlab, Common Lisp in general and SBCL in particular etc. Investment to these things pays dividends that can be measured in significant money. It looks like communities involved are alive and work towards goals I like, so I donate.
I am not however very sure the open core model would work that well, people generally dread it as it tends to be crippleware.
Serious question: can anyone name one open core product that is really successfull?
If I were the people behind Nginx I would make my money through selling my technical expertise and support. Pretty much like RedHat make their money.
On the other side, this would make room for some new projects or for older to pick up some new steam (e.g. lighty, cherokee).
Mysql? Was doing really well even among the OSS crowd until Oracle, and post Oracle still seems to be doing alright.
Postgresql while not traditionally open core, there are a couple of companies that employ core contributors that sell addons fairly similar to the way Mysql used to(maybe still does I haven't looked at Mysql in a while.)
At least this is my impression. At the end of the day I do like Xen and Citrix, they were/are certainly good for virtualisation on linux.
I do not believe that and Apache has saved our arses over and over since times immemorial. Should've mentioned them, but it was kind of implied.
(I'm both an nginx and apache fan, just trying to add some clarity here.)
Ah, ye olde dayes of Apache. Cast my memory back there, lord!
Many of us still are running Apache, as well as MySQL, & even PHP :)
What proprietary interfaces?
Red Hat does have things that are not available to the public (e.g. RH network), but these are more services than actual products (machine management and patching can be managed using Spacewalk these days, and all patches are rebuilt and released by CentOS/SL). There's a bit more leg-work required but RH's whole business is based around adding service value for customers.
The one thing they do not provide to everyone for some reason is signed Windows drivers for QXL KVM graphical devices, but one can sign it himself need be.
The OSS base product is not crippleware by a long shot.
Instead, MirthCorp's main way to encourage folks to purchase the paid version is the lack of freely-available, up-to-date documentation, and getting secure connections working with the OSS version requires either custom code or more sophisticated server admin skills (i.e., stunnel or proxying to get SSL support for incoming connections).
What concerns me most is that "on-the-fly reconfiguration" and "advanced load balancing"  has been introduced as Plus. It feels like they freeze an existing feature for OSS offering and all the improvements on these primary product features will be commercial.
* Application Health Checking -> Nagios
* Monitoring -> stub_status_module + Munin/Nagios
* Advanced Load Balancing -> Chain Varnish / Nginx
* Dynamic Configuration -> Seamless configuration reload without service interruption is possible in the open source version
* High Availability -> Pacemaker or whatever...
That's stuff that high traffic sites have covered themselves. But: Many normal Enterprise IT ops won't touch Nginx with a stick if they can't pay for it and have someone to blame should things go wrong. Plus, managers love shiny dashboards, buzzword features and fact sheets like http://nginx.com/media/cms_page_media/21/nginx_plus_datashee...
Nginx provides more values than hundreds of million-dollars acquihires nowadays.
It is a bit sad though that free software has come to this choice, now needing to maintain a commercial and an open source version, and the conflict of interests that means and the possible diminished value of the open source product.
But alas no other solution than this is really on the table for the developers to actually make money out of something so valuable to society.
Donation-route? Didnt they have that?
Hint: not enough to support yourself + wife + children.
Its mostly private persons, where are the companies making huge profits from nginx?
So its good they do like this with nginx plus, even if the open source version suffers, I wish the developers make tons of money.
So things should just work and if you are able to build a software that is easy to install, start and configure the user has no demand for support.
This product is built with your help. The roadmap reflects services you requested, but in no way would this company ever prevent the scene from offering additional patches, etc. that would serve to better the product itself.
If anything, this should be a welcome hint that this company is seriously looking forward to the future of growing itself into a competitive entity that is vigilant about bettering what services/products it offers.
my interest went from "oh wow I'd like to evaluate this tonight" to "blah. this is sure to be a grating email dialogue."
edit: ..and even though I'd be willing to buy a small license now for evaluation purposes that seems to lead to the same sales trap.
So while I still object to forced-into-sales-inquiry funnels like we were discussing here.. I have to apologize for assuming they'd be bad at it. :)
I understand peoples concerns, but it seems to be the only way for the nginx developers to do what they do best. Donations are clearly not working. It's only reasonable that they want to get a stable paycheck while helping the rest of us getting ours.
But that's got more sales-speak sprinkled in with the technical details.
Not to mention: If you get value from Adaptive Multimedia Streaming then pay for it. Why should they necessarily provide you value for free?
I'm personally getting tired of folks who ride the coat tails of "open source" because they simply read it as "I don't have to pay" rather than getting behind the ethos of what it's actually about. I don't know about your specific situation to say this is the case here, just venting on a pile of comments that are poo-pooing the fact these folks want to make some money from the MASSIVE value they are providing the world.
What about the people who are fine with paying? Where can they get an open source version of Plus?
Pretty sure buying proprietary software is not part of the "ethos". Well, maybe of the open source ethos, but certainly not part of the Free Software one.
Amount of donations on this page: http://nginx.org/en/donation.html is really suck.
Well, they seem to have no stance on that - at least there's nothing on the page. So I tend to assume that pro features remain pro features.
Nobody is demanding that the nginx folks provide value for free. However, I see problems with their chosen business model. The separation of "open source" vs. "closed source" is ill defined. What happens for example if some other party implements a solution that provides the same functionality as a pro feature? Would they accept a PR for that and then provide it as part of the free version or would they just keep the pro-approved version and let the OS-version play catch up? Is it possible to patch the pro version as it is possible to patch the os version? Syslog logging requires source patches atm and it doesn't look like the patch will ever be accepted in the mainline. There's a legal question as well: From the changelog it seems as if other people contributed patches - the implied idea is that they provided patches to an OS project, did they sign a CLA that says they're transferring all rights to the nginx company?
Don't get me wrong: It's fair and square the authors want to make money of their project and they're certainly entitled to. I just see a bunch of issues cropping up.
As of writing, the Contributing page states:
Submitting changes implies granting project a permission to use it under an appropriate license." "license" links to  which states (in part):
" * Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
" followed by standard liability disclaimer.
There may well be a problem agreeing what "appropriate" means. There's an argument that given the link, appropriate could mean a license that allows redistribution in the same way as the current license - which would raise interesting questions for redistributing the nginx plus version.
Certainly it's not a simple assignation of copyright to NGINX. I can easily imagine a lawyer having a heart-attack when reading the original conditions of submitting.
Says the .NET developer with empty github and bitbucket accounts. Meanwhile, there are those of us who live and breathe open source software, building industry-transforming businesses around open source software and contributing to the open source ecosystem. Don't even try to pretend you are anything other than an outside observer.
That argument applies to the software as a whole, not just to a particular feature, right? Isn't it just an argument against open source in general?
rather than getting behind the ethos of what it's actually about
What do you think is the ethos of what open source is actually about? I think part of it is indeed about sharing things with others for free, isn't it? If other parts of it are about the ability to see the code you're using, and make changes to it yourself -- you can't do that with the non-open-source part of this (or other) application either, right?
I don't have a definite opinion on the nginx model, whether or not it's good for the community, I don't really know. Certainly no developers are obligated to write open source ever, everyone can choose to write proprietary software whenever they want (and sometimes it's good for the community and sometimes it's not). But your argument is silly.
Not everyone is on the world for money.
This wouldn't work. Paying corporations tend to be fairly conservative on the features they use, so it's not necessarily the new features that people are willing to pay for.
Having stable revenue means the ability to spend 100% of the time working on the project (instead of it being a side project), and hire more full-time employees. It is possible that as a result both the pro and open-source versions improve faster than in an only-volunteer open-source project.
An alternative strategy to ensure it to do so in the future, could be to build a team of open source contributors to take charge of the further development of the project. As a user, I would prefer this, as it doesn't have the inherent conflicts of interests that a premium/free model has.
Mainline Nginx is still available while this seems to be a value-added product with a bunch of extras.
The cheapest is $1350/yr/server. For that you get... remote logging? Configuration reloading? Oh my...
Zero downtime deploys? Is that a thing people care about? If you don't have server redundancy, having zero downtime deployments might be nice, but sooner or later you are going to have to reboot that machine, or you'll deploy broken code or bad configuration. Then what? If you do have server redundancy, zero downtime isn't even a feature. Not to mention, while nginx might have zero downtime, it's a fair amount of work to build an application that can be deployed with zero downtime. Maybe people are using nginx as a load balancer? If they are, and downtime really matters to them, they are seriously fucking up.
I expect a lot of corporations to pay this just because of some policy that they have to have support contracts in place for everything, but honestly, this is redunk.
I am using Apache webservers behind a fronted running Pound proxy (www.apsis.ch/pound). Pound is mind-bogglingly easy to setup and use, anyone looking for an Nginx replacement should really start there.
Over the last week or so been learning about nginx as a possible solution to serve up compiled JS apps. Rails asset pipeline is just too slow - especially on heroku.
I've been working on my first real open source project - an nginx buildpack for Heroku/Dokku/Flynn optimized for static JS sites: https://github.com/cpursley/buildpack-nginx-js
Open Source works because the motivation is purely based on making the best product possible. Once you have this open core model, the stronger motivation is on the money making side of things. This means likely the free version will stagnate.
I actually think this is quite a good way to fund nginx.
"Red Hat Enterprise Linux (or RHEL) is a commercially supported derivative of Fedora tailored to meet the requirements of enterprise customers. It is a commercial product from Red Hat which also sponsors Fedora as a community project. Fedora is upstream for Red Hat Enterprise Linux but there are several other Derived distributions available too."
Since Nginx Plus will not be open source I do not see how this is a valid comparison.
You might not argue RHN is the feature, but what I understand from sysadmins the RHN subscription is one of the key features, in addition to a few others.
So, it is not the same level as Nginx Plus, but you must be kidding me if you believe RedHat is 100% open-source.
There SRPMS are open source because they have to be, not altruism.
Disagree. I think RH opensources a lot of products because they really do believe it's better (whether that be for "the community" or simply their bottom line). Look at how many (large) proprietary software systems RH has opensourced: Satellite (Spacewalk), SPICE, RHEV-M (oVirt)
Having said that, because of chance or who knows why RH did a great deal of good deeds and they are literaly one of the locomotives pushing the open source train, if I may be permitted this metaphor.
Getting back on topic, if Nginx did as RH does and released the source of what they do so a "Centos-Nginx" or "Fedora-Nginx" can take form then I'd be happy with that.
unfortunately it's not available for cluster compute/HVM instances, so I can't compare it with our existing nginx deployment.
Other than that, I haven't seen external connections to Amazon break 5 MB/s, but that might just be me renting cheap instances.
note that i'd totally pay for support - its the closedness that bothers me.
So why didn't you? Nginx Inc. had support available for some time.
Either way I really can't vote these kinds of people down enough.