3 ms·
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
by jasonkester 13y ago
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.
- stonemetal 13y ago>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.
- FooBarWidget 13y agoSharing 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.
- zzzcpan 13y agoIt is two-way exchange, but common, have you tried to contribute? They do not accept anything and neither are open to talk about it.
- FooBarWidget 13y agoYes I did. I contributed the ability to listen on unix domain sockets, and it's been part of nginx since 0.8.
- comex 13y agoNot 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.
- deleted 13y ago[deleted]