Also note that we’ll cover the open source version of the Nginx, not its commercial version with additional features.
It always kills me when very successful companies don't buy software from other companies.
I remember being at a lunch with a prospective client that really loved our technology. About 1/2 way through, he said he really would love to purchase our software, but the CEO doesn't allow them to use anything but OSS. What they make? Non-OSS software.
In a business context, I'd definitely consider paid support for an Open Source product. But I'm not interested in a proprietary version that I can't modify or get third-party support for or otherwise work with in a pinch; I'm certainly not going to make a business dependent on it. Push the proprietary version hard enough and I'll reconsider whether I even want to use the Open Source version, or if it might be on more tenuous ground that might get undermined in the future (pushing back on improvements to the Open Source version to maintain differentiation, or worse, deciding to switch to a non-FOSS license in the future).
> Push the proprietary version hard enough and I'll reconsider whether I even want to use the Open Source version
Qt is pushing hard for commercial licensing (which I heard prevents you from using the open-source version), putting L/GPL FUD on their websites, and trying to track users of their installers more.
The model of "copyleft if your project is open, pay us if your project isn't open" is one where I have no problems or concerns, and will happily use the open version and recommend that people building something proprietary purchase a paid license. Nor will I typically worry about the motives or future of the project unless I have some other reason to. And the KDE Free Qt Foundation means I never have to worry about Qt going proprietary.
Does anyone know a good license for that? Maybe the Prosperity license?
EDIT: I've just realized that I want a revenue-limited trial, rather than a time-limited one. I basically want the Prosperity license, but with the ability to say "you have to pay me if your company makes more than $100k in annual revenue". Is there a license like that?
I've emailed the License Zero people, hopefully they'll do something for that.
The "that" in question was "copyleft if your project is open, pay us if your project isn't open". For that, try the AGPL or GPL, depending on your use case and customers, and then sell alternate licenses for people who don't want to make their own code open.
> Maybe the Prosperity license?
That isn't an open source license, despite its efforts to be ambiguous on that front. That and the even worse "commons clause" are exactly the kind of license that motivated the latter half of my original comment at https://news.ycombinator.com/item?id=24005833
The Prosperity license seems like a better fit to me, as the GPL/AGPL has a different set of constraints (e.g. customers who want to keep their code closed).
What's wrong with a license that's non-OSI "open" but gets developers paid from large companies to develop otherwise open software?
> The model of "copyleft if your project is open, pay us if your project isn't open" is one where I have no problems or concerns, and will happily use the open version and recommend that people building something proprietary purchase a paid license. Nor will I typically worry about the motives or future of the project unless I have some other reason to. And the KDE Free Qt Foundation means I never have to worry about Qt going proprietary.'
Software under a proprietary license is something I can't build other Open Source software atop of that I expect other developers to use and collaborate on. I don't want to have a forked ecosystem of proprietary-with-source-available software, I want to actually collaborate on Open Source software.
With Open Source, I'd feel confident that if we had to manage it ourselves, or fork it and add a patch, or get a third-party to develop a patch, or work with a dozen others with the same needs we have and collaborate on it, we can do so. It's reasonable to build an ecosystem or community or company around. You cannot replicate that with any non-open license; by the time you're done granting all the necessary rights, what you'd have is a non-standard-but-Open-Source license, at which point you'll get more traction if you use an existing well-established Open Source license.
I don't really care about encouraging the development of more proprietary software, whether or not it happens to have source available. There are already well-established models for getting people to pay for proprietary software. If someone is looking for a funding model for Open Source, and what they find is "turn it proprietary and generate FUD that it's as good as open", that's a failure. And when people are looking for Open Source and they find proprietary-with-source-available, it undermines decades of careful work and explanations by the FOSS community, and generates substantial confusion.
It's your software, and ultimately your choice how to license it. Various companies have tried the "source-available but still proprietary" model. Just please don't call it open or contribute to the FUD around proprietary-with-source-available licensing.
Speaking from experience, when encountering software under a proprietary-but-source-available license that tries to act like it's open, the response from companies that actually deal in Open Source is not "Ah, OK, let's pay them and use it", it's "yikes, get this away from us, how did this even end up in consideration, let's either use something Open Source or use something actually proprietary, not something by someone who is either confused about the difference or hopes other people will be". (The set of engineers and lawyers who deal with software licensing professionally, at various companies, tend to talk about it with each other.)
That makes sense. Unfortunately, as someone else in the thread has mentioned, the ways of monetizing OSS misalign the incentives between user and developer, and they haven't really been very successful anyway.
I develop multiple popular libraries that thousands of people use, yet I've never seen a single cent from them, which is fine for me because I don't develop them to make money. However, it's really hard to foster an ecosystem when companies who extract millions of dollars of value from FOSS don't feel like they need to give back.
> Unfortunately, as someone else in the thread has mentioned, the ways of monetizing OSS misalign the incentives between user and developer, and they haven't really been very successful anyway.
Many ways of monetizing it don't misalign incentives. As a user, I don't value support less just because software is more reliable; on the contrary, I trust the software in higher-value contexts because it's reliable, and in those contexts I need the support more. I don't value "host this for me" less just because the software is easy to install and configure (because I still don't want to be the system administrator if I don't have to). And "please develop this feature for me" has great alignment of incentives.
> However, it's really hard to foster an ecosystem when companies who extract millions of dollars of value from FOSS don't feel like they need to give back.
You're a lot less likely to get paid for software that's under an all-permissive license (e.g. MIT or Apache or BSD). It's unfortunate that so much of the ecosystem has settled around permissive licenses; with such licenses, your best strategy for making money may be "use the software to get hired somewhere or to build reputation for consulting". There's a reason companies love permissive licensing, and subtly (or unsubtly) discourage copyleft. Strong copyleft gives you more options to monetize something, either now or in the future.
That said, I also do agree that there need to be more good ways of funding Open Source.
Maybe you're right, I do tend to choose MIT/BSD usually. I think I'll switch to GPL, though I don't entirely agree with your first paragraph (I am less likely to pay for software if I can host it myself, for example, though possibly not by much).
Not sure but I think maybe they were mixing up profit vs. revenue and pointing out how a company can ensure it has zero profit. But I guess you'd also have to be careful about which entity or sub-entities are covered by a license and the revenue limits.
Unreal engine charges a 5% royalty on sales after the first $1M in revenue. And source is all on github, so it's basically zero friction until you get big.
I’ve been using Qt/C++ for a few months here and I’m really really impressed. It’s really nicely done, and the performance is fantastic. Honestly, I’d have probably considered Electron, but the software runs in a somewhat resource constrained environment and has pretty significant soft real-time processing requirements (the C++ part)
If the licensing model asks for companies to pay for the "Enterprise" features which are still OSS, it would resolve this problem for me at least (not sure about the OP).
In general, its been my experience that the closed source enterprise only crap that most companies push for is exactly that: crap. I suspect its because those features are treated as a business expense, and thus built to keep costs low. Almost every time those features are underwhelming and buggy.
If its OSS, at least I can contribute a patch; if the thing is popular, likely someone else has already fixed it.
Enterprise support is a fucking joke; they will delay delay and delay. If you push hard enough, they say "its on the roadmap" without giving any gurantee of when it will be fixed. The only time Enterprise support has really worked well is in my org that got the best support package for GCP. GCP's support for urgent issues and product feature requests has been somewhat reliable and predictable. Much more than literally any other enterprise (I'm looking at you Okta).
- we had requested some way of being able to remove IAM permissions that went stale. GCP introduced a “recommendations” feature that indicates which IAM roles have been unused for a long time and can safely be removed.
- we requested a way to prohibit the provision of ILBs on shared VPC subnets without explicit grants; GCP introduced a role for that
- we had issues with the number of compute instances being too high on our VPC and reaching limits because of the number of vpc peerings. In the past, every GKE cluster created a new peering. We have a bunch of GKE clusters, and as we added more the Max number of instances we could provision was reduced significantly. GCP introduced and fast tracked a feature that enabled all GKE clusters to use a single peering rather than create a peer per GKE cluster.
There’s a bunch more. But on this front I have been a happy customer.
If you're saying "source-available" as opposed to Open Source: complete non-starter. I'm looking for Open Source, not a faux knock-off of it; don't try to give me a subset of Open Source license terms that you think would placate me while not actually being open.
I think a part of this is that engineers in particular have a preference to use software which can be treated as a transferable skill if/when they move on. They would rather use the OSS version of Nginx, of Envoy, because they know they will have access to it in the future. I think there is some aversion to becoming familiar with the features, functionality, and characteristics of a piece of software that your current employer is paying a non-trivial amount for, when you know that chances are your next employer will refuse. This may not be in the best interest of the current company, but it's a bias that I think impacts a lot of engineers.
You can purchase the commercial version of Nginx and not use its specific paid feature subset. Alternatively, "I am familiar with this, and we can do x% of what we need with the OSS version, but we had to pay to get the last part."
I see what you're saying, but this is basically suggesting that Dropbox should have made a donation to F5 (a public company with an $8B market cap).
I think there is a valid point you're making for smaller companies that are providing both open-source and commercial versions of software, but I don't think Nginx is a great example of that.
Why does it blow your mind? Various obvious and sane reasons for this, including cost. I bet many of those companies you have in mind “buy” Windows and macOS, and if they are sufficiently big, most certainly buy Oracle or SAP for their corporate operations, finances, and accounting. It’s usually only the production side of sufficiently large internet-scale companies that is biased towards building. Most of the time you can easily explain it with “it’s cheaper than the contract with supplier”. Often, it is strategic ownership over your fate and not being locked into the vendor that comes into play as well. The vendor positioning in the market and its leverage may also change over time and pose a risk down the road (getting acquired, changing focus, abandoning the product, going out of business, etc.) Many times it is just that their problem is so unique to their scale that the generic solution does not technically work for them or the pricing model is not designed to be a fit.
In the particular case of nginx, I can tell you their reputation is not great in adapting to the users’ needs.
I think the point was a financially successful company not contributing to an open source project even after making a bunch of money just seems un-ethical? Maybe I'm old-school but I still think we should be supporting each other in this type of situation especially if one of us strikes it big? Sure - move away from Nginx but maybe throw some $ their way for the service they provided even if you don't legally have to ...
I did not infer that from the OP’s comment, but in any case, I don’t know the specifics of their arrangement or whether they had been a commercial customer or not. Last time I checked Nginx had been doing fine selling itself for half a billion.
But more abstractly, I don’t actually agree with that sentiment. I see more of a responsibility to give back in the form of patches and collaboration than throwing $ at the problem. I see the nginx approach of open source simply as a business tactic no different from Windows Home/Pro customer segmentation except Home is free for tactical reasons to kill off other competition. It is a calculated business move; if your business model sucks-—which it obviously did not in nginx case—-does not imply others are acting less than ethically or they should pay you out of pity. (That said it might be strategically important for them to keep your head above water and survive for their own benefit as their vendor, but that’d be a different angle.)
I suppose the difference between free software vs open source is also relevant to this discussion, and I could relate to your sentiment when facing the former much more than the latter.
Patches and contributions take a non-negligible amount of time and resources to review, test and integrate, as well as adding to the ongoing maintenance burden. They might be welcome, but they are absolutely not cost-free and I wouldn't consider them a "form of bill paying", the benefit (if any) is far too indirect and it doesn't directly help the bottom-line in any way.
Something should pay for the bills and if the oss project creates lots of real value then I would prefer to live in a world where some of that value goes to pay the bills. The alternative world simply discourages oss since devs would have to work other jobs. There is qualitative difference when you have a dedicated core team vs just everyone contributing patches.
Could it be that OSS is simply not a sustainable business model for the long haul and it was simply successful in a period of history when vast money was made quickly by landgrab expansion of technology to consolidate/provide many basic services and the code itself wasn’t the competitive differentiator? I don’t know but that’s a possibility too. I question why one would be concerned in keeping OSS alive, as a business, assuming it cannot survive on its own feet. There’s no inherent reason OSS should somehow forcefully live. It’s already changing its character via AGPL and Mongo license-style things in the face of AWS cloud simply deploying and milking cash.
(The above is assuming the concern that it is funding that’s a problem today; I don’t quite see it that way [for instance, I strongly suspect Nginx to have made more money than DBX so far, so who are we to say who’s been more successful; market cap ain’t everything], but that’s a hypothetical to think about.)
Moreover, supporting a project does not equate supporting its existing maintainers. It could mean taking some partial ownership including the review side and having some developers on your own payroll. Seems like that’s how the big project are done most of the time. The Open Core model we are focusing on is a niche and arguably more akin to fremium products than free software as a thing with communal ownership.
OSS is not a business model, but more closely matches charity and non-profits, and run on donations and altruism of their users.
i find it annoying that people here keep saying that a company _should_ pay for their open source software usage just because they have money to do so. They don't have an obligation. They could donate - and some do - but it is in no way required of them, regardless of how much value they derive from using said OSS.
Open-core projects, which has a somewhat useless core and a paid for 'enterprise' version is not, under my eyes, a proper OSS project, but instead is a way to market their proprietary product.
The serendipity was GPL getting uptake thanks to Linux and GCC.
Linux via the ongoing lawsuit with BSD back then, and GCC because UNIX vendors started charging for their compilers, with GCC being the only alternative available.
However everyone needs to pay their bills, therefore the push for non-copyleft licenses, thus in a couple of years GPL based software will either be gone, or under dual licenses.
You already see this happening with BSD/MIT based alternatives to Linux on the IoT space, NuttX, RTOS, Azure RTOS, Zephyr, Google's Fuchsia, ARM's mbed, Arduino, ...
>> "There’s no inherent reason OSS should somehow forcefully live"
What on earth does this tirade even mean? Every business lives 'forcefully' and fights for survival. Sometimes it comes with values, i.e. we dont use child labour in DRK to mine thallium, fairtrade, organic, etc. OSS is one of those values.
For what’s it worth, many companies have a hard time justifying “unnecessary” expenses to their boards or shareholders. Depending on company structure, their hands may be somewhat tied.
Not all companies, of course; and to be clear, I think such a company structure is a problem itself and agree with you.
I think you'd be hard pressed to find a board or shareholders who think 'support contract for essential component of our infrastructure' is 'unnecessary'.
The subject of monetizing opensource software is a tricky one. Some companies pursue the Open-Core principle, others monetize through the consulting services or cloud infrastructures.
As for investing into opensource, Dropbox is trying to do that when possible, for example we (along with Automattic) did sponsor HTTP/2 development in Nginx.
> - Consulting::: Ease of use is ignored, as if it's too easy people won't need consultants.
Some problems can only be made so easy. Some problems require custom work. Sometimes you need paid support not because the product is low-quality but because you need to know that you can call someone at 3am because your service is down. There are lots of reasons to have consulting.
> - Sponsoring Goals::: Software is almost held at ransom, until goals are reached.
You're assuming the work would get done one way or another. Sometimes people have many other things they could be doing, and they need to justify spending more time on a project than they already do. Or sometimes, people have a fixed amount of time but they're happy to prioritize things people want and will pay for.
(No argument about open-core; that definitely has problems.)
Other great approaches include hosting the software as a service. Depending on the nature of a project, many people may want a service whose primary value proposition is "we'll host this for you so you don't have to maintain and administrate it".
From my (admittedly) limited experience, paid support isn't consulting.
Paid support surely is, as you say, about calling someone at 3am and having them look into an incident.
From my experience, that's not about helping you get the most out of the product, and a hand in tailoring it to your needs - that's the consulting part, and is usually paid for separately (and at much higher rates).
You can just charge companies that make over a certain amount of annual revenue. Then OSS and small companies can use your software fine, but when they get big they have to pay you.
Do you have an example of sponsorship goals actively gating software development? I haven’t seen this one. “I’m not patching this zero day until I get to $1,000,000!”
I suppose, but you know you’re what you’re buying when you sign up for RedHat. I was trying to imagine a scenario where free OSS project does that, like Kubernetes or React.
Disclaimer: I work for Red Hat but opinions are my own
I totally disagree. Red Hat patches/maintains things regardless of whether people pay for it. Everything is always available open source. There are numerous derivatives of RHEL that get these for example.
The money you pay for Red Hat stuff is for support. There are always free-as-in-speech and free-as-in-beer alternatives of red hat products.
It's not necessarily about money. An engineer can burn through tens of thousands of dollars per month in cloud spend because they have access to the AWS [or] GCP console, but that same engineer may not have the first idea about how to get the CFO's sign-off to purchase a license that will facilitate a halving of that spend. And that same CFO can institute a policy against using credit cards for recurring payments that prevent that engineer from expensing the purchase through a corporate card. And the software company may not offer a bill-via-invoice option — or they may only offer it for amounts greater than the amount the engineer wants to spend.
So much of what happens in sufficiently large organizations has nothing to do with profit maximization. Think confederacy of dunces, not a conspiracy of greedy evil geniuses.
Exactly my thoughts when I read the article - a hugely successful company not contributing to an open source project which enabled them to succeed in the first place ...
There are different paths companies take. Some buy and it really works for them and their business, since overhead is small and everything just works.
The other set of companies have more sophisticated requirements: when they want to have full control on what is going on, understand what the code is doing to better optimize everything else around it, faster shipping cycles and being able to implement what you want with out waiting for the next shipping cycle with commercial software, community and knowledge base around it etc.
> when they want to have full control on what is going on, understand what the code is doing to better optimize everything else around it, faster shipping cycles and being able to implement what you want with out waiting for the next shipping cycle with commercial software, community and knowledge base around it etc.
I'm a bit confused by this - I work for HAProxy Technologies and we do have an enterprise product. Many of our customers contribute code directly into the community and we backport those features into the latest enterprise stable version. This means they do not have to wait until the next shipping cycle to take advantage of a new feature. There's also a large community & knowledge base around HAProxy.
Your reasoning may be right when dealing with "closed source enterprise software" but it doesn't line up when we start talking about open source/open core.
Shipping cycle is one of the reasons mentioned. And as you can imaging, unfortunately, contributing to Nginx open source is not an easy thing (but they have a great product for sure). If HAProxy is different in terms of contributions - it is great!
What stops them buying commercial licenses for Nginx and then using the OSS version? They're not obligated to, certainly, but I hardly think Nginx would say "you must use only the commercial version".
Just speculation, but there are motives to not use the closed source version beyond purely profits driven point of view. One of the prime benefits of OSS is that you have the power to change it whenever necessary. If something is breaking bad- you might not have the luxury of waiting on support to track down and fix your problem. If you don’t need the features of the paid version- then using the paid version is actually limiting your options.
I don't see what's surprising -- companies that earn money selling product can make even more money by cutting costs. And if OSS software gives them an equivalent (or even better) solution, why wouldn't they use it? For any sizable production deployment, the cost of nginx licenses could be applied to hire a number of engineers to help maintain the OSS software.
I don't know what their volume licensing is like, but at $2500/server list price, costs add up quickly.
If you buy something or worse you have to pay license fees on a regular base your earnings will be smaller.
We live in a world that is driven by economic growth so the ultimate goal is to maximize profit.
Of course this has a moral aspect to it as well and I see it but in this case I think it is not outraging enough to be something on the scale of a scandal.
Many businesses use ideas or products for free to start a successful enterprise that earns a lot of money.
This also rubbed me the wrong way. As an individual I think that shows selfish and opportunistic behaviour and it raises a red flag about that organisation in my mind.
However, for profit companies are not here to do what’s “correct” they’re here to make money for its investors. If I had decision making abilities at Nginx I’d be conducting a comprehensive review of the free OSS offering and redacting the features and overall value with extreme prejudice.
Dropbox never paid because it COULD not pay. If you have an enterprise, paid version of your OSS product it has to be impossible for an enterprise to use it for free.
> If you have an enterprise, paid version of your OSS product it has to be impossible for an enterprise to use it for free.
Why? Most enterprises, especially ones that aren't tech firms, are going to shell out for enterprise support even if there are no additional features. Crippling the community version doesn't necessarily help enterprise sales, it can reduce overall mindshare reducing enterprise traction or, worse yet, mean that a third-party downstream edition with richer open-source features becomes dominant and it's creator gets “your” enterprise support contracts.
> shell out for enterprise support even if there are no additional features.
i don't feel this to be true.
Also, an enterprise that's large would want some features that are irrelevant to a small shop. For example, single-sign-on integration with various providers.
I do though ... Imagine a manager being dependent on a system he ~~bought~~ installed for free, which he didn't buy support for, and is now malfunctioning. It's his fault. And this is what I've seen in practice as well.
Just think about the commercial success of SUSE Linux?
If the said company has unknown track record, then doing business with them is risky.
What if the company goes out of business in near future? Or get acquired (actually I think A lot of infra companies's end goal is to get acquired)? What if they raise the price out of sudden? How extensible/customizable their solution is?
The trust is the key here. If I am in the position to buy software from somewhere and cost isn't the primary concern, the money would goes to a known/stable figure in the industry.
I’m increasingly concerned about being screwed by non-OSS vendors. Imagine a use case like Slack. Say you have an employee that goes to visit a family member in Venezuela & connects to the company Slack. Slack has been given a mandate to terminate accounts for people in Venezuela by the Trump administration, and now your key employee is cut off from communication, or perhaps your Slack account gets flagged.
Business is motivated to avoid anything which is a tax. Said another way, they are motivated to avoid or escape from anything that grows in line with earnings. If their infrastructure grows, their bill from nginx will grow, modulo the skills and efficiency of their infrastructure teams and the speed of whatever servers they are buying.
You have a good problem. What sucks is when you sell a foss solution and they want paid support and SLA but the foss maker does not want free money in form of closing out issues/bugs/features they might anyways workon without getting paid for it.
Not sure what nginx is like, but in my experience, the developer/operator experience of commercial software tends to be subpar. For instance, when I worked at a shop that used a ton of Red Hat software (millions of $$ per year in licensing), the commercially-supported versions often were a pain, with requirements like phone-home (that didn't play well with the mandatory corporate proxy), documentation behind a paywall and hard to discover (yes, we had login accounts, but Google couldn't index it), and other disadvantages. The OSS equivalents were easier to access, had better (or at least better-indexed) documentation, and we didn't need to worry about per-seat licensing (again, we were paying for it, but we still had to track it).
If you're going to sell software that has an OSS variant, make sure the commercial experience actually outshines the free one.
I agree, we (at Red Hat) try so hard to make awesome documentation but then put it in hard-to-reach places. I really wish we didn't do that. I'd like to see us publish it all widely.
That said you'd be amazed at how much of man pages is written by Red Hat but isn't attributed, so nearly everybody on every distro benefits from our documentation without realizing it.
It always kills me when very successful companies don't buy software from other companies.
I remember being at a lunch with a prospective client that really loved our technology. About 1/2 way through, he said he really would love to purchase our software, but the CEO doesn't allow them to use anything but OSS. What they make? Non-OSS software.
Just blows my mind.