I fully appreciate the need for the developers of nginx to make money and I can understand that moving to what essentially is open-core is probably the only way for them to actually make money out of nginx (the thing works so well that selling support contracts probably won't do).
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.
edit:
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. :-)
Agree on the motivation, and you see this with Automattic/Wordpress. They haven't touched or accepted tickets into commenting or ORM in quite some time, because they've "fixed" it as they think it should be in outside projects (http://www.intensedebate.com/http://wordpress.org/plugins/hyperdb/). While these are "free" (for now), they're closed source so that they can do as they wish with them. The great majority of WP commenting code is 3-5 years old, and they keep deferring this DB ticket (http://core.trac.wordpress.org/ticket/21663) despite the drivers they use (mysql_*) being deprecated in modern versions of PHP.
Actually, Automattic is completely separate to WordPress as a project. While some of the commit team are Automattic employees, most aren't (at least of the active ones; there's a few that work mostly on Automattic internal projects).
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.)
I believe the point was that WP is lagging behind the times. A developer that works with modern frameworks and looks at the WP codebase will quickly ask themselves "Why"...
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.
> 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.
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.
Correct. But the quicker you stop working with legacy code, the quicker the cutoff can be.
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.
I hope they do. There is an obscene amount of integral parts in automobiles that are made out of poorly formed plastics. Not only do a higher number of parts fail, the manufactures making replacements often follow the same flawed construction.
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[1].
Counter Argument: (Not saying I disagree, just a different point of view)
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.
This is exactly what happened to the Phusion Passenger application server (available as an addon for Nginx). Since the release of our (paid) Enterprise version we have a lot more resources at our disposal, and development of the open source version is now faster than ever before. Before releasing Enterprise we would make our living by doing consultancy but that slows down development even further. I'm very glad we decided to release an Enterprise version.
I think MySQL's three copyright owners (with a heavy emphasis on Oracle) gave open core a bad reputation. I like reading stories like this because I think it's important for there to be different business models for open source.
Surprising to see this (not at all uncommon with OSS folks) preference for "group o' dudes" over "group o' dudes with enough money not to need to take day jobs and a tangible motivation to work hard on this particular product." Especially considering that their list of "closed bracket" features seem to all be things to support their hosted service rather than webserver functionality.
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.
>Surprising to see this (not at all uncommon with OSS folks) preference for "group o' dudes" over "group o' dudes with enough money not to need to take day jobs and a tangible motivation to work hard on this particular product."
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.
Sharing is only fair if it's a two-way exchange. How much code have most people contributed to Nginx? If they don't contribute code, then how about donating money? Oh hm... the donation page doesn't look so impressive.
Not all of them - in particular, "on-the-fly reconfiguration" and "adaptive media streaming" sound like useful webserver functionality, although it's hard to tell without more technical details (the absence of which is somewhat grating).
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.
The price is written on the website $1,350/year for the standard subscription.
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
It's a different world now, but this is similar to the transition Snort went through over a decade ago. It started as an open-source piece of software, but then the creator of it formed a company around it, and started to add on value-add features and provide support. The OSS of Snort still exists today and a lot of people use the free version of it. There arguably a lot of features in Sourcefire's paid products that could be integrated into the free version of Snort, but they aren't.
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.
I fully appreciate the need for the developers of nginx to make money and I can understand that moving to what essentially is open-core is probably the only way for them to actually make money out of nginx (the thing works so well that selling support contracts probably won't do).
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).
I can only speak for myself, but i've found their Wiki always to be extremely helpful and for the most part, i can't seem to think of an occasion where i couldn't find what i've been looking for..
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.
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.
edit:
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. :-)