I'm fully aware of what I'm doing :-)

The D Language Foundation is a non-profit, has expenses, and is funded by donations. None of it goes to me.

Imagine Linus Tarvolds stopped working on Linux before there was a foundation to take over because he did it just for fun and no one else wanted to take up the mantle? It's hard to say what the outcome from that would have been... maybe Google would have claimed it entirely and slowly shifted the license to something else?

I appreciate that people can create things for fun, and those things can be open-source, but if someone creates something because it's the right thing to do and not just about fun... well where do we stand now? Should they make it open-source but demand money? Should it be closed-source if the fun-factor is less than 80%? 50%?

Unless a small, dedicated team of capable people agree that your open-source project is worth preserving, allowing it to survive you as the founder, I question the validity of open-sourcing anything for fun unless you design the licence, and more, to enable you to walk away and/or get bored.

Would love to hear your thoughts.

Then someone else can take over, or not, depending on how important it really is to those 150000.

From the perspective of a business, using open source is strictly safer than closed source. With closed source, if the entity owning the code goes bankrupt, increases licensing fees substantially, just axes the project (incidentally what Google is also known for) or looses interest in some other way, you are out of luck. Go find something similar and hope there is a migration path. With open source, the equivalent is the maintainer walking away because they are bored, and you have the code right there to take over, or pay someone else to do so.

> I question the validity of open-sourcing anything for fun unless you design the licence, and more, to enable you to walk away and/or get bored.

Every open source license is already designed so that you can just walk away for whatever reason, e.g. when you are bored.

When using open source, you take that risk. I've used a lot of libraries that have been abandoned over the years where I either had to switch to a fork, another library entirely, or just write the functionality myself. I know the risk inherent in OSS. For large projects like Linux, since it's so large, someone else would pick it up, but again, there's always a risk that someone doesn't.

I do not mean this to imply I think commercial software is superior to free software, I am a great believer in FOSS, I just wnat to show a reason why a "scary" warning in commercial software is not equivalent to the same warning in FOSS.

Then a few of those 150,000 people can start contributing and take over maintainership. If no one wants to step up, then I guess it isn't that important to them.

If you're depending on a one-person open source show for your company's livelihood, it's on you if you don't have a contingency plan for if/when that one person decides to abandon the project, or, hell, dies or gets too ill to continue working on it.

> I question the validity of open-sourcing anything for fun unless you design the licence, and more, to enable you to walk away and/or get bored.

No one owes you anything. Any way that anyone wants to open source something is perfectly valid. No one has to use their work for free, or under any particular terms. People who need the functionality from an open source project are free to find a different project (free or paid) or build their own, if they are uncomfortable with how a particular project is managed or licensed.

> you design the licence, and more, to enable you to walk away and/or get bored.

It's all Boost licensed, so anyone can fork it, anyone can step up and continue with it, etc.

As D's scope has increased, a lot more of the tasks have been delegated out. I do a lot less management than I used to, and get to concentrate on the parts I'm good at.

I’m unaware of any open source license that prevents an author from walking away, ever? GPLv3 has no warranty or liability?

I guess you meant something with “and more”, but that sounds like a mismatch of expectations of what a user of open source might want, vs what is required of an author of open source?

Then 150,000 people should open their wallet, or crack open a text editor, and pay.

> design the licence, and more, to enable you to walk away and/or get bored.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

I sometimes say "hell no" to features popular in other languages (like version algebra, and macros). How do you say "hell no" to your employer?

Outdated, less optimal, almost-famous code/libraries/frameworks that businesses still rely on for money and don't want to spend money migrating away from that need various updates for new OS versions, security patches, and those are the maintainers that are underpaid and struggling.

They can just not do it if they don’t want to.

I have no expectations of the users, and I expect the same from them.

On one hand OSS authors select permissive license exactly because they want big corps to use their software.

On the other hand - OSS authors are unhappy about big corps using their software in a way that license allows them to.

Just stick to GPLv3 / AGPL.

I don't understand why an OSS author would select anything more permissive than that: big corps can use MPLv2/EUPL libraries in proprietary software just fine.

[1]: https://joinup.ec.europa.eu/collection/eupl/how-use-eupl

Honestly? Because many things are too small to be worth paying a lawyer to write a letter to license violators.

If I'm not willing to sue someone for disobeying the license on a library or tool, I just use a maximally permissive license. And at a good lawyer's hourly rate, it has to be a pretty big project before I'd even care.

So for minor projects, MIT or Apache it is. Or I just CC0 it. I wrote the code because I found it useful, and I decided that it wasn't worth the often heartbreaking effort of building a sustainable business around it. So if someone else finds my code useful, that's great!

(EDIT: See discussion below for why I don't bother with a license I'm not willing to enforce.)

> Because many things are too small to be worth paying a lawyer to write a letter to license violators.

Then don't! I would advice you never even consider it, that would be absolutely crazy!

But what you miss is that big companies using your library have a lot of money, and therefore it is a risk for them to not comply with your licence. What does that mean in practice?

* Big companies will favour permissive licences. If you publish your library under a permissive licence, you screw the other small libraries that have a copyleft licence (that would be an argument for a permissive licence). * Big companies can't use strong copyleft libraries in proprietary software, so that would be a no-go. * Big companies can TOTALLY use weak copyleft libraries in their proprietary software. But if they do, they have to distribute their changes. Because not doing it would be a risk they are not willing to take.

Whenever someone starts a sentence with "respectfully", it's usually because they're about to say something disrespectful. Definitely the case here.

GP doesn't have it completely wrong. There is no wrong or right. The person who is doing the building gets to decide the license, and any reason or motivation they have for picking a particular license is by definition correct, because that's what they want to do.

> If you publish your library under a permissive licence, you screw the other small libraries that have a copyleft licence (that would be an argument for a permissive licence)

No one releasing something under an open source license has any sort of responsibility or obligation to some random other open source project they may not even know about.

Only alternate facts?

I answered to a comment that said "I don't use copyleft because I don't want to have to pay a lawyer", which to me is a completely invalid point. It's like saying "I don't use copyleft because I don't want to eat bananas". You can use copyleft and not sue, just like you can use copyleft and not eat bananas.

> No one releasing something under an open source license has any sort of responsibility or obligation to some random other open source project they may not even know about.

I meant that permissively-licensed libraries tend to be favored, so that's an advantage when competing with similar libraries. If you care enough to choose a license but you are not trying to compete with other open source alternatives, then it would be nicer to go for copyleft.

I know permissively-licensed projects that were inferior to copyleft alternatives but got more traction because... well because companies could freeride on the permissive license. In that case those who chose the permissive license knew exactly what they were doing and decided to compete this way instead of technical merit.

Just to clarify: I have actually been involved in open source license enforcement efforts, because big companies do violate strong copyleft licenses regularly. Or their subcontractors do.

Usually, if you're willing to pay a good lawyer to yell at them, you can get the domestic ones to stop. And I know of some enforcement organizations that manage to get voluntary settlements on the order US$15,000, or who get the violators to appoint a "compliance officer."

For a big, commercially important project? This is often worth it. For a modest CLI tool, or something which I put a few weeks of full-time effort into? It is not remotely worth my time to enforce a strict license. This is a purely personal tradeoff. But if it's not worth $400 to me to have a lawyer write a letter, then I'm going to use a permissive license.

Again: if it's not worth $400 to have a lawyer write a letter, just don't have a lawyer write the letter! But you can still have the copyleft license... for the situation where it may be worth a lot more in the future. Or just to give leverage to fellow developers: if I use a copyleft library at work, then I can tell my managers that I must contribute my changes upstream, during my working hours.

That’s a false alternative. You can chose copyleft license and not sue.

This is _especially_ useful for things I don’t plan to monetize. It allows free use but also protects the society from free riders.

That's a value judgment that others may not share. I'm not (quite) one of them, but there are people who believe that bits on a hard drive shouldn't be owned, by anyone. I think it's a perfectly reasonable stance to argue that releasing something as a public good under the least restrictive terms possible is a moral and correct thing to do.

Personally I prefer strong copyleft for most projects that I really care about. But that's my preference, and I don't kid myself into believing that I know what's right or wrong for society in this area.

Probably there's no real reason apart from legal saying "meh, we can't be bothered about reviewing this"

As I don't care about Google using my code or not, I choose EUPL, but it's worth mentioning that some companies only accept permissive licenses that grant them the right to do basically whatever they want with your code.

Free software has almost lost, now that MIT has become the default, pushed hard by corporations and its employees.

Not sure what you mean. GPL-style licensing is still very popular among open source projects. Sure, there are perhaps a lot more projects that are MIT-licensed (and similar), but that doesn't detract from the body of thriving GPL-licensed software.

I think you're reading too much into people's motivations. When I release something under a permissive license, it's because I don't care about it enough to license it under something like the GPL. Or I just don't want to deal with the possibility of there being license violations that I'd feel responsible for dealing with (if I'm not going to, then why bother licensing under a copyleft license?).

For the most part I don't really care who (if anyone) uses the stuff I release. Building a community around an open source project that I started could be fun and rewarding, sure. But honestly I'm not sure I'd even want big corporate users, since they're likely to expect things from me that I'm not willing to provide.

> On the other hand - OSS authors are unhappy about big corps using their software in a way that license allows them to.

Regardless, you're painting all of us with a very broad brush. Please don't assume anyone's motivations or licensing decisions fall under some simple, one-size-fits-all rubric that you have in your head.

I developed this license https://justdo.com/source-available-license , if someone wants to adopt it for their project, I'd love to provide its Latex form, just DM me. (With enough demand, I might Open Source the Source available license ;) )."

"The PolyForm Project is a group of experienced licensing lawyers and technologists developing simple, standardized, plain-language software source code licenses. PolyForm aims to fill gaps in the menu of standardized software licenses, like non-commercial, trial, and small-business-only terms."

https://polyformproject.org/

"allow us", "ensuring we can" ...

You misunderstand OSS, which is about "allow all", and "ensuring all of us can". Of course, the OSS model doesn't always work, nor do its proponents claim it is the one true way to run a project. Though, they do get irked when source-available licenses try to pass off as "almost OSS" but aren't quite.

The gp clearly distinguishes open-source and source-available, and I don't think he misunderstands OSS.

I wouldn't be interested in collaborating with a company on their source-available software (since I'd be doing free work for their profit), but if my company were using their product, and we needed a new feature or bug fix that they weren't going to prioritize, I'd much prefer to build that feature or fix that bug myself and give it back to the company than have to maintain my own fork.

And I don't really see a problem with that. Presumably my company would be using their software because building the whole thing ourselves would be too costly. But if I need to spend a week or two augmenting it? That's fine. Cheaper for my company, and I'm getting paid to do that work.

Transparency: If I can see the source code, that is certainly pretty much the definition of transparency.

Collaboration: It is easier to collaborate if I can see the source, don't you think? That doesn't define the legal terms under which this collaboration happens, of course, and you should make sure they suit you before you collaborate.

> Open source software companies need to come to grips with that uncomfortable truth: their business model isn’t their community’s problem, and they should please stop trying to make it one.

are full of unjustified entitlement. And also not relevant: The companies we are talking about are not open-source companies. They are just companies. Some of them, with source-available software and/or hardware. Some of them, with open-source software and/or hardware. Some of them, with both.

> So that argument is idiotic.

Well, what's idiotic is expecting collab on a source-available project. There's a reason the community forks or uses OSS instead, as the article notes.

  Those of us who have been around for a while — who came up in the era of proprietary software and saw the merciless transition to open source software — know that there’s no way to cross back over the Rubicon.
  
  Open source software companies need to come to grips with that uncomfortable truth: their business model isn’t their community’s problem, and they should please stop trying to make it one. And while they’re at it, it would be great if they could please stop making outlandish threats about the demise of open source; they sound like shrieking proprietary software companies from the 1990s...

I personally wouldn't use something available under a non-OSS source-available type license, but if they're able to build a business around it and are doing well, that's great.

Stallman et. al. have not worked in big corp since the 80s so they don't understand how misaligned incentives are now. The AGPL is a solution to the issues we were having in the 00s. The issues of the 20s are solved by source available licenses. Or my preferred solution, any open source license which can only be used by a natural person, corporations need not apply.

Lots of us said this in the 1990s by the way. Even back then, the belief that many developers and businesses would reciprocate by freeing their own source or even that enough would reciprocate for FOSS to be self sustaining was clearly, ahem, unrealistic.

GPL didn't foresee SaaS becoming such a huge thing. As I understand, AGPL is a step on the way to fixing this.

Android in doesn't even accept patches from the like of you or I, and future versions are developed almost entirely in secret.

You're talking about open development and governance, which are often associated with open-source, but aren't required.

A big part of Open Source is not knowing or caring about the intentions of the user. Wherever it may go is magical but also, potentially, terrifying.

I can't articulate it that well, but look back at the whole RSA/military grade encryption thing for references.

I use only open source software. Thanks for writing it.

Even if it was strictly a donation model, I'm not sure I'd feel completely comfortable with that.

I think the best option is to just AGPLv3 everything. You maximize freedom but still own the copyright so if corporations want your software they can simply pay for permission to use it. AGPLv3 gives us our leverage back in an ethical way.

Even asked Richard Stallman what he thought of it. His reply:

  > It is my understanding that as the copyright holders
  > they have the right to do it without any problems.
  > They leverage the AGPLv3 to make it harder for their
  > competitors to use the code to compete against them.

  I see what you mean. The original developer can engage
  in a practice that blocks coopertation.

  By contrast, using some other license, such as the ordinary GPL,
  would permitt ANY user of the program to engage in that practice.
  In a perverse sense that could seem more fair, but I think it is
  also more harmful.

  On balance, using the AGPL is better.

But it is the truth. Do you not like the truth?

It is not a job. Nobody asked you to do it. You do not get to be sad when nobody pats you on the head. You are owed nothing.

Thanks for the code.

You might not be getting paid, but you also aren't getting nothing.

It might be important to you to get paid for your work. Okay, charge for your work then! That was always allowed. There are many people who are okay with doing certain work for free. Maybe they just want to put it on their resume, or they already have enough money, or they just really like that work. Open source is working fine.

Individuals have agency over discretionary spending, in other words you can wake up and decide to donate money, hire a OSS dev, and so on.

Because you personally have that agency, and because companies have lots of money, you project that agency onto companies.

But that's not how companies work.

People at companies have very little personal agency when it comes to spending money. Spending has to be approved, justified, and some value has to be received.

FOSS basically is (mostly) incompatible with this model. Some companies do pay staff to work on OSS but it's rare (and exclusively tech companies with a motivation.)

So while your statement is completely true, it's also not possible.

It's important to recognize that donations and corruption are indistinguishable, and company finances tend to be set up to avoid corruption.

Other than the humor in this sentence, I'm not sure why it would be limited to donations. They can hire devs to work on FOSS.

> People at companies have very little personal agency when it comes to spending money. Spending has to be approved, justified, and some value has to be received.

Approved by... people.

These FOSS we personally use. And FOSS we don't. Most of the FOSS we use already has plenty of paid devs. Think Linux, Firefox etc.

But what about small projects? How does that hiring conversation go? How do I explain my hiring request to my supervisor? Why am I spending 100k a year on a text editor? Why have I mandated we use my cousin's text editor and we're paying him to write it? When there hasn't been a significant update in 2 years? When we had to layoff staff to make mandated cost cutting?

Wow. What absurdly unfair examples.

In other words how do I choose which projects to support? How do I detect when said support is above board or when there are other factors?

You may take issue with the specific example but "hiring OSS devs", or worse making OSS donations, look exactly like this (if not as blatant.)

As a business owner How do I know these decisions are made in good faith? As a shareholder how much of this am I prepared to tolerate?

Those businesses making "billions in profit" have very high levels of accountability. Lots of people care deeply about that money.

Same argument can be applied to closed-source software. For example, how do you decide which vendor is your company going to select for their internal or external business. Why did you choose Cisco security solution over Fortinet or whatever other alternative there is? Is it corruption in terms of "I know this guy in Cisco" or is it "their solution is the most powerful"? Essentially, as you say, it is indistinguishable. I don't see how this is any different than to select some FOSS project to support if it generates your company/product a value.

Reason why companies aren't paying for FOSS is simply because they don't have to. And also there's no business on the other side to buy something back from you which is many times the case with B2B deals.

Selecting software (commercial or OSS) is no problem. And OSS bring free is a plus in that column.

Paying for commercial software is easy. They give us an invoice, and we pay it. OSS has donated button on a web site. There is absolutely no motivation to click it, and indeed clicking it leads to all kinds of extra hassle and work.

OSS has no business model. That makes it hard for companies that are used to business.

Yup. All this other stuff is just noise: this is the real reason.

If I ran an open source project that businesses used, I could make something that looked exactly like an invoice for a piece of commercial software, but say it's optional to pay, and companies would -- completely correctly -- not pay it.

> As a business owner How do I know these decisions are made in good faith? As a shareholder how much of this am I prepared to tolerate?

Hypotheticals that I'm not going to bother trying to answer, because that's going to depend on the business, the business owners, the projects they choose to support, and a myriad of other factors. Good luck getting some generic answer to such questions.

> In other words how do I choose which projects to support?

You're right. Impossible to decide, so let's not even try.

Or, like, do some research and have a discussion to determine which of the various FOSS your company uses that could do with some funding. Evaluate them individually. Decide on a monetary limit. Re-evaluate regularly. You know, normal business accountability things, right?

No, not at all. A normal business accountability thing would involve not paying for something when you don't have to. Or, rather, not paying when paying doesn't grant additional value beyond what not paying gives you.

For the most part, a company that uses an open source project will not see any upside if they pay. Collectively, yes, it would be better to financially support the projects that companies depend on, but on an individual basis, a company logically sees no reason to pay.

And even if the worst happens, say the sole maintainer gets hit by a bus and dies... most companies will be content to wait and see, and deal with that problem if and when it happens, not before then.

seems to all hinge on the justification part, for which ppl that do it for the lulz don't really care

People can of course choose to spend their political capital, and discretionary budget on random OSS projects. Or they can choose to spend it on their project, their goals, the outcomes that make their walk in the company easier, the actions that will get them promoted and not fired.

These are choices people make, and frankly OSS funding delivers very very little bang for the buck. (On a buck by buck basis.)

which is why companies generally don't pay anything for OSS. If the cost is zero, but the benefit is not zero, then the bang for buck is infinite!

But neither goal is aided by hyperbole, pretending that not paying OSS is gravity.

No idea what the future will look like in general in 5, 10, or 20 years but I am reasonably confident that donations to OSS won’t be drastically more than they are now.

Hard to see why those things will stop being true.

That’s why I said to shame individuals, not faceless entities. And I think it’s fascinating that you didn’t reply to what I actually said.

Even as you tried to shame me (ie “if you actually believe that, you’re so dumb you’d buy something ridiculous!”) because you recognize that shaming is an effective tactic.

To quote someone else who's worked with Big Corp:

>>Do not fall into the trap of anthropomorphizing management. Think of management the way you think of a lawn mower.You don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it'll chop it off, the end. You don't think 'oh, the lawnmower hates me' -- lawnmower doesn't give a shit about you, lawnmower can't hate you. Don't anthropomorphize the lawnmower. Don't fall into that trap about management.

>Even as you tried to shame me (ie “if you actually believe that, you’re so dumb you’d buy something ridiculous!”) because you recognize that shaming is an effective tactic.

I don't give a fuck what you think. I want to convince other people that you're wrong and we need better solutions for writing open source software because I enjoy doing it and I'd love to get paid for it. As far as I'm concerned you're a badly put together memetic lawnmower whose a danger to everyone around you - the end.

unless they're using some sort of hosted service for free, this cannot be critical. After all, software doens't rot, and they could continue to use the existing release until a (new) solution is found.

Look at how crowdstrike triggered outage didn't cause bankruptcy - that is more critical than most OSS would be.

Though I will note I'm agreeing that it's highly unlikely you can put a gun to the heads of corporations and get them to cough up, so I'm not sure what the point is here.

which doesn't happen instantly. For example, the end of life of the old java versions (1.5, 7 and 8 etc) - plenty of companies simply just paid a support fee and get support, while others paid to upgrade (or even change stack).

Most open source software, even with lack of updates, does not immediately start failing. The huge amount of time and leeway, even with security issues, is what prevents it from being critical, and prevents OSS from causing a bankruptcy.

Well, there's plenty of mission-critical FOSS used by plenty of companies. But you are right in that it doesn't just fail one day, and companies have plenty of time and options for dealing with abandoned FOSS.

(Which is one of the major benefits of FOSS. It's more likely with proprietary software that it can just disappear one day, with little recourse for users.)

And plenty others simply keep using the old 1.8 version because there's no budget to upgrade and there's no budget to 'pay a support fee'. And there's no budget to 'change stack'. Because... there's no budget.

Convincing people you need to upgrade or switch to keep current is often a hard problem, and sometimes has to be done with "you'll get all these new features!". But often "hey, we need some money to upgrade system X" is met with "hrm... it's software! It doesn't rot!".

    > paid a support fee and get support

Me: "I think you cannot get corporations to cough up without some ridiculous extreme event like a behemoth dying. And I'm not holding my breath that would really do it."

You: "Your extreme ridiculous scenario is extremely ridiculous and here's why..."

Rinse and repeat.

Sure, but that won't happen immediately when the maintainer abandons it. It might not happen at all. There's usually going to be plenty of time for a company to switch to an alternative, or even take on maintainership themselves.

Which is absolutely correct!

As an open-source author and maintainer, I have no desire or motivation to call any of my users "deadbeats", especially when I license my software under terms that specifically do not require any kind of payment. That would be pretty hypocritical, as I've used lots of open source software (both personally and professionally) without paying for it.

[1] apart from Meta and Apple, they seem ridiculously low.

MPLv2/EUPL come to mind: they are compatible with proprietary products, but they make it mandatory to distribute changes/extensions of the library, not the whole product.

FOSS authors have a responsibility when they choose a permissive license.

No they won't. They'll only contribute if they're required to, or if doing so will be beneficial to them, and they'll do that regardless of whether the license says they have to or not.

When I've worked at companies that use FOSS, and have needed to modify those sources, I'll contribute back (regardless of license) if I think that change is likely to be accepted upstream, because I'd rather not have to maintain a fork. This would fall under "contribute if doing so will be beneficial to them".

At any rate, no FOSS license (that I'm aware of, or is in wide use) requires users to contribute. At most, they require that changes be made available. There's nothing that says the changes need to be submitted (or accepted) upstream. Often getting a change into a state where it would be accepted upstream is a significant amount of work beyond what the company has already done for their own purposes, so they don't bother.

Did you actually read my comment before you answered? Because I said that copyleft licenses "make it mandatory to distribute changes/extensions", which means that companies are required to contribute if the license is reciprocal.

> At any rate, no FOSS license (that I'm aware of, or is in wide use) requires users to contribute. At most, they require that changes be made available.

Making changes available is a form of contribution. If you work on a proof of concept for a month and at the end your company decides not to use it in a product (thanks to the learning from your work), do you say that you did not contribute, so you should not be paid?

Feels like you're being pedantic just for the sake of the argument.

With copyleft licenses, nothing say that you have to get your changes upstream: you just have to distribute them to the users. It's not a whole lot more complicated than attribution: set up a repo and put your fork there publicly.

Also, I stand by my previous comments from other similar discussions: Almost all big corps use Redhat. They are indirectly funding open source. Redhat probably employs more programmers that contribute to a base Linux install than any other company on the planet. (Yeah, I know they were bought by IBM, which gets no love around here.)

Or maybe he knows he's not a good person and has no intention of multiplying people who are just like he was, because he knows people as himself are bad and the world is better without them.

If he’s doing that, we should stop him as a danger to others - no different than any other criminal.

Um, excuse me?

Ok, let's suppose you've got a product that depends on open source project X. For simplicity let's say it's a direct dependency, though I think everything here applies to indirect ones as well.

Let's consider the options.

Option 1: never pay a dime for it. This works in so far as someone else picks up the bill. So really there are two sub-cases:

Option 1(a): the project is successful enough that it's self-sustaining. What this really means is that someone else (or multiple someone elses) picked up the bill. Congrats, you lucked out.

Option 1(b): the project is insufficiently funded and either dies or has a major security breach. Now you end up paying either for the security breach fallout and/or to replace the component, possibly on short notice, with something else. Or you maintain it yourself and start paying that cost, again possibly on short notice.

Is that really worth it? Do you think so? I'm betting all those costs are higher than it would have cost to maintain it in the first place. Because anything you do in an emergency is more expensive, and you're paying the cost of losing all the context in the development of the project itself (if someone leaves before you start maintaining it).

Option 2: pay for the software in the first place, making the cost predictable and avoiding a low-probability high-impact failure mode. Honestly, given all the risk management companies do, this seems worth it to me. At least if the dependency is critical enough.

Obviously you won't do this with any random open source project. But that's sort of the point: companies are making economic decisions all the time about what they really care about. If they aren't paying, that means they're happy with the inverse lottery[1] of the failed open source project model.

[1]: An inverse lottery is one where most of the time you get nothing, but rarely you lose big.

Option 2: Fork the code and do whatever they want with it.

Option 3: Directly employ open source project maintainers instead of donating to the project. They can exert at least some control over project direction that way.

Most enterprises don't even have a budget line item for open source project donations.

But it's common that they have employees who are assigned to working on the open source project. That's an item in the budget, it just isn't labeled "open source project donations".

Perhaps after this generation of LBIP moves on, the next wave won’t be so generous.

Also, open source doesn’t have to mean free labor. One could be paid a wage to work on open source.

The rate of new contributions may be dependant on these factors, but not for what’s already out there.

What isn't sustainable is just the model where some random person takes a huge part of the responsibility for himself without any structure around it. We need different organizations.

You hate tickets without repro? Enjoy the barrage of “help. Doent work”, “me too” and “HELLO IT’S BEEN 3 DAYS” messages.

There are very good reasons why the support processes of commercial entities that build products are the way they are. You do want a lot more friction and you do likely want to limit support to paying customers.

GitHub-style public issue trackers are just a bad idea overall IMO. They only work if the "public" is only "public" because everyone _in theory_ could take part. In practice however, you only want to grant such unlimited write access to vetted individuals. This happened to happen automatically previously (because getting to the point where you even know where to open a ticket _was_ part of the vetting process), but with GitHub as the default for everyone and everything, it needs to be a conscious effort.

If you think about it, it is completely insane how any random individual just has to press one button to publish whatever they want to a super prominent part of what is effectively your products/projects website. That simply shouldn't be a power random individuals have

Sure, countermeasures exist, but the issue is that you first need to be aware of what exactly the problem is before you can take these countermeasures.

The reality however is that people just hear "You should do GitHub" and then for some inexplicable reason slowly descend into feeling bad without any clear reason why. After all, they're following all the "best practices" laid out by people that clearly know what they're doing and surely have their best interest in mind.

Open source was built on the spirit of openness. Rather than closing it, I think solutions should be proposed to improve it (thinking of it, it's a good place for using LLM-s - you don't need perfection for checking a bug report makes some sense and filtering people a bit).

> Throw magic at the problem to further scale resources to sustain a problem instead of actually solving said problem

I can only encourage people to counter bullshit with minimum resource investment. Full-sentence answers should be limited to those statements deserving of them.

No open source maintainer is obligated to run a public issue tracker or listen to users at all if they don't want to.

Why do people feel that maintaining open-source software is stressful again?

I wish Github would allow me to hide the Issues and PR tabs from my projects.

Cannot underestimate mental health issues after a barrage fire of those messages, usually by people who could not bother to read the README.1ST - been there, done that.

Regulatory requirements also need to be contextualized similarly. If they become burdensome, efforts should focus on reducing the exposure of your systems to those risks.

That said, patch and configuration management should be second nature and performed continuously so that when a real issue arises, you're prepared and not worried about your environment falling over because you're unsure how it will respond to an update, or whether your backups will restore properly - which are risks as well.

I saw more than a few organizations struggle with log4j because they only patched server systems when a vulnerability was publicly exposed, and a Metasploit exploit was available.

Open source first felt to me like a way to give power back to ordinary people, and it still is, but it seems like those who get the most benefit from free labor are large corporations. Open source feels increasingly corporate and companies like Microsoft dominate and reap enormous benefits. I’ll work for Joe Neighbor for free but not Sataya Nadella.

Open source was always political but in 2010 (around when I started getting into Linux) it felt like dumb arguments over things like programming languages or “the UNIX philosophy”. Now it feels like a vicious Red vs Blue culture war where not picking a side is just as bad as picking the other side.

Contributing to open source is a thankless job and even if your project is really good, most people won’t care and the few that do might still treat you like crap. I’ve submitted a handful of pull requests and I’ve already run into the classic “Your patch works and provides a feature some people might like, but I don’t like it, go away.”

I’ve donated plenty to organizations like Mozilla, Wikipedia, and GNOME. I then email them with my opinions on what they’re doing. In nearly every case not only am I ignored completely, I see those projects (Mozilla especially) continue to drift in a direction that I disagree with. So, I stopped donating.

For me, the Linux kernel is probably one of the few big open source projects where 1) the project is technically interesting enough that I would learn a lot by contributing, 2) It seems like politics and infighting is kept under control, 3) it actually seems possible to get a patch in while having a 9-5, 4) I use the product myself every day and enjoy it, and 5) the technical direction feels positive in that it is getting regular features & bug fixes that I like

One factor is the lack of adoption of copyleft licenses. The proliferation of permissive licenses turned into a backdoor for corporations to privatize volunteer work. We should adopt copyleft whenever possible. Stallman is right on this.

Git is GPL, this didn't prevent GitHub from becoming a multibillion dollar behemoth of a Microsoft subsidiary.

The value which companies capture is in using software, not modifying it and selling a proprietary version of the modified code. The only way to sustain this misapprehension is to notice every time permissively licensed software makes a company some money, and studiously ignore it every time copylefted software does the same thing.

You have it backwards. The goal of copyleft is not to "prevent others from benefiting". The goal is to potentially benefit from the adoption. If someone uses your copyleft library and fixes bugs in it, you can see their fixes and bring them back upstream. So you benefit from their work.

There cannot be an OSS license where the user of the OSS who don't make money don't need to pay, but a corp that do make money pays.

and nobody cared. read about the "tainted kernel" compromise. without it android, modems, anything with a linux firmware, would be truly open source.

alas, the modem manufacturers won then.

But there are copyleft licenses that are not viral at all and just force the users to distribute their changes to your library, e.g. MPLv2 and EUPL.

I don't understand why one would use a permissive license versus MPLv2 or EUPL.

GPL3 gave copyleft a bad name and everyone decided to give away their labour for free.

MPL/EUPL are the spirit of "you can use it, if you spend half a million writing a completely separate module of course you can keep it for yourself, but if you change the actual source files that everybody uses you have to share, so everyone benefits."

Using Linux as example it means one could write their own proprietary driver for their proprietary device, but optimize, say, the memory allocator, please share it so we all benefit.

I feel one thing to remember on this front is that large corporations will ALWAYS get the most benefit out of open source / “free labor”, simply because they have the ability to bring massive amounts of resources to bear on using that open source product towards their own ends. Consider the world of hardware emulation. Sure the community has benefited massively from the efforts poured into reverse engineering and understanding old systems and games and preserving what was there. And the big corporations reap huge benefits in the form of continuing nostalgia, awareness of their back catalog of IP, test markets and information about the viability of re-releases and in some cases the licensing (or outright theft) of emulators and emulator code for selling their own retro consoles.

Burn out is absolutely a concern, and the approach of some open source devs (like IIRC the curl dev) of essentially “f you, pay me” to support requests is probably an important thing to have. But for me as an individual, the fact that Atari’s current owners have reaped massive rewards from the fact that the emulation scene keeps their brand alive means nothing to me. I’d rather have the world we have were things are open and the community is there, than one were emulation is closed and insular and getting into it is even harder than it already is just to keep Atari from “winning” the most. And selfishly part of that is because Atari winning also benefits me. Their re-releases and re-masters and dumping of money into manufacturing by hardware retro clones puts money into the market, gives new hardware to tinker with or build on. And their dependence on the open efforts of the community also means bending that hardware to my own needs is much easier than if they had for example just rolled out a bunch of new proprietary SoCs to replace the old hardware with a single blob chip

This might be because they’re not interested in maintaining it for future iterations.

I totally get it that a maintainer doesn't want to merge some code, even if it's totally working. Is the new feature a niche case, or has if a wide audience? Is it aligned with the project goal/philosophy? Will it be easy to maintain/evolve/debug? Does it add unnecessary/unwanted dependencies? At the end of the day, the maintainer will be the person that have to work/support with this code.

Please keep in mind that if you've spent an hour on a project, maintainers have have certainly spent hundreds if not thousands more time on it.

[1]: https://github.com/Orange-OpenSource/hurl

The reason I open a PR is so that it becomes public.

Most of my PRs solve stuff that I wanted to solve. For example at some point I added simple math expression evaluation in the Start menu of Linux Mint. It worked, I use it in my computer and I published it as a PR. I Think it was rejected because of so e bureaucracy. It's OK. It's there if someone finds it useful, I do t care doing bureaucracy, but I understand why they would want that.

Normally the larger the project the more "bureaucratically painful" it is to have a PR accepted. In small obe person projects, .y experience has been that original devs are surprised and happy to know that someone used their code s d is bui5on top of it.

and the beauty of opensource is that the fork button is right there! You don't even need to ask for permission.

Same. I think it is potentially easier to get a well defined change into Linux itself rather than a randomly chosen but largish open source project these days. I don’t really try to contribute to other projects anymore, not because I don’t want to, but because if you’re coding for fun anyway it’s usually better to work on a project you control rather than dealing with the frustration.

I think a huge percentage of open source would be more accurately advertised as “open source but closed contributions”, and being upfront and realistic about this is important. People who are already working for free deserve to have a realistic understanding of whether they will get to merge that simple bug fix they need to unfork the library, or if it’s more realistic that they need to start talking on a mailing list for 5 years and work out how to join a steering committee first.

Your Pull Request makes the project larger and it needs to be maintained - so making the load on the original author larger. If it fixes a bug then it helps the original author and so can be accepted. So it is not closed contributions but rather it has a defined scope and we are not going let the project suffer from scope creep.

One example of this is a project written on Linux - it does run on macOS but not fully correctly. The original author just says I don't have access to a Mac so cannot support it. They are not being a bad person here just stating a fact. The answer here is that there is now a fork that does support macOS, hopefully correctly but I would not be surprised if there are bugs due too differences in the OS - the major ones have been made but I'll bet that a full code review has not been done over every line of code.

It’s not that much to ask. Realistically as programmers we should probably solve these problems with data and not waste anyone’s time. If your supposedly open project has never merged a pr by a non-member or a person without a looong history of hanging out on the projects social periphery, then non-members should be warned when they submit a PR that this is the case. Saves 2 weeks of fake requests for tests/documentation/justifications when the real issue is a steering committee that prefers insiders-only. And again, that’s fine, it’s just the missing transparency that’s the real problem.

And yeah, even clearly needed bug fixes can still be in this category, it doesn’t take a major feature that’s going to be a maintenance burden. 3 weeks (or years) of discussion arguing the bug is not a bug, followed by the users saying it’s a bug, and then maintainers asking for changes/docs/tests and then when that’s all in place, maintainers pivot to suggesting it needs to be an extension/plugin or whatever. In some ecosystems this kind of thing is more common than elsewhere.. but if you’ve never seen this count yourself lucky. Naming projects is tempting here but in the end it’s unpaid work that’s a passion project for an army of volunteers. But the volunteers are still just dumb monkeys that really enjoy dumb hierarchies, so what can you do..

Absolutely not, no.

A potential contributor can start by assessing the project. This can begin by politely asking the maintainer whether a particular patch will be accepted. Or, the contributor can examine the project history.

If the potential contributor receives no response, or sees no indication of a robust history of merging patches, then assume no patches will be merged. The code is there for the taking. The contributor is free to fork it and modify at will.

Rich Hickey said this best:

"As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation."

https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

To put it in simpler terms.. here is a person who wants everyone to fuck off, but refuses to even explain that’s what he wants? How are we supposed to know? If no one is entitled to an explanation, then don’t be surprised if everyone is confused.

    > open source but closed contributions

I have seen this so many times. It used to bother me a lot, until I stopped trying to boil the ocean and fix a bug in a project that I do not control.

As I often do on this topic, I feel compelled to point out that this isn't actually a problem. Software is not a scarce resource, and Microsoft (or whomever) getting huge benefits from a project doesn't prevent the project from doing good for the common man as well. Since nobody is being hurt by corporate usage of open source, there's no problem.

I've got aplenty of code I haven't released because I think at some point I could build a business with it.

I presume this is the problem - if you dislike Microsoft, then Microsoft benefiting is potentially a problem.

It is for me, I don't want to spend my precious time helping a corporation like Microsoft increase their dominance.

It is hard to keep something rolling after the founders, that managed to steer a project under their ideals are no longer around to steer the boat into the right direction.

Something else will eventually take Linux's place, in some form, it might even be a Linux based like Android, WebOS, ChromeOS.

So Linux won't be the same because it might start being marketed under a different brand name?

Also given that the kernel is not exposed to userspace, other than to device vendors, it could be replaced by something else with very little impact to userspace, other than whatever people are doing in their rooted devices or via ADB shell, both meanigless for common consumers.

It is not really Linux-based if something else. Assuming the Linux-based property remains, though, isn't that still Linux, even if it ultimately is taken down roads Linus would have never approved of?

Microsoft tried it (with WSL1), and gave up. The remaining 15% is the hard part, and plenty of software will depend on something within that 15%. Sure, there are only a couple hundred system calls, and most of them are pretty simple, but then there are the multiplexed system calls (ioctl, fcntl, ptrace, io_uring, etc), the fileystem-based ABI (procfs, sysfs, etc), the ever-growing set of flags to otherwise simple system calls, and even a network-like protocol between userspace and the kernel (netlink).

> Open source first felt to me like a way to give power back to ordinary people

I think it's the difference of philosophy between Free Software and Open Source Software: Free Software cares about the people, Open Source Software not so much.

> most people won’t care and the few that do might still treat you like crap

That's completely right, people are mean. I do open source for myself, I choose copyleft licenses (I like MPLv2/EUPL), and if people want to fork my project I am fine as long as they honor the license. If they do a good job, I can bring some of their changes back, to my benefit. If they ask me for features, I invite them to fork.

> I’ve submitted a handful of pull requests and I’ve already run into the classic “Your patch works and provides a feature some people might like, but I don’t like it, go away.”

That's where I think you misunderstand open source. It is their right to not take your change, you should not bully them for that. Your right is to fork the project and add your changes. Do it!

Never ever build anything non-trivial for an open source project unless you've cleared it with the maintainer first. No one is obligated to take your contributions. Unless you're building an addition that you plan to maintain yourself (either privately or through a fork), always always always discuss what you want to do with the maintainer before you write your first line of code.

> I’ve donated plenty to organizations like Mozilla, Wikipedia, and GNOME. I then email them with my opinions on what they’re doing. In nearly every case not only am I ignored completely, I see those projects (Mozilla especially) continue to drift in a direction that I disagree with. So, I stopped donating.

In general I look at donations as influence-free. You aren't buying anything with your donation. Sure, an org is more likely to listen to the wants of someone who is a large, noticeable, recurring donator. But in general most people will not be that. Donate to support what they are doing, not to try to influence them. Your decision to stop donating when their values stopped aligning with yours was a good one.

> Open source first felt to me like a way to give power back to ordinary people, and it still is, but it seems like those who get the most benefit from free labor are large corporations.

I think you're looking at it the wrong way. Unless you're going to dual-license your project, you just need to accept that people will use your software in ways that you might not agree with, or to make more money with it than you can make off it yourself. That's always been true, even before you started getting into it.

I do open source because I enjoy it. It's really that simple. I love building things with code, and building entirely for myself behind closed doors is much less fun than collaborating with others, building for a larger audience. If I ever stop enjoying it, I'll stop. If a company ever starts making money off what I've built, that's fine, good for them. If there's anything I've built that I do need or want to monetize, I'll license it in such a way that will make it harder for companies to make money without me getting a piece of it. But this is the trade off with open source: you give it away with no expectations for or reservations against how it's going to be used.

I also had an opposite experience - submitted a PR with a fix, and the maintainer rewrote it a 'better' way which addressed the problem higher up the stack, meaning it 'fixed' things in a couple other spots I didn't even know about. That was such a great thing to do, and reminded me that projects can be that collaborative, even when you don't really 'work' with the other people all the time.

I might suggest you find smaller and more focused projects to contribute or donate to. The spirit you're looking for is still out there. Your Mozilla donations individually don't mean much to them, and sending some money to GNOME doesn't mean they'll take your emails seriously. A more niche project addressing a more focused problem would more likely welcome your code and donations, and potentially let you have a 'voice' more effectively than at big projects.

I have some tips that might help you develop a better relationship with Free Software.

Try to be egotistical about it. Contribute because you want a change in a software you use. If the maintainers are giving you a hard time, fork it with your changes and be happy.

Stop donating to software foundations, you will be disappointed on how they use your money.

Never sign away your rights with a contributor agreement. Fork it and move on.

Use copyleft whenever possible.

I don't spend much time accepting contributions: I encourage people to fork. But if they make changes that I find interesting, I bring them back. For my benefit.

I do it for me.

I wish more Open Source community players to stand up for their interest more strongly.

In the end, whenever you like it or not, few are going to pay for what they can get for free, and it especially applies to large enterprises

Which IMO means using copyleft licenses. Not necessarily strong copyleft: I mostly use MPLv2 and EUPL, that I find let people use my code in their proprietary software, but forces them to distribute the changes they make to my code. The best of both worlds.

the only thing licenses help with is discouraging people from using it in the first place

It may discourage people from using it, often because it's easier to go with a permissive alternative. But if there was no permissive license at all and only weak copyleft, then I am absolutely convinced that people would use them just fine.

One important thing I believe you miss is that weak copyleft gives developers leverage to contribute back during their work time. If my company needs this particular library which is MPLv2, then as a developer, internally I can tell my managers that I must upstream my changes. Whereas if it is permissive, then I can try to ask the permission to upstream my changes, and obviously that will be refused (because it takes time which costs money).

By using a reciprocal license, you give developers a legal reason to contribute back during their work time. Ain't that amazing?

Maintainers owe you absolutely nothing for just using their software.

Go pay them if you want them to work for you, and see if they want that.

Gross misrepresentation of one's software will earn complaints to GitHub. It is the responsibility of the author that the repo's readme does not ovepromise and underdeliver.

It's difficult for me to point to any one specific cause of this. I want to say the reduced control over your own computing environment, far greater propensity for litigation and control, and the reduced or eliminated means of using social media website APIs to curate your own online experience.

Everything's feels so helpless and the primary reasons to solve these don't feel like they're technical in nature. They used to always feel technical in nature.

I have to wonder how much of the problem space of individual empowerment is even left for technology to fix?

There's a lot of comparatively wealthy engineers and programmers out there. Enough to fund a powerhouse of a lobbying force. But lobbying to change what is the question?

It seems to me that the current youth generation is less "giving" than previous ones. 70s , 80s and 90s where full of "sharing is caring" mantra. We had people like Stallman, a lot of "crackers" removing copy protection and people just sharing their stuff on an individual level (via edonkey, soulseek, imeem, etc). Same with software, I would never feel "underpaid" for software I release as open source. It's just some code I share, with some open license. If I keep building it, is because I enjoy it.

But now, everyone is driven by monetization so much. Maybe it's the fact that it had gotten more difficult to make ends meet, and everyone is looking for a way ti squeeze a cent.

I just miss those days.

I don’t mean in the narrow of sense of exchanging things for money. If society wants some undefined group of any kind of people to do something but they are not (or they are about to quit) then that’s a resource allocation problem of sorts. That’s the bare problem. This problem does not immediately prescribe a solution like paying someone in dollars and cents. That’s only one solution.

Same if a country is having a fertility issue. The problem is sort of an economic one. But the answer doesn’t have to be paying would-be fathers and mothers. It could for example be to provide more free services that parents benefit from. Or it could mean reducing the hours in the “standard work week”. Or it could be to improve the pension of part-time workers (mothers are often part-time workers). Or it could be to more child-friendly urban planning. Or it could be to improve the public transportation and road infrastructure for households where the two partners work in different parts of the city/municipality/county.

Are professional economists working on this problem? If not, why aren’t they? This seems like it should be their domain. Am I being totally naive here?

Because right now the impacts aren’t particularly noticeable, even for people “in the know”, let alone professional economists who have never heard of the software supply chain

Now this probably won’t happen but it’s still interesting to think about.

I preferred developing minimal-dependency software but my customers demand fast good-enough results. The only way to deliver that is to glue together open source dependencies.

Now that 0% interest has ended 'regular' people like me are not flush with cash. Any time I have I need to spend on activities that will bring in money. Why would I waste that on open source?

(Another aspect is the McKinsey-ification of the work place in the last ~10 years or so. Managers are making decisions in tech now, not tech people. all my life I was told that OSS contributions will look great on my CV. So far nobody who has made a decision to hire me has had the background, interest, or knowledge to judge, or even care, for my OSS contributions.)

1. The GPL/GNU period. The software is mostly called "free software-as-in-freedom". The community is small, volunteer driven, highly ideological and focused primarily on cloning UNIX for commodity PC hardware. Most developers aren't using this stuff at all and work with entirely commercial toolchains.

2. The Apache 2 period. The software is mostly called "open source". The community is huge, frequently driven by corporate donations, not particularly ideological anymore and focused on developer tools / libraries rather than operating systems and desktop apps. Developers now regularly incorporate open source libraries into their commercial programs.

The transition was slow but I'd pick 2008-2010 as the crossing over point. Before that time if someone said they wrote open source software you'd make a weak assumption that they worked somehow on Linux related projects in their evenings/weekends. After that time you'd probably assume they were writing some library and had even odds it was their job.

It's important to remember that 2008+ is ZIRP territory. Money was "free" for investors, so investment piled into a lot of stuff that often wasn't revenue generating because there was nowhere else for it to go. This era was also shaped by a historical aberration - a handful of hyper successful advertising companies whose founders were able to remain in control whilst still selling much of their stock thanks to dual voting classes. Modern developer's understanding of the open source ecosystem, along with their expectation that powerful tools are all free, is very much shaped by the combination of Fed policy and a handful of super rich patron companies that weren't under any pressure to return capital to shareholders.

Thing is none of these factors (ideology, free money, stock with dual voting classes) is historically normal or arguably sustainable over the long run, whereas ordinary capitalism is. So we might well see a reversion to the mean where things like compilers, libraries, operating systems etc become commercial again as relatively high interest rates pull funds out of tech and the supply of Stallmanists devoted to the cause of desktop GNU/Linux continues to dwindle. The recent death of a man who reverse engineered a lot of networking hardware for Linux is an example of this - how many 25 year old hackers want to do that sort of thing any more? They're all writing JS frameworks that only work on AWS these days.

If that does happen though it'll be quite slow. I think the industry would need a kind of Steam for libraries to emerge first, and it's pretty unclear what the next equilibrium phase looks like.

> how many 25 year old hackers want to do that sort of thing?

A lot! More than 30 years ago, that’s for sure. The sheer number of all programmers have increased so much since then.

A few years ago, when I was 25, I was getting into hardware hacking and I found 2 books on the subject.

It’s just hard to find learning resources on reverse engineering hardware, since that isn’t the entry point for programmers anymore.

My hope is that some greybeards will write some resources on how they made harfbuzz or eMacs or whatever.

I’d pay for that knowledge. I’d gladly pay for technical biographies of open source projects.

Open source did exist in 1994: projects like Linux and Python were started around 1991 but nearly nobody knew about them or used them. The average person or developer in 1994 had zero encounters with open source software. Even by 2000 this was still the case: the average developer was working with Visual Basic or Delphi or Visual Studio (all proprietary) using the Windows API or VBX/OCX controls as libraries (proprietary), connecting to Oracle, SQL Server or Access for data (proprietary) and if they were bold, rendering web UIs from IIS or Netscape's servers (proprietary) to Internet Explorer or Netscape Communicator (all proprietary). If they were cutting edge like Google they might be using Linux as a server kernel, but that was rare and a source of competitive advantage. Google wrote all of its own internal libraries starting from the STL upwards partly because there just weren't that many to adopt if you worked on Linux.

> It’s just hard to find learning resources on reverse engineering hardware, since that isn’t the entry point for programmers anymore.

Well, two books is a lot. Back in the day there were none :) I think this shows the issue, right? Yes there are more developers overall, but there are also more opportunities and things to do. Why would you spend hours slaving over a buggy wifi driver when you could try your hand at writing a mobile app instead, which might make you rich? Back in the 90s this was far less of an option for most developers. The original motivation was a desire to use something other than Windows on PC class hardware, but that desire has been satiated by Apple for a long time and desktop Linux remains obscure.

I've experienced all of this. My first open source project was on Windows, back when open source was novel and new. Then I worked on Linux for a while - I had code in Wine and GNOME and a few other things. Then I wrote open source libraries and took part in Bitcoin. These days I do open source work for pay and also sell a proprietary developer tool. So, seen it from every angle. My gut feeling is that we're going to see a resurgence of proprietary platforms and libraries in the coming years.

People do get paid to write Linux WiFi drivers. Especially for embedded devices. But honestly, some people just like that stuff. I’ve watched a twitch stream where a hobbyist reverse engineered the wireless protocol that the valve knuckles controller used.

He spent hours sifting through bits in wireshark.

Some people see a problem and bash their heads against it until it’s fixed. Torvalds is one of those people and I’m sure many open source contributors are too.

Kind of an aside, but what was really cool was that the creator of that protocol was in chat dropping hints.

IMO the big failing of the open source community is selling out too much and not attracting as many enthusiasts as career programmers (not that there isn’t overlap)

Alan Perlis has a quote that goes like “I hope we keep the fun in computing” and I think we failed at that.

My outlook isn’t as bleak. I think Linux is here to stay. I don’t really see a proprietary OS that is as robust and runs on as many different platforms taking Linux’s thunder.

Mobile and VR has android.

Even on desktop, the seam deck is pushing it forward, though it will forever probably remain niche on desktop.

With respect to maintainers getting old, I guess your example is kind of on point. It used to be driven by ideology or the practical desire for a home UNIX. That motivated people to spend the long evenings alone working it out. Now it's driven by building a Twitch audience, and the hobbyist was even getting help!

I guess with respect to stealing Linux's thunder, I feel like that happened 20 years ago already. When MacOS X came out there was a long stream of people 'defecting' to it from the Linux community. It separated those who just wanted UNIX from those who had the ideology and a lot of the energy dissipated from Linux at that time.

And both were called by different names previously.

It is not wrong to say that open source grew up in parallel with the Internet. I see no reason to worry that they will not continue to evolve together.

After I left the first company they provided zero maintenance support for the major upstream feature, and I won't maintain it on an individual basis because life moves far too quickly for that. Occasionally I'll happen to run across exasperated posts along the lines of, "Help this is broken for me! Why is my patch being ignored? Is this even maintained any more??"

Chances are you only care because the company you work for wants it done so they can make some money off a product they're building with it. Half an hour dealing with some random patch and/or bug report for an upstream thing I did 10 years ago is half an hour less I have to spend with my daughter before she leaves for college. Nope, fuck you and your bug report.

No, you can't even pay me to fix it. I have a job, and it's already taking more of my limited time on this earth than I want it to take. The email address I used to submit those patches was deactivated when I left that company, and I ain't handing out my current one.

For any minor contributions I made I had to convince the powers that be that there was no real IP or competitive value in maintaining the patch ourselves, and they after much hand-wringing and delay they finally let me push a few small patches up to the maintainers. In hindsight that ended up being more trouble than it was worth because I wouldn't have been the one needing to maintain that patch in the long run. I should have just submitted it to the company-internal repo and let the next guy deal with maintaining that patch.

In spite of all that, my contributions are still there. They still provide tons of value to both individuals and to companies that mooch off of them. Somehow at some point someone somewhere steps up after enough time has passed to review and merge a patch or fix a bug. Or the bug report just withers and dies, and the world keeps turning.

Small wonder that some might not want to do that, but it doesn't explain why fewer people than previously would want that responsibility, especially if the population of developers has increased.

My guess is that people are less interested in taking over other people's projects than in starting their own.

Like, I release pretty much everything I create into the extended public domain (CC0/the Unlicense/0BSD), so I very intentionally have no dog in this race, but for those who make different choices for me regarding their public contributions, it just seems logical. Maybe it's just impossible to sue someone for violation of the GPL in a way which makes it easy to come out financially ahead, though.

They could sue or try to settle out of court to get the company's own code to get licensed under the GPL, which seems like something they'd want as well.

In that sense an open bounty is like putting a price tag on how much you really care, in terms of hours of your life you're willing to spend (indirectly) enforcing the rules you have set.

That's almost certainly a good thing. Over the last decade plus of my using GitHub on three different occasions I have wandered into a project, submitted a pull request, and the author has simply given me full write access to the repo without my asking. I didn't want it. I didn't ask to be a maintainer of this project.

People can be really weirdly not unconcerned about security.

I would love to work on open-source full time, but I exist in a capitalistic hellhole which employs violently coercive methods - the constant threat of homelessness, destitution, and even death - to ensure I remain “sufficiently profitable” to someone else who already has more wealth than I could ever spend in a dozen lifetimes.

If UBI is ever implemented in Canada to an effective degree, you can bet both your left titties that I would be able to afford the time to contribute. But now? I’m just struggling to tread water.

As someone who did a lot of volunteer work, these issues resonate with me -- painfully so.

That's probably my primary motive for reading such articles when I'm not really a programmer.

Some people know how to add value and don't know how to turn that into an income and if they desperately need income and everybody wants their work but nobody pays them, it's extremely infuriating and crazy making.

I'm a writer and a blogger. Newspapers are dying. If you put ads on your site, people use ad blockers. People find ways around pay walls. Etc.

Sometimes you can't somehow magically control the fact that people won't pay you.

Any institutionally funded project should be forced to take a percentage of the raise and pay it to the OSS projects/dependencies (even the deep ones they dont see).

thanks.dev is a good platform that does this well.

> open source project maintainers are not being paid for their work, spend three times as much time on security than they did three years ago, and have become less trusting of contributors following the xz backdoor, according to open source package security firm Tidelift.

> Tildelift: Reduce security risk from bad open source packages

- there is no FLOSS culture in most people, so the classic model "I publish and maintain my code, others get it from free and give back their improvements equally for free" does not work anymore in most cases. Collaboration culture seems to be very diminished, some try be moral police, some simply do not care etc;

- mere widespread lack of competence mixing, in the past with usenet newcomers and gurus was together, interact and share visions, doubts etc, make all people involved learn. Today with Reddit and co people are divided, gurus with gurus, newcomers with newcomers, these are Indian castes with extremely little "social mobility" and that's a large part of why the mean culture is collapsed and almost all new projects not only in FLOSS but in the whole society are failures;

- lack of a good software base, modern software designed by commercial/managerial needs are CRAP, even the finest one, not because the code is crap, but because the environment is. An OS need to be a single application where anyone can automate their small bits at their competence level, this mode was killed because compartmentalizing anything means more products to sell, this is technically unsustainable and most modern people works in such environments and many young have no idea of the old mode and it's power, as a result good tools left behind, those who know them isolated, newcomers suffer from the lack of proper tooling and can't progress;

- finally the "slavery flat line with a dot on top", meaning only few nowadays do things, the giants, others are essentially their slaves. Most companies have no iron, no operation in house, just sitting on the shoulders of giants, using their iron and operation through their interfaces/services. This means the social FLOSS ecosystem does not exists anymore.

More and more people burned by this model try to go FLOSS, off the cloud etc, but they lack tools and competence and resurface from such disaster it's damn not easy since still the largest part of the world is in the barbaric land of the giants where even damn simple things are complicated because that's makes the money for someone.

Edit: At my current job I replaced a 65 year old retiree that the company thought was an irreplaceable lynchpin. I learned his job in 2 weeks.

https://www.youtube.com/watch?v=h_DjmtR0Xls

I have a project. I'm willing to spend time to help someone learn how to contribute, and in return they'll gain experience they can use to earn money elsewhere. How do you find those people? It's the sales. We have saturated our tolerance for advertising. We just assume everyone who approaches us wants to sell us something right away.

When I started development on my accounting application, I decided to go around town and talk to businesses to figure out what features I should add. I had nothing to sell, I just wanted to talk to people about my own personal initiative. Never mind everyone on the internet screaming that an ERP system can't be done by a single person. No one wants to talk to me, no one cares.

And you all know the best of us are introverts because we focus on the problem and not the sale.

YCombinator: learn to do sales on your own, don't look for sales oriented co-founder. Seriously? Every day it's getting harder and harder to do sales. It's not even sales but social engineering. You hear words like "funnels" and "CPA".

I reached out to my network, I know about 7 people capable of helping me. None had the drive to lift a finger cause they're all too comfortable with their day jobs. I don't blame them, I would be too if I was being paid $100k to change background color of buttons every two weeks.

Yes, what I'm building is of commercial nature, but I have other interests too, like creating mesh network with ESP32 which to me has no commercial value and would be done purely for fun. I'm sure there's people with similar interest exist, but they're being kept guard by social media companies that work against collective initiative. Cause if they didn't, it would be too easy for people to find what they're looking for.

I have interview on 24th. If I get the job the progress on my project stops. I'm 1/4 ways through to production, that's three more years of development. If I had few people to help me, we could complete it in six months and end up with jobs maintaining it.

Like many people pointed out - time is precious, "you couldn't even pay me to do it", "I have a family".

So you have to find people just at the right time who have overlapping free time.

I've run out of money, gotta go back to work.

Increment this counter if you gave up on open-source: 1

To summarize the programming toolsets used in open source are not the kind that hobbyists and volunteers should be using, that is why I mentioned the use of Lisp and other higher level languages compared to C and C++. If you are going to write non-trivial programs and utilities in C and C++ then you should absolutely be paid for it.

Most of the people burned out developing for Linux should focus on a cut down system developed for end users and small businesses in mind.

You clearly haven't heard those jokes about C and C++ have you?

You are talking about unpaid people using the wrong languages to do difficult things and that never works.

http://harmful.cat-v.org/software/c++/I_did_it_for_you_all

https://xkcd.com/303/

The Unix Haters Handbook

http://harmful.cat-v.org/software/c++/linus

http://harmful.cat-v.org/software/c++/

Not only that the industry ignores the foundations and principles of correct and sound programming in low level programming languages like C and C++ which makes things even worse.

Going back to the start Linux did not start of with an intention to be an operating system developed for enterprise users.

Commercial interests took it over and decided to go with it. The simple truth is unpaid hobbyists and hackers should not be involved in the development of enterprise operating systems. Windows NT was not developed by unpaid hackers. Why should that apply to Linux? Unix was developed by corporate employees, and it is only when the GNU project decided to replicate the toolsets it used that Linus decided to build a kernel of his own, after which corporations jumped on it because of the GPL.

Those days are long gone and hobbyists and part timers shouldn't be really involved. It is OK to write and develop programs to gain a sense of achievement and pride from them, but when the need to maintain it kicks in that is when it all starts to south.

Their involvement should on simple utilities for end users. That is what free software development which is not well remunerated should focus on.

https://xkcd.com/2347/

Python is a great example how OSS can be stolen by a small dominant clique that is active on Twitter (now Mastodon) and markets themselves as leaders while having done very little actual work in the past 15 years.

All of this is enabled by Python's propaganda arm, the PSF, which is filled to the brim with mediocre members, most of whom haven't done anything at all but who brag with @psf in their Mastodon and GitHub bios.

It is all smoke and mirrors now.

The choice of language has absolutely nothing to do with it. Not in the slightest.

This cargo cult nonsense does not make you smart or cool. Try some critical thinking next time instead of regurgitating catch phrases you haven't even bothered to analyze.

You clearly haven't heard those jokes about C and C++ have you?

You are talking about unpaid people using the wrong languages to do difficult things and that never works.

http://harmful.cat-v.org/software/c++/I_did_it_for_you_all

https://xkcd.com/303/

The Unix Haters Handbook

http://harmful.cat-v.org/software/c++/linus

http://harmful.cat-v.org/software/c++/

Not only that the industry ignores the foundations and principles of correct and sound programming in low level programming languages like C and C++ which makes things even worse.

Going back to the start Linux did not start of with an intention to be an operating system developed for enterprise users.

Commercial interests took it over and decided to go with it. The simple truth unpaid hobbyists and hackers should not be involved in the development enterprise operating systems. Windows NT was not developed by unpaid hackers. Why should that apply to Linux? Unix was developed by corporate employees, and it is only when the GNU project decided to replicate the toolsets it used that Linus decided to build a kernel of his own, after which corporations jumped on it because of the GPL.

Those days are long gone and hobbyists and part timers shouldn't be really involved. It is OK to write and develop programs gain a sense of achievement and pride from them, but when the need to maintain it kicks in that is when it all starts to south.

This is my conclusion too. None of the reasons C/UNIX won are valid anymore and it's essential kludgyness has cost us incalculable time, money and brain space. Imagine what the open source community might have achieved with a real high-level language. Instead we've given them layer upon layer of inadequate tools and told them that if they can't manage the mess they are too dumb. So we spend more and more time in maintenance than in development. Who wants to juggle pointers, increment counters, and do their own garbage collection in a Jenga tower when they could just write their own nouns and verbs in Lisp? I'll be working on exactly this.