Tiered pricing license... tiering based upon annual company revenues... should start super low for small companies (free for individuals), and jump to thousands of dollars per year for 10+ milion revenue companies.
I understand that this might not fully be in the spirit of open-source, but, what's happening currently is way worse.. where giant companies rip off the hardwork of open-source software maintainers without compsensating them adequately.
Too complicated. Make it GPL (not MIT) and offer dual licensing.
Those corps that need it but are GPL-phobic can have a different license, and can pay for it.
My org theoretically makes hundreds of millions, unfortunately none of that money is ours. So I get forced into a procurement process for anything that costs more than (ridiculously small limit), and get stuck using the worst in class because it's cheaper.
I'm not sure this worked out as well as we thought it might do for the musicians.
for example, adding support, bug fixes, corp-friendly licencing and pricing models, private code/package repos, code/package signing, etc. Providing biz ppl to be available for meetings, legal protection, PII, etc.
To foster goodwill, they could even send some of the profit back to the original maintainer, ala pikapods: https://news.ycombinator.com/item?id=31312682
People who don't want tiered licenses could definitely just mit it and walk away of course.
I do like the idea of paying back the original maintainers otherwise people could sandbag projects to fork them later.
If you don't have a discretionary spending limit that will accommodate it, then trying to get OSS through procurement is difficult. Who is providing the support contract? What level of indemnity insurance is the supplier covered by? Can you get a spread of three quotes from competitive providers?
Not to mention that if the supplier isn't VAT/GST registered, the accounts department can be operationally incapable of accepting an invoice or issuing payment.
Not malicious, this is best practice for a large organisation that needs to prove that it is not doing fraud. But it does present a huge obstacle to buying from small organisations, startups, and one-person OSS maintainers.
I thought a while back there were some products that had dual licenses, a fairly open license for private use, use in small companies, but requiring purchase and/or contribution back when used in something like a cloud providers SaaS.
I like open source, but I also can understand the nagging feeling when your (and your contributors work) is used for pure corporate greed.
I like this idea, but the devil is in the details. "profit" is less defined than revenue. You have to specify your accounting principles. What counts as an expense that deducts from revenue to help define profit?
It's not impossible, but there's a lot more variance depending on locality, business structure, etc. than there is with just "revenue".
Of course, I suspect it all comes down to whether the entity offering the license is large enough and well-enough legally armed to force an audit of the organization taking the license. If they're not able to do that, it's all self-reporting anyway.
See all these multinationals paying close to no taxes in the countries where they operate.
Maybe they mean their org makes a lot of money the money for their parent corp, but little of that ( goes into / is reflected in ) their own orgs budget?
Why would anyone do that? If the person who was most passionate about it for over a dozen years has given up because it was never worth the trouble; what fool would think things will be different going forward?
This is the curse of OSS.
Just because someone gets tired of working on something eventually doesn't mean everyone else will immediately feel the same way.
I don't think they are "hoping" someone else will take it, exactly. They're just done with it. That's how I read it, they liked working on it, but it wasn't financially sustainable, the project is now over, and my reading is they are sad about it.
> This is the curse of OSS.
There are examples of failing forks. And there are examples of forks that became better than the original. It is not possible to generalize this into one or the other solely via a curse-of-OSS conclusion. Funding will always be an issue; but funding is not necessarily the main or only criterium as to whether a project fails or succeeds.
“And many programmers, they say to me, “The people who hire programmers demand this, this and this. If I don't do those things, I'll starve.” It's literally the word they use. Well, you know, as a waiter, you're not going to starve. So, really, they're in no danger.”
- Richard Stallman in 2001 admitting his ideology can’t explain how a programmer can eat
In my opinion, though this is HN heresy, the free software ideology and ethos was naïve, utopian, and clueless about how power works, from day 1. His dream is literally structurally impossible, capitalism or no capitalism, so long as humans need money to eat.
September 26th, 1983:
"Dear Mr. Stallman, it is I, gjsman-1000, a time-traveler sent back to tell you to rethink your upcoming GNU project because you are currently clueless about how power works. Yes, you may be able to code up an impressive prototype compiler and revise it until your fingers bleed. Yes, a decade later some zealous followers may follow your lead and maintain it on the bleeding edge. Yes, two decades later others will perhaps start an open source compiler project to wrest control from your successful compiler that is largely maintained without your direct input. And yes, three decades later your compiler team may even merge in new features and improvements that came from the other compiler. But heed my ominous warning: four decades later I will not be able to remember my original point, for time travel is dangerous business and has adverse effects on short and long term memory."
And yes the free software ideology is as naive as a puppy. Every serious individual understands this. Most HN-ers are in a fairly specific bubble (income brackets, geo-location, political leanings, upbringing, the whole package); of course to them this is "heresy". This is well-understood. Happily for me and many others around here, karma farming is not the goal so we don't mind getting some gray arrow treatment every now and then.
Some who are opposed to capitalism seem to think that anyone who wants to trade their talents and hard work for more than the minimum, are exploiting anyone who wants or needs their product.
I am not even fan of Stallman. I think it is ok to produce close software. But starving argument is just not it.
He was paid to work on it. That stopped, he continued to work on it in the hopes he could find someone who would hire him to work on it.
That wasn’t true, no one has funded it.
So due to the economic system he no longer maintains it.
That’s your economic system at work. No one is pretending it isn’t there, this is the outcome of it
The business model is as follows: Open source maintenance produces recurring costs (developer salary, infrastructure costs, etc) but these costs are fixed and do not scale with the number of users, only with the development effort. This means the ideal financing structure would be a cost plus system where the maintainer gets paid a salary and the customers (businesses) are spreading the cost among each other so that each business ends up paying less than if they had built or maintained the project in-house.
The problem here is that the costs are variable and depend on the number of participants and their individual willingness to spend money and how that effects the viability of the project as a whole. Participating businesses need some sort of guarantee that they won't be stuck with all of the costs and that there are other participants who will chip in. At the same time, once there is a sufficient number of participants, the participating businesses don't want to overpay. They may commit to a monthly worst case bill of $5000, but if the total bill is $10000 and there are 100 participating businesses so that each business could only pay $100, said big spender would want the option to lower their spending down to $100 if possible and let others carry more of the financial burden.
With this sort of arrangement, funding open source software would be rational, since the amount you save by freeloading is insignificant compared to the risk of the project being discontinued due to freeloading.