I love how your comment drips with derision for everyone not willing to pay $3675 per year per instance as they're just a mere insignificant hobby site.

I'm sure you like your site, but to be honest anything that doesn't make at least $3,675 per year is not a business, it's a hobby. Nobody said that hobbies are insignificant, they just don't (necessarily) make money.

If it were $3675/business/year, I might agree. But $3675/server-instance/year is insanely expensive for many very real businesses. That's $300/month! Imagine a business like Shopify, but with one server instance per customer. No way can you afford to do that if you have to buy nginx pro for each instance. Unit economics still matter to lots of businesses.

That said, you can run quite a big site without any of these features just fine. Also nginx is open source and you can implement these features yourself, either using C or Lua, relatively easily as well.

nginx is a reverse proxy. You're not meant to be running dozens of instances, you're supposed to stick one instance in front of a whole collection of application instances. Your nginx costs don't scale with your server load, they scale with your infrastructure complexity.

Nginx is a lot more than a reverse proxy, including a not too shabby static resouce host. In fact Netflix hosts their videos ultimately from Nginx.

You're saying anything that makes under $4k a year isn't a business, but you're using it to justify that anything that makes under $8k a year isn't a business. Because you're earmarking those profits to go to a vendor, which then are not profits.

Are people not entitled to make $300 a month because they owe Nginx for a bot throttling feature? Can you run a small website without throttling these days?

> Are people not entitled to make $300 a month because they owe Nginx for a bot throttling feature?

Where is this attitude of entitlement coming from? Are people entitled to use Nginx's code for free? Yes, free software is a wonderful thing, and I do believe that most software should be free. But the reality, in this world, is that software developers need to eat, and relying solely on donations only works for a handful of projects (as does relying on selling support). Open-core is a reasonable middle ground.

If somebody wants to reimplement that feature on top of Nginx and release it under a free license, there's absolutely nothing stopping them. If you want to use an already written and well-integrated version from Nginx themselves, then you can pay up.

On the other hand, though, why does anyone believe they're entitled to a bot-throttling feature for free?

Certainly someone could write and release a third-party, open-source nginx module to do bot throttling, if they wanted to.

Profit is the difference between hobby and not?

Non-profits are not hobbies.

I didn't say anything about profit. Non-profits do (and should) make and spend money, too.

Charities should make money?

Best to you.

It's one cost of so very many these days.

These prices (per instance!) add up; there are many other pieces of software clamoring for their share, hardware costs, networking costs, labor costs. It's death by a thousand cuts.

It's not a significant amount of money for any business that gets this amount of traffic. Being this stingy on software your business relies on deserves derision.

Big Same feels from me as you. I watched countless good things at Heroku get locked behind enormously expensive “enterprise” contracts.

No personal offense intended, but I really /hate/ this justification. "Open Source" should not be equated with "Hobby Projects". It should be possible to run large-scale important things on pure open source.

My employer (Wikimedia, which is a non-profit) has been running all our server infra on pure open source for many years, for very principled reasons. We even publish all of our internal infrastructure config in public git repos as well. We're an open-source-only shop that's doing very non-hobby work. We have thousands of servers, we run our own CDN on multiple continents, we have somewhere around a billion unique users per month, and our average global rate of inbound HTTP requests is around 135K/second.

However, it keeps getting harder to stick to our open source principles every year as more projects shift towards open-core models with this kind of "Anyone who needs feature X is surely a big corporation making billions who doesn't mind running closed source software" type of thinking. It's not just bad for us, it's bad for the whole larger open source and Internet ecosystems if all the important bits for running at scale are locked up and hidden away in closed-source software.

This is a rather weird point to make, considering the way Wikipedia has handled the collection and usage of funds. Investing in its technical infrastructure would be a less controversial usage of their money than what they are doing currently.

What are they currently doing?

As a theoretical exercise, I'm not sure that's strictly true. If you're reliant on donations, then income is never guaranteed. If you suddenly fall short of targets, maybe you have to lay some staff off. But stopping your license fees means you then have to pay someone to switch to an alternative.

Avoiding recurring payments you can't easily stop makes reasonable financial sense to me. Particularly for a business that doesn't sell anything.

Let’s say you need a feature in nginx. You can either pay for an nginx plus license, or fork the oss nginx and develop the feature in-house.

Many people assume that developing it in-house is a one-time cost. However, in my experience, code is not an asset but a liability for which you will have to pay interest in the form of maintenance. More specifically, in this case there will most likely need to be adjustments made to the in-house extension as the oss nginx version it was built on top is being updated over the years.

My point here is that you should probably treat in-house code as a recurring cost, because in practice it usually is.

The question then becomes which recurring cost is higher: The license or the in-house maintenance?

As a theoretical exercise, you could also choose to "lavish" funds on the developers of the OSS platform instead of a recurring license fee for use, accomplishing a more outreach oriented use of funds than paying non-profit "employees" north of market with remarkable packages. If funds get tight, you can simply stop laving on the OSS, while enjoying ongoing use. Such a license can definitely be arranged -- I've done it at scale.

You are very much the exception that proves the rule. What other non-profit needs anything close to that kind of capacity?

The NFL was a non-profit from 1942 till 2015.

I wholeheartedly agree with you, and I am so glad that wikimedia is pushing to stay truly open source.

Accepting these "sprinkles on top" licenses is highly foolish. I do hope that the true free and open source licensed software prevails in the server space. As many as possible must continue to hold out and push forward with new better and better scalable fully open source software.

AFAICT nginx has a true open-source edition, which anybody can fork. Was there enough interest in the community in developing SCH features in the open-source code base?

> My employer (Wikimedia, which is a non-profit) has been running all our server infra on pure open source for many years, for very principled reasons

Curious how deep does it go? Do you only use firmware in server which has open source code. Do you require all drivers to be open source?

> It should be possible to run large-scale important things on pure open source.

It is definitely possible. With enough developer time, you could create copy of any software. Every paid or open core software runs on the philosophy that it is cheaper to pay them rather than to build them.

Which brings to the core issue, developer time is not free or cheap. The fact is that software quality and reliability is dependent on the money that the software has means paid software quality in general should be higher. While wikimedia could get enough money through donation, no one donates to open source projects that could be counted in full time developer salary, likely not even wikipedia(correct me if wrong).

Most large projects make money. Wikipedia is one of them (they have more than sufficient funds). If you are a company that writes open source software you have to earn money somehow. I think aiming paid features at customers that make money (i.e. large enterprises) is logical.

Have you tried contacting nginx and explain the usecase/problem as you did here? A lot of software companies have different or free licenses for cases like yours.

In Wikimedia's case it's more likely a matter of principle than cost. They have plenty of money despite what the donation popups make it seem. They want open source because it's open, not because it's cheap.

DevExpress is closed source, but they give sources to customers under a promise that they won't leak. Maybe nginx can do something like that? Or openresty has a module for your needs?

This is called “source available”,l and is not the same thing as “open source”.

https://en.m.wikipedia.org/wiki/Source-available_software

In case they worry there's something horrible hidden there.

You are correct, but you are an outlier. The vast majority of organizations who are serving the quantity of requests trust Wikimedia is serving, are commercial entities.

nginx opensource is more than enough to have a very capable solution. All bells and whistles that are fenced off are more or less for people who don't want to bother engineering their infrastructure properly. Or can't do that for a reason. The only thing that may really be needed is name resolution inside an upstream. But you can work around it in many cases. If there is something you need in OSS - consider asking in a mailing list. Best case - you'll have a workaround (an unlikely outcome: feature will be moved to OSS). Worst case - you lose nothing, don't you? It's quite difficult to get a decent feedback on a thing like a webserver. You can't add a pop-up window or email your users. You have to rely on an active feedback. A vague comment somewhere in the internet doesn't count as such.

I like to overbuild my own things as a way to build a skillset, and I've basically only been doing that on software where only extremely specialized features are gated (e.g. Vault's HSM service, can't justify to afford one of those anyway).