Maybe there is nothing wrong with the "status quo", maybe we don't need yet another attempt to finance small FOSS projects where it's hard to explain how money will actually solve any of these issues.
Maybe people just need to be more considerate of what they depend upon. And in the case that a popular yet well maintained project has a CVE on day, maybe we need to accept that popularity does not make them invulnerable to bugs, all software has bugs.
Open source always trails professional software solutions. Yet always time after time will eventually surpass it as the bleeding edge moves further. Maybe we can view it in such a way that major companies have become too reliant on free open software. If you want secure software, pay for it. The knowledge will eventually flow down to free software because it's ultimately run by hobbyists. I like the way it is and I don't see it changing because so many are just donating free time to open free software. Maybe something we could do is make open source contributions tax deductible (if we could somehow price it accurately)
That's more an argument against old-school "no amount of architecture is ever enough" Java -- not so much an argument against the principle that engineer-time can fix bugs.
This bug was not consequence of not enough developers. And there will never be guaranteed "no security issue" situation. That level of certainly is simply too expensive.
I don't really see how the Log4J2 issue would have been uncovered by testing. It's not really a bug but more of a design flaw.
The reason is that the whole JNDI string interpolation feature by itself opens a door to a whole world of layered complexity which you can't comprehend. And even if you could comprehend it all Java could add some feature to JNDI which introduces an issue which wasn't there when it was all tested.
Anyone who knows anything about JNDI would've immediately recognized that this was an incredibly bad idea, as JNDI attacks are well known around black-hat circles (LDAP is just one of the things you can do once you have JNDI available).
Yet, here we are, several years later, acting surprised this thing existed and thinking that tests would've helped!? What kind of tests, exactly?!!? I think I am to blame myself, as many other Java developers who actually use log4j, has a good understanding of how it works, knows JNDI and LDAP, yet never connected the dots and noticed what this incredibly stupid feature was making possible.
I would say that this is different from "hard to explain". What is being proposed is essentially "OSS with a paid model for premium support / feature development." It shifts the language from "donations", which companies don't understand, to "consulting", which companies do understand.
It's not completely novel, projects such as openssl and sqlite do offer paid consulting, but it's not normalized among companies to pay for doing so. If Filippo can normalize having OSS be treated as paid consulting engagements I think that would be wonderful for the community.
> OSS with a paid model for premium support / feature development.
Adding features do not reduce likelihood of bugs, if anything the opposite.
It's very difficult to come up with a paid model that specifically encourages a preventative strategy towards bugs and security flaws. Currently the best we have is getting people who care about those things to build software.
Yep. Working for a company that makes paid for software and customers always want more features. It's really fun when paying mutually incompatible features added and the sales people and developers go at it for months trying to figure out how to make it work.
Then, maybe a year later, that feature is no longer the hot new thing and it becomes abandonware inside the application. If you're app isn't cloud based you have no idea if you can rip the feature out or not as you have no idea how many people, if anyone still uses it.
Quite honestly, I think that if companies paid open source maintainers to get the features they wanted, the log4j problem would NOT have been averted at all, it would likely have happened earlier... notice that the source of the issue (support for JNDI lookups right into any log messages) was introduced because of someone asking for that feature (and getting it for free!)... if a company had paid for it, it would've been just the same, I doubt very much the company would have done any kind of security veto on the implementation.
What's needed is for open source libraries to somehow get "rated" by security experts before they get used by businesses. If those businesses using it paid for that, and then paid someone to fix any issues found, then I think we would have a working solution. Just paying for features would just make things worse... have you ever seen companies paying for security features, though?? No, I haven't at least... they pay for business features that will make them money, they hope, security is kind of just implied (and they might lay the blame entirely on the developer if they actually had a business relationship with them - which may be a big nightmare, actually, for OSS developers - and I am one of them myself... you can no longer use a license that just says you're not liable to anything bad that happens).
Perhaps OSS has become too sophisticated and professional-standard for its own good, while still being created and maintained by amateurs.
I have an analytics package which is apparently being evaluated by the military of a large country. Even if secure code, now the maintainers themselves are under attack.
For I am definitely a weaker link than a soldier or agent or gov department. Did not expect such usage when creating this project. If said government had seen how this was developed and tested, they would probably physically destroy the machines it is installed on.
Most every company I've worked for, large and small, has paid for professional third party security audits that scrutinize the dependency chain. log4j still wasn't flagged as problematic.
Open market dynamics should in theory change this one way or another. Long term you can't have some code cost $0 while an SVE's code costs $300k+ per year... Reality is open source code is badly mispriced right now.
There are salary discrepancies everywhere in the world. If you mean the salaries across countries, you're comparing apples and oranges. €100k in Berlin goes much further than $100k in Houston (a random big city in the US, I don't think Berlin is comparable to NYC)
Tech companies also pay for health insurance, sick leave, and ma/pa leave. Sure pensions aren't a big thing, but increased savings from increased salary can make up for that (not to mention 401k).
The difference: It's not up to the companies in most of western Europe. These services are guaranteed by law, and provided by the state.
>but increased savings from increased salary can make up for that (not to mention 401k).
And huge medical bills can quickly eat up even substantial savings...that doesn't happen as easily when medical services are provided by universal coverage.
Also, state guaranteed pensions aren't lost if some company in a portfolio crashes.
The problem with that is that you end up paying everything twice because state funded healthcare sucks, the state pension sucks and the state paid ma/paternity leave is quite short.
If you're in a good tech company in Europe you generally end up having private healthcare, a private pension with employer's top up and extended ma/paternity leave.
The problem is that taxes in the USA are still fairly high and comparable to the ones in EU - you would expect some services for the amount of money you're paying.
That said, having lived in countries with state run services all my life, I don't think the solution is state run services, but cheaper private services. The problem in the USA is that governments and insurance companies inflated the cost of healthcare ridiculously.
Similarly the cost of universities in the USA has been inflated following government intervention.
Talking about state run services:
Between waiting times, poor support and the lack of competition the quality is pretty bad, despite what the state propaganda will tell you.
Having lived in the UK and in Italy I cannot but laugh hearing that NHS or the SSN are "the best healthcare systems in the world". The amount of bad experiences I had is ridiculous (some of which could have damaged my family health, had we not had the money to pursue private treatment).
Universities in Italy, which are pretty cheap at 3-4k€ per year, have several deficiencies and, despite having a handful of great professors who do it out of passion (maybe while running a profitable business on the side), it has its fair share of problems.
Not to mention the amount of freelancers in Italy who pay pension contributions every month who will never see a penny for their money.
One thought: i disagree with the classification of (senior) software engineer.
i think it’s more comparable to a VP of Engineering in a company with n engineers (n = count of committers/involved), so salary estimate are even higher.
At the very least, it's unsustainable to maintainers as people, because many are burning out (I have no data, so this is an assumption).
As a result, it's also unsustainable to other coders because the OSS ecosystem grows replete with broken and stale code that is no longer maintained and which creates cognitive cost to ignore/prune.
Both might grow in a non-linear fashion, which would be really bad news.
It has certainly 'worked great' for leeches, if you ignore bombs like this logging bug destroying Western civilization.
Can you explain a bit more how it worked great for the bulk of maintainers / authors who don't see any return on their work, burn out and have to do something else?
And for communities, and for sponsoring companies, and for some (although not all) authors.
> if you ignore bombs like this logging bug destroying Western civilization.
...yeah, no; a library had a bug. Somehow, Western civilization is still here.
> Can you explain a bit more how it worked great for the bulk of maintainers / authors who don't see any return on their work, burn out and have to do something else?
Can you explain why you think the majority of authors/maintainers burn out?
> That was exploited since April
... this 'bug' is RCE on the logging infrastructure.
And yet, Western civilization is still here.
>> Can you explain why you think the majority of authors/maintainers burn out?
> Please try maintaining a popular FOSS project for a few years
The majority of projects aren't popular, so you're comparing apples to oranges. For many, I suspect most, projects, the user base is tiny and low pressure.
> authors who don't see any return on their work, burn out and have to do something else?
I don't understand this argument. Nobody starts an open source project - and posts it in the open to share freely - expecting to make any money. Are there even any significant amount of projects with a donation or a Patreon page?
Webnovels I read on RoyalRoad all have it and are much more successful that I would ever have thought given that the stories are all coimpletely free and all any one who pays a story author gets is a few chapters ahead of others, but I can't remember any of the numerous OS projects I use one way or another to even try to make any money.
I did see burnout in some projects. I once joined as co-maintainer of a medium sized project and was left as the sole maintainer because the main author just up and left and was unreachable (we only heard of him again over a year later, and he never touched that particular project again).
All the stories I saw had nothing to do with money at all though, just getting fed up with the expectations. In "my" project's case it also was the large amount of complexity and technical debt that made the original owner's attempts at adding and/or refactoring a huge time sink, and he probably would have been better off to start again from scratch (it's what happens after adding more and more features in a complex cross-mobile phone platform library project's code).
None of those "disillusioned open source maintainer" stories I saw ever included any attempt of making money with it. Disappointment of not being able to get money from anyone only ever comes from people starting a commercial project (a new company), if that kind of disappointment exists for freely shared open source software then I must have missed all instances of such a thing happening.
> It has certainly 'worked great' for leeches, if you ignore bombs like this logging bug destroying Western civilization.
All of life and especially commercial life in anything slightly sophisticated or at scale is "muddling through" to some degree. The same as biological life actually.
So overall I agree with the previous statement that it worked quite well. Nobody should be called a "leech" for using projects that were meant to be shared openly and freely, given the license and method of distribution (e.g. freely on Gitlab or Github).
Do you pay for every piece of Open source software you use? How much? What is the criteria you use to determine how much you want to give them?
Yes, it would be very good if more people started to contribute to software they depend on, but to call them "leeches" is not only against the spirit of free software, it is counterproductive as it will probably lead people to the idea that proprietary/closed source is better.
No... projects want contribution more than money, the idea of paying the author is that they can then continue to contribute in the long term by proxy for the payers.
But FOSS-systemwide, I give much more than I take. It just needs leechers, who systemwide, give nothing back, to do the same.
Let me try again: how do you measure how much you have given and how you have taken? If not (only) with money, how do you estimate the time and effort that you put into collaboration?
If you ask five different people to evaluate your contributions, how much would they agree? How much would these people be interested in contributing as well and/or paying for you to keep doing what you are doing?
The point I am trying to make: people express their preferences differently, and that is a Good Thing (tm). Market dynamics are a Good Thing (tm). Each of these critical RCEs work as shock on the whole ecosystem which makes it a little bit stronger. I'd rather have a dozen of RCEs on popular-but-amateurish maintained projects than a little totalitarian forcing everyone to "stop being a leech".
I have no sympathy for maintainers who give away their work for $0 and the act all surprised when the world pays $0 for it and value it at $0. Wake up! Look around and notice how the world actually works and act accordingly. If you want people to pay real $ for your work then make that the price tag.
If you want endless unmaintained security apocalyse -ware at all levels of your organization, just keep using FOSS dependencies while explaining to yourself you don't have to contribute anything back.
"Look around and notice how the world actually works"...
Yes because that is the only possible alternative. Without FOSS the planet will obviously instantly explode and turn into a black hole. Right. I've got news for you: your life depends on closed source commercial software. Every time to take a lift, drive a car, fly an airplane, use your credit card, use your bank, drink water, buy products, use electricity, is a passenger on a ship etc. you rely on commercial software. And yet somehow the planet hasn't exploded yet. So yes look around and notice how the world actually works. Having said that, I think FOSS is a good thing. But make sure companies pay $ for it. Don't give it away for $0 and then sulk when people pay you exactly that in return.
there is no past tense for unsustainable, so if one wants to indicate something was unsustainable in the past they say it 'was unsustainable' but if they want to indicate something will be unsustainable for the future they just say it is unsustainable, one of the downsides of English; also, past performance is no indicator of future performance applies to many things outside investing.
In other words open source as it was practiced was sustainable up until the point it got taken advantage of too much by big players not putting things back into the system. At this point it has become unsustainable.
Everything stated about the risks and current deficiencies is true. Meanwhile the OP works for Google on OSS, one of the "untenable" approaches to funding it that is lamented. Nothing else presented is close to an alternative solution; there's no "ask" that would fix the situation, let alone an attempt to lead by example, so what's the point of this post?
> This is what I hope to see happen more and more: Open Source maintainers graduating to sophisticated counterparties who send invoices for "support and sponsorship" on letterhead, and big companies developing procedures to assess, approve, and pay them as a matter of routine so that they can get what they need from the ecosystem.
>But! Maintainers need to be legible to the big company department that approves and processes those invoices.
I imagine this could be a hard sell to people who just want to build some cool software and maintain it. Setting up an account, okay, that may be possible, but that's not the end of it. Companies pay invoices FOR something. That something means contracts, potentially about substantial sums, that means getting legal support to navigate said contracts & obligations.
We have software licenses and yet every open source project doesn’t employ a lawyer. The solution is probably the same: canned, off-the-shelf contracts. If a company wants to negotiate a custom contract, then the maintainer can decide whether or not it’s worth hiring a lawyer.
Even if the contract itself might be commodified, the relationship won't be. Business will want what it wants, regardless of what the contract says. Maintainers will certainly be subject to influence campaigns by business, which will sometimes conflict with other "clients". Even saying "no, read the contract" to a persistent VP has a psychological and social cost. I can't really imagine this decreasing the pressure on maintainers: it's basically turning the project into a startup.
I think the idea is to provide a middle ground option between full-on startup and doing free work for corporations. That implies meeting in the middle both on compensation and on work delivered, but it's possible that we'll find new non-zero-sum opportunities.
I feel like the examples of log4j and ua-parser aren't that great, because it would be relatively easy for any other similar lib to take their place, as it's mostly straightforward to implement, even though it still takes time.
But there are some things like Kafka, PostgressSQL, Spring Boot, Tomcat, Apache Math, ZooKeeper, the OpenJDK, and all that which are definitely non-trivial and a huge amount of time and effort, and you couldn't just take an extra month or two and have a dev on your team implement a replacement, unlike log4j and ua-parser.
I think those would be better example to discuss, and my impression has been that those things often have a company behind them offering support or offering them as a service that in some ways pays for some real devs to contribute to them, but maybe I'm mistaken.
Like for example, the author mentions working on the GO team at Google, and Go I would consider one of those big open source projects that truly are foundational and would be non-trivial and huge effort to replace. So that shows that the really big pieces do have companies hired and paid staff behind them.
Quite a few managers I have spoken to will use the exact reasoning ("we could rewrite this in two weeks or so, why should we worry if it disappears?") and do indeed seem to think that the fact that because the OSS dev did not get paid for their work implies that it is low value work. If it was in fact high value, they would have gotten paid for it you see.
As a developer, if there were no free open source logging library, then I'd be paid to implement one at my work. It be a fun project, but because someone is willing to do it for free, and give it away, it's hard for me to justify to my employer that we should build our own.
This is how the value is measured.
But if you take a much harder task, like building a performant and safe JIT language runtime like the OpenJDK, you'll see that even in the open source model, people can't actually deliver it effectively for free. It often starts out from a company that later open sourced it, or it's backed by academia, and contributions require deep expertise, so sometimes companies had to have their own staff contribute to it on their own payroll.
>I feel like the examples of log4j and ua-parser aren't that great, because it would be relatively easy for any other similar lib to take their place
Log4j is a good example, anyway. It's an old library, very old. And a lot of other software depends on it. So the effort of replacing log4j is not proportional to it's feature list, but rather to the feature list times the number of projects already depending on it. (The replacement exists, btw, called slf4j, usually with logback, written by the same author as log4j.)
Java Logging is a subject in itself (I won't say "interesting subject" although it is interesting, in the same disturbing way the lifecycle of a tapeworm is interesting.) but I would argue that these logging libraries are old and have evolved over time in ways that are hard to anticipate or recreate. (Rewriting things also leads you to the xkcd "standard proliferation problem" - https://xkcd.com/927/)
The real problem is that it takes time, like real calendar time, to understand an implementation fully enough to fix it, and no-one wants to do that, because it's a job as critical as it is thankless.
I tend to use Logback for new code an the slf4j log4j bridge when an old library (usually Hadoop) likes log4j. Log4j hasn't been the first choice in Java logging for a while.
There are some maintainers for Postgresql that get paid. It’s a part of their job in consulting companies (they specialize in postgresql). Not sure about the other projects though.
You can get a closer view of this sentiment in action within communities built on open source with distributed governance. Very many communities in the blockchain space routinely discuss how to compensate the development work necessary, and the recurring theme is that people imagine a nonexistent cheap developer:
An engineer with in Micronesia with specialized skillsets.
Try to convince these communities about the need for a well compensated team of people including product managers and designers all making 6-figures and honestly people just don’t believe you. The truth is that cost of living discussion doesn’t even matter, people should be compensated on the value they bring (and in those communities that is very easy to quantify.)
This has wildly slowed down many projects as UI and usability are completely neglected.
Its pretty much only been one year that an engineer in this space can reliably land compensation packages somewhat competitive to a tour in NAAAM
The solution to this, along with many other socioeconomic problems, isn't going to be solved through voluntarism.
This is easily solved with a universal basic income. Some of us would gladly forever maintain and contribute to free software if we had our basic needs guaranteed.
> The solution to this, along with many other socioeconomic problems, isn't going to be solved through voluntarism.
Open source has been incredibly sucessful using voluntarism.
We could also throw in political movements; the all-volunteer military, which has existed on and off since the American Revolution; science (the pay doesn't nearly match the efforts and value); non-profits; teaching (same as science); etc., etc. Why do people feel so motivated to sh-t on voluntarism, which has changed the world with great success. Almost every major advance in history has been accomplished by volunteers (depending on how you define it). Declaration of Independence, Newton, Van Gogh, World Wide Web, etc. etc. etc. ...
I agree that appropriate compensation is necessary,
but I don't think it's sufficient. There's a lack of
visibility and tooling for dependency management/auditing.
I can't even find a proper list of critical OSS along with
their donation links.
Moreover, there needs to be a fundamental re-thinking of
the security model of languages and runtimes, i.e. even
if I can eval() user input or load a plugin from the network,
it should not be game over. There should be finer-grained
access control in programs, both at the type-level and
with how they interact with the OS. The global view of
"your program can do anything unless said otherwise"
needs to change.
I'm an open source author and maintainer of a somewhat-popular python package[0] (~1M downloads/month) that I've maintained for over 10 years. I don't recall ever receiving a donation. I am still maintaining it, but I just don't have time to add the improvements that it needs to keep up with the ecosystem (asyncio, for example). If organizations who use it got together and chipped in some non-negligible amount, I would be much more serious about keeping up with it, but $0, or $5-20/month, is just not realistic incentive to compete with other priorities in my life. I don't know the answer, but that's my thought process.
First, I don't use it, but thanks. (I know, being a maintainer is a thankless job, but I'm a rebel.) Second, the OP addresses this issue directly. He's talking about "making OSS maintenance legible" (emphasis mine) to BigCorps via 5-6 figure invoices "on letterhead".
It's a grand idea, and I hope it works. The path to not working is too achingly obvious though. Budgets are always tight (even if you're Apple and you have to artificially make money feel tight). What corp officer with budgetary discretion is going to greenlight a 5-6 figure payment to someone who's not doing work directly for the company? I think the key here is that that person is going to have to a) be principled, and b) smart about selling it, by emphasizing the fact that the changes were beneficial to our company, and leave out the fact that those changes were beneficial to every company. It wouldn't hurt if BigCorp got a measurable recruitment bump from it, too.
If I could figure out for certain which big companies were using my software, I might try the invoice idea for fun. I expect it would be ignored, but I would send it anyways to prove the idea one way or the other.
Big companies don't just pay random invoices;* you need to indicate what project and account (usually IDs from their CRM). So it would merely be chucked out.
* In really big companies it's possible for admins to buy routine stuff below a threshold just to save on paperwork. So there's a scam in which someone sends out a bunch of $100 invoices for "printer paper" -- account payable assumes the department code was left off by the vendor but it seems legit so they pay it. Seems like a hard way to collect money.
It's called a Purchase to Pay system - whoever makes an order supplies a Purchase Order number from their internal system, which the supplier will reference on their invoice so the accounts team can look it up before paying it.
In terms HN would understand, it's a stateful firewall for invoices that prevents paying orders that didn't originate from your company.
If you hosted the package/library yourself instead of in closed silos/package repos, you could directly check the IPs of whoever regularly pulls your stuff.
We all opted for centralized package repos though, so now only they know. And they’re not telling us.
Just another “free” opportunity lost to centralization, I guess.
> We all opted for centralized package repos though, so now only they know. And they’re not telling us.
I'm sympathetic to the view, but there really are some things that are better centralizing. Reducing code into binaries is something that a "fair" 3rd party is going to be better at than the 1st party. Why? The 3rd party central source is (presumably) mechanically cloning and building, whereas the 1st party is doing much much more. Effectively the 3rd party offers a better guarantee to the end user that this binary corresponds to that particular source.
Also, the Way to measure who's using your code is to put runtime telemetry in there. Distasteful, but so common now with every kind of software, it's crazy. Yes, even OSS CLI programs phone home now (heck, ohmyzsh phones home every time I open a terminal!). For a generic server library, you'd add a check to make sure it's the most recent version and print that out to stdout on startup.
See, it's not user hostile it's to keep them informed of updates! /s
Good for you. The welfare queen megacorps have been too comfortable expecting handouts like open source charity work and public bailouts. Open source software has served the elite executive class while leaving working people to depend on anti-freedom proprietary offerings. I am sick of watching it go down like that. The never-ending data leaks, dark patterns, lock-in strategies, and attacks on encryption and freedom of speech, are all exacerbated by this tendency to yield the commons to the ruling class. If open source doesn’t serve working people, I don’t care a lick for it anymore. Cheers to Stallman and all, but this is where his proposals fell short.
it serves everyone. it's technology. free intellectual "property". free and open innovations.
obviously these tools amplify their user's productivity. corps are organized to be economically productive, hence they benefit enormously from free power tools.
hobbists benefit too, but since their productivity is low they benefit relatively little in terms of economic surplus.
(sure, I might do my taxes using free software, but my taxes are also trivial, two lines and that's it. sure, I might whip up a blog/website using free software to share stuff with people, but again it's economic productivity is already zero, it doesn't matter if now it's a technologically amazing site.
and sure, I work as a freelancer using these free tools, but again my productivity is very limited compared to, relative to the systems I work on for corps.)
the solution is probably a mix of a bit of wealth tax and consumption taxes.
Oh, wow. I've used this before. I think the python community needs to work out how to make it easier for us to identify and donate to maintainers. When I pip install, I never get a donate here: some url. When I npm install, I do (arguably too much). Anyhow, sh is handy. Thanks!
No idea whether it would help but clearly staying exactly
> I've maintained for over 10 years. I don't recall ever receiving a donation. I am still maintaining it, but I just don't have time to add the improvements that it needs to keep up with the ecosystem (asyncio, for example). If organizations who use it got together and chipped in some non-negligible amount, I would be much more serious about keeping up with it, but $0, or $5-20/month, is just not realistic incentive to compete with other priorities in my life.
may be a good idea.
Even if that would not help this project then making people aware about problem in general would help.
The answer is to use a license that require companies to pay. If you ask for $0 then people will gladly pay you $0. It is naive to expect anything else.
I really don't think there's an answer. The ideal form of Free Software is just people sharing their solutions out into the world. We should just be thankful that you've decided to share it rather than keeping it private. If people thought a customer service relationship was something they needed from you, they'd pay you enough for you to start a company based on this.
I would be pretty skeptical of projects that try to keep up with the ecosystem, if they are adding things just to keep up (rather than because they need them). The fundamental advantage of Free Software is that the people writing it are doing the ultimate dogfooding. A Free Software project that is adding functionality they don't need is no better than a company in terms of knowing what "customers" want or how to evaluate whether they did it right.
I maintain a much, much smaller PHP library[0] (~1-2k downloads/month), and I've made a few thousand dollars in sponsorships, donations, and paid improvements to the library over the past year. I don't try all that hard to solicit donations, but I do have a donate button and a request for people to sponsor the library right near the top of the README. I noticed you don't have any visible donate button -- I'm guessing if you added one, and a little blurb about why people might want to donate, you'd up your donations quite a bit.
The only reason I’m able to maintain a reasonably successful open source library is because it is part of an open core business model. Without that I couldn’t justify the development effort or relentless support to myself, or my family. Getting a few hundred dollars a month wouldn’t cut it either.
Building a business on a stack of other people’s hobbies isn’t sustainable. I mean, just tell that to anybody outside of tech and watch their reaction.
This post didn't go the way I thought it would. When these discussions get going, I always feel a little guilty because my tiny company doesn't pay for all the open-source software we use. I suppose we should, but it would be hard to make a business case for that, since the software is already free. It would be easy to conclude that this is a problem for the big, rich companies to solve, but I'm suspicious of advocating any action that I'm not willing to do myself.
I feel as if engineers at firms that build systems that use open source libraries should campaign internally to create budget line items for paying non-trivial amounts to the maintainers of those libraries.
I find it difficult to blame developers individually. Individuals working at these companies aren't going to see it as their role to send some of their own after-tax income to maintainers via GitHub Sponsors unless they are unusually charitable. But I could definitely see my company sending thousands out the door (pre-tax) every year to the maintainers of the libraries we depend on.
For example, imagine your team is 15 people. Have the company budget for and send an additional one developer's worth of salary out annually to the open source maintainers, divided among the libraries in a proportion agreed to by the development team. Yes, it's an additional cost line item, but it's the right thing to do and it won't break the bank.
Open source has reduced costs dramatically for all of us who use it in our dependencies list. A nominal cost line item on our annual budgets is more than fair.
This makes more sense than blaming the developers.
But ultimately the problem is the same: engineers, i.e. employees, don't control the money. They don't have agency to direct the money toward functions other than enriching the people who have the money.
They may have more agency relatively speaking than free software developers, but on an absolute scale, you can measure this kind of agency in dollars, and it's a pittance.
Maybe they could donate some of their own salaries. Maybe they could get employer matching. Still doesn't seem realistic, but it's closer.
Why should they? Open Source developers give away their work with a price tag of $0. So why should anybody pay more than $0 for it? Do you pay more than the asking price for things you buy?
Maintaining business relationships with $megacorp is one of the primary reasons OSS maintainers (maybe just speaking for myself, but I don't think so) do their OSS work, and don't develop proprietary software and market and sell it around a business venture.
If you start writing up contracts or accepting direct payments with any strings attached at all, the dynamic is completely changed.
Not to mention that the dynamic would completely shift in terms of community contributions. If I submit a patch to a free project where the maintainers make nothing, I wouldn't even think of asking for anything in return (even if it is a project used by bigcorps, such as Redis or GHC). If I know that the maintainers get paid a full salary for maintaining the software, it becomes a much weirder thing to send them bugfixes for free.
"Sending them bugfixes for free" is both a benefit and a burden to an open source project. It takes maintainer time and effort to review the fix, test, make releases, etc, and that's a thankless job. When a company pushes their patches upstream, they're gaining a benefit for themselves (avoiding maintaining a fork), and potentially benefiting any other users who might be affected by the bug or want the same feature. But they're also adding to a maintainer's workload, and that's often the scarcest resource in open source.
Fair enough, but I didn't mean sending in bugfixes because I need it for my employer, I meant sending in bugfixes (or features) to a project that I wanted to make because it bothered me. For example, some time ago I sent in a patch to use better data structures in an event loop library that I think is cool but otherwise don't use.
Should OSS devs optimize for my (probably quite rare) use case? Probably not, but the feeling when making a patch for something that I like is still different when the maintainer runs it as a business compared to when they run it as a hobby.
(This is what the whole discussion seems to be about btw. Some people like to program in their free time as a hobby and other people would REALLY like guarantees about the software that cannot be made without losing the essential hobby-ness of it)
I knew it was largely corporations but thought the final call was with Linus/the lieutenant system, and that Linus specifically wasn't beholden to any particular corporation (well, barring binary blobs I suppose). Is that no longer the case?
Linus is paid by the Linux Foundation, which is funded by corporations. I don't either LF or their funders have any influence over Linus. The funding side of things doesn't seem to matter though, because those corporations contribute directly. For example, there was some DRM enforcement code added to Linux and more recently Intel is trying to get their "software defined silicon" stuff into Linux.
Filippo, I think that what you are proposing is an unusual, even radical idea. I hope you are able to follow through on it for yourself and that you can inspire others to do so by seeing the path you are marking.
Once upon a time, the best way to get a software job was to demonstrate your ability to build useful open source projects. 10 years ago the Principal Engineers I would work with had super sized open source portfolio's which leant them both credibility and experience building products people liked. Junior devs would search (sometimes in vain) for issues where they could contribute a few PRs
Now the best way to get a job is leet code, leet code, and more leet code. Rather than spending <5 hours a week working with real code and producing real value on open source projects - most career minded engineers will simply focus on leetcode.
Not many people patch esoteric software that's been around for 10+ years because it's particularly fun or because there is specific business value in it.
> Now the best way to get a job is leet code, leet code, and more leet code. Rather than spending <5 hours a week working with real code and producing real value on open source projects - most career minded engineers will simply focus on leetcode.
Maybe more broadly: The only way to prove that you're good at X, is to do X well. An artist is only as good as his portfolio. The same is true for all creative jobs.
I'm thinking that these proxies (see all attempts at standardised testing) are a disease of our time.
I'm not sure I fully agree. Doing open source doesn't mean you do it well. You have no sense of how quickly, efficiently and independently they managed to achieve it. I'd much rather hear from prior experience, and probe about situations and scenarios they were in, projects and problems they contributed too, and hear the story of how they went about it, how long it took them, what they did in the face of setbacks and pressure, etc.
I have seen first hand developer that are just okay or below average successfully deliver on open source, because you have infinite time, no constraints, no stress and get to choose exactly what you do or contribute. But in a work environment they struggle, given ambiguous problems they struggle, given time constraints they struggle, given changing needs and demands they struggle, working within a team they struggle, given something outside their area of knowledge they struggle, etc.
I don't think there was ever such time. Only a tiny minority of developers ever has open source projects and some companies even actively discouraged that.
Moreover, with industry moving towards agile, having project and developing in a company are massively different kind of work.
I don't know if that is objectively true. There are numerous small companies who will leetcode every candidate. Then there are Google and Microsoft and the other bigs who hire thousands of people every week, where the best way to get hired is to have a Ph.D and get referred by insiders.
Mediocre candidates getting leetcoded by mediocre companies may be a highly visible pattern but on industry scale I am not convinced it is the dominant mode.
This might sound weird, but I find every time someone publishes or contributes open source, they are stealing value from me, because it is one less thing that a company will need me to implement, build and maintain for them, instead they'll now expect me to simply use the existing free of charge open source one.
Not only does it feel like I'm stolen value, open source work tends to be the most interesting, and as more and more is done and offered for free, my work becomes less and less interesting, and the job becomes more about connecting and configuring all these open source systems together.
Needing to contribute free work in open source before getting a job therefore sounds like the biggest of scams to me.
I guess in the same way that public libraries steal value from book publishers and public education steals value from private tutors. Also, how rainwater steals value from bottled water companies, fresh air steals value from air filter vendors, and sunlight steals value from the electric company.
Libraries still pay for each copy of a book, and in some countries royalties are paid out each time the book is borrowed. The library is not allowed to make additional copies of a book and borrow them either. Public education pays its teachers.
But overall I'm not in disagreement with you, you could say open source is done as part of the greater good and advancement of technology and computer science, and not for personal capital gain. That also means that it isn't meant to be a sustainable career path, or job that you can do full time though.
I can understand the perspective. But it goes both ways: Aren't you (and I) 'stealing'? How much do you use open source, as a developer and as a user - and just to post his message: try enmuerating all the open source that goes into it.
> How much do you use open source, as a developer and as a user
As a user I agree, things would probably be more expensive if nothing was open source. But as a developer, I disagree, my employer would simply need to pay for the stuff I use, or they'd pay me or another developer to build them one. And this is precisely what the article argues, that companies should pay for it. If there wasn't any open source logging library, the maintainer could either work for a company that offers a paid one, start his own company, or work for a company that pays him to maintain one for them.
> But as a developer, I disagree, my employer would simply need to pay for the stuff I use, or they'd pay me or another developer to build them one.
Good point, but you would have a much smaller industry and platform without FOSS, and there is no way you could build all the libraries, tools, etc., yourself. Even FAANG depends on FOSS. If everything had to be paid for and professionally developed, licensed, etc., there would be much less around, and nobody could fork and innovate - there's a reason people develop and use FOSS.
I think that's the counterargument, and I can imagine it being true, but I also think we just don't know. Maybe there'd be just as much advancement but more developers would be properly compensated. It's hard to say exactly what would have happened because we're talking an alternate history.
Lowering the barrier to entry by being able to leverage a lot of free stuff probably helps make the industry bigger in having more startups, but I also can't say for sure there wouldn't be more jobs or higher paid jobs otherwise.
In the end, I'm not trying to push to end FOSS, but I'm trying to bring to front the contradiction I'm seeing of people wanting FOSS but also wanting FOSS developers paid a full wage. It seems fundamentally at odds, if you want people working on logging libraries to be paid full wages, stop making FOSS logging libraries.
> I think that's the counterargument, and I can imagine it being true, but I also think we just don't know. Maybe there'd be just as much advancement but more developers would be properly compensated. It's hard to say exactly what would have happened because we're talking an alternate history.
Yes, valid and important point. We could look at how other industries develop. Software + Internet is especially condusive to 'free' products. Other industries must at least share knowledge, which arguably is embedded in FOSS software.
> I'm seeing of people wanting FOSS but also wanting FOSS developers paid a full wage. It seems fundamentally at odds, if you want people working on logging libraries to be paid full wages, stop making FOSS logging libraries.
We benefit far more than we can repay, but "stealing" is too strong. It's what the author who adopted an open source license explicitly intended to allow.
That's a good point. We as developers trying to make a living doing it are competing with an ever-expanding sea of OSS. And therefore we'd be mad to contribute to it, for free even.
On the other hand, from the viewpoint of all of humanity, it is great that there exists a huge amount of software that is useable by everyone for free.
This is just the broken window fallacy. Hobbyists giving away schematics for unbreakable windows are not stealing from your window repair business.
Yes, having open source competition means you'll have to either build a superior product that customers are willing to pay for, or find another niche. That's a good thing.
Good has many dimensions. I'm saying that as a developer, FOSS means people don't need to pay you to build those things, only to use them, and that's why FOSS developers themselves don't get properly compensated, because they chose to build it for free.
You could say FOSS is a good thing if you talked about computing progress, or barrier of entry for a startup wanting to build an app, or as a great source of example to learn from, etc.
As for your comparison, I don't think it holds, because very rarely are FOSS contributors hobbyists, most of them are professionals. So it is much more akin to a professional window engineer giving away free schematics for unbreakable windows, which means that companies manufacturing unbreakable windows no longer need to pay a professional window engineer to make schematics for them.
I'd wager companies hire based on leetcode because it's efficient from an administerial perspective. It can be easily automated and helps weed out a greater number of poor candidates than good ones. It's easier for an interviewer to pull out a set of pre-written questions than look through a github repo and ask pointed questions.
Too much of what we do, from education (standardized tests) to banning of users in places like YouTube, is centered on efficiency or administration. Aim for the center of the bell curve, ignore the collateral damage and reach those target metrics, as the mantra goes.
It'll get much worse before it gets better, if it ever does.
That's a rather negative view, considering that much of software by and large is about replicating paper based processes with far less human effort involved.
It's fair to describe software engineers as a profession of the professionally lazy. "This takes too long to do, therefore I code."
I think it's better to reinterpret the problem based on what Leetcode does well, and try to invent something that does it better.
The old world of make some giant Github project a company might appreciate, or might ignore entirely, holds little attraction to me at this point.
Companies use Leetcode because it tests for the 2 things that are required to become a successful developer, above average critical thinking skills and willingness to spend hundreds of hours improving. Companies figure if you have those two things they can make you into a decent developer, figuring out if someone is already a good developer is much harder.
Or does it test for someone who in the hope of passing these tests will spend hundreds of hours dedicated to pointless exercises that produce no real value?
If by harder, you mean sitting down and having a real conversation, then yes, I suppose it's harder.
Edit: Value is a poor word here, now that I think about it. Let's say mostly pointless activities that generally don't apply to work they'll be doing with that skill. It's like playing baseball to practice for tennis.
When I worked at eBay, our policy was that we had to use RedHat and that any open source we used had to be provided by RedHat or we had to get a support contract from someone else who would be willing to 1)Support the software and 2)Accept legal liability if it failed.
#2 was the big sticking point. RedHat made a lot of money accepting that legal responsibility, but very few others were willing to do so. It made using software difficult (and a lot of us just ignored the policy).
But if you follow this advice, you may end up accepting legal responsibility for the software, and that may be bad.
I maintain a tiny, tiny, unimportant open source package. It gets about 10K downloads a month. Assuming that each of those downloaders saved one minute of their time on average, and their time is worth $15/hr, I'm providing a service worth $2500/month.
I'm starting to think, how could my next project provide the same value, and get paid for it?
The alternative to what we have now is not going to be a healthy OSS community. The alternative is going to be big companies insourcing more of their libraries.
The only reason why OSS has seen the up-pick it has is because major companies profit from it. Microsoft didn’t embrace open source because it had a change or morals, it embraced open source because it started making so much more money from enterprise orgs switching to Azure compared to selling us licenses for on-prem alternatives. Facebook and Google don’t share their massive front end-libraries and extensive tools because they are nice, they do so because it helps them dictate web-development and being able to on-board new hires who are already familiar with their tech.
If anything, I think it’s more likely that we are going to see a big player pick up a NPM alternative and make sharing packages much harder. I think the fact that no one has done this, should tell you all about how little the enterprise industry worries about the status que.
I don’t think it’s necessarily healthy, and I sympathise with OSS maintainers who don’t get paid for their work, but I don’t think it’s a massive issue either. The OSS world is still better than it ever was, and your tech stack isn’t actually in danger if you review that code you use.
Reviewing code is the elephant in the room. Filosotile -perhaps out of ignorance or disconnect- fails to mention that the vast majority of open source projects (log4j being a great recent example) are absolute shit. Nobody should be building anything on top, nevermind giving the maintainers more money.
In-house development, software BOMs, rising of standards and multiple rounds of code review are the processes that the industry is shifting towards and for good reason.
Every engineering-driven fintech company I know of (having myself worked there or having friends who work there) is doubling down on every single one of the processes I mentioned.
Yeah, and that is about 0.1% of total amount of software assembled and deployed in the world. It is like saying all my friends drink Evian water so that's the way we handle clean drinking water shortage in the world.
I would be fascinated to see your evidence that in-house code is any better on average than open-source code.
I haven't done a lot of consulting lately, so I haven't seen much in-house code in the last few years. But my experience is that the average in-house codebase is worse. And that makes sense from the incentives. Open-source projects that want more than one contributor need to be approachable enough that people join in. Whereas with most in-house code, people commit to working on it without ever seeing it. Switching to work on another open-source project is easy; switching to another job is hard. Open-source authors get to decide when to release; in-house code is generally driven by execs. And so on.
... keeps resulting in shit code, too! There's no evidence standards of quality are rising. In my own extremely limited view of in-house software -- i.e. my own professional experience -- code quality is crap, standard quality practices are very low and actually worse than in FOSS projects (I've seen someone mention more than once that "this crap PR simply wouldn't fly if this were an open source project, it's so bad nobody would want to review it!"), absolutely dumb bugs keep hitting production, and people think of automated testing as "that thing we don't want to do".
In-house code is just code you don't know is garbage because you cannot look at the code.
I didn’t say in-house code was good, but it does keep you from being exploited by things like what recently happened with NPM.
Companies genuinely don’t care about the software they use, as long as it works and isn’t hacked. This is especially true in non-tech enterprise. At my former place they still had hundreds of ASP Webforms with custom in-house ASP libraries that were utter shit, but they worked.
What I’m postulating is that this is the alternative to the current status que.
I’d personally love for NPM to review their packages, or for a big player like Microsoft to step in and make a more limited platform with reviews, but I just don’t think anyone is going to be willing to pay for it.
I think I’m too senior to believe in non-shit software.
I work in non tech enterprise. You’d think that things like the ransomware scandals, GDPR, the increased risk-awareness would have improved the business processes or management awareness or all the things are “corporate digital maturity” but the pressure to get things done fast with minimal resources has frankly never been higher.
In that environment we’re always going to have shit-software. If anything I agree with you, which is why I said that I thought that the current status quo was the best ever.
The welfare queen megacorps have been too comfortable expecting handouts like open source charity work and public bailouts. Open source software has served the elite executive class while leaving working people to depend on anti-freedom proprietary offerings. I am sick of watching it go down like that. The never-ending data leaks, dark patterns, lock-in strategies, and attacks on encryption and freedom of speech, are all exacerbated by this tendency to yield the commons to the ruling class. If open source doesn’t serve working people, I don’t care a lick for it anymore. Cheers to Stallman and all, but this is where his proposals fell short.
Where the GNU project always fell short in my opinion was that it thought there was a difference between free to use and free as in beer.
There was an abundance of people who predicted where the internet would head once big corporations got into it. There is an entire genre of cyberpunk authors who did after all, and I guess Stallman gets credit for trying to stop it, but it always comes down to money.
It’s very easy to fool yourself into thinking differently, but the harsh truth is that everything you do for money is being weighed and evaluated by someone in the management chain whom, at the very least, considers if you’re worth your cost, every three months.
I just don’t see how OSS is supposed to have changed in that regard. Maybe it was more ideological when it was mainly paid for by academia, but someone still paid for it, and considering how much OSS has improved in the wake of corporate capitalism taking over, academia don’t appear to have paid enough.
That’s easy for me to say of course, I have no solutions, but I still think we’re better off now than ever.
463 comments
[ 5.0 ms ] story [ 325 ms ] threadMaybe there is nothing wrong with the "status quo", maybe we don't need yet another attempt to finance small FOSS projects where it's hard to explain how money will actually solve any of these issues.
Maybe people just need to be more considerate of what they depend upon. And in the case that a popular yet well maintained project has a CVE on day, maybe we need to accept that popularity does not make them invulnerable to bugs, all software has bugs.
</ unpopular realists opinion>
The reason is that the whole JNDI string interpolation feature by itself opens a door to a whole world of layered complexity which you can't comprehend. And even if you could comprehend it all Java could add some feature to JNDI which introduces an issue which wasn't there when it was all tested.
Anyone who knows anything about JNDI would've immediately recognized that this was an incredibly bad idea, as JNDI attacks are well known around black-hat circles (LDAP is just one of the things you can do once you have JNDI available).
Yet, here we are, several years later, acting surprised this thing existed and thinking that tests would've helped!? What kind of tests, exactly?!!? I think I am to blame myself, as many other Java developers who actually use log4j, has a good understanding of how it works, knows JNDI and LDAP, yet never connected the dots and noticed what this incredibly stupid feature was making possible.
It's not completely novel, projects such as openssl and sqlite do offer paid consulting, but it's not normalized among companies to pay for doing so. If Filippo can normalize having OSS be treated as paid consulting engagements I think that would be wonderful for the community.
Adding features do not reduce likelihood of bugs, if anything the opposite.
It's very difficult to come up with a paid model that specifically encourages a preventative strategy towards bugs and security flaws. Currently the best we have is getting people who care about those things to build software.
Then, maybe a year later, that feature is no longer the hot new thing and it becomes abandonware inside the application. If you're app isn't cloud based you have no idea if you can rip the feature out or not as you have no idea how many people, if anyone still uses it.
What's needed is for open source libraries to somehow get "rated" by security experts before they get used by businesses. If those businesses using it paid for that, and then paid someone to fix any issues found, then I think we would have a working solution. Just paying for features would just make things worse... have you ever seen companies paying for security features, though?? No, I haven't at least... they pay for business features that will make them money, they hope, security is kind of just implied (and they might lay the blame entirely on the developer if they actually had a business relationship with them - which may be a big nightmare, actually, for OSS developers - and I am one of them myself... you can no longer use a license that just says you're not liable to anything bad that happens).
I have an analytics package which is apparently being evaluated by the military of a large country. Even if secure code, now the maintainers themselves are under attack.
For I am definitely a weaker link than a soldier or agent or gov department. Did not expect such usage when creating this project. If said government had seen how this was developed and tested, they would probably physically destroy the machines it is installed on.
Salaries are lower, but expenses for essential services are simply A LOT less in most of Europe.
>but increased savings from increased salary can make up for that (not to mention 401k).
And huge medical bills can quickly eat up even substantial savings...that doesn't happen as easily when medical services are provided by universal coverage.
Also, state guaranteed pensions aren't lost if some company in a portfolio crashes.
Have cancer, or a premature baby with 90 days in Neonatal Intensive Care, in the USA, and get back to me on your health insurance.
If you're in a good tech company in Europe you generally end up having private healthcare, a private pension with employer's top up and extended ma/paternity leave.
The problem is that taxes in the USA are still fairly high and comparable to the ones in EU - you would expect some services for the amount of money you're paying. That said, having lived in countries with state run services all my life, I don't think the solution is state run services, but cheaper private services. The problem in the USA is that governments and insurance companies inflated the cost of healthcare ridiculously. Similarly the cost of universities in the USA has been inflated following government intervention.
Talking about state run services: Between waiting times, poor support and the lack of competition the quality is pretty bad, despite what the state propaganda will tell you. Having lived in the UK and in Italy I cannot but laugh hearing that NHS or the SSN are "the best healthcare systems in the world". The amount of bad experiences I had is ridiculous (some of which could have damaged my family health, had we not had the money to pursue private treatment). Universities in Italy, which are pretty cheap at 3-4k€ per year, have several deficiencies and, despite having a handful of great professors who do it out of passion (maybe while running a profitable business on the side), it has its fair share of problems. Not to mention the amount of freelancers in Italy who pay pension contributions every month who will never see a penny for their money.
One thought: i disagree with the classification of (senior) software engineer.
i think it’s more comparable to a VP of Engineering in a company with n engineers (n = count of committers/involved), so salary estimate are even higher.
It has worked great for decades, both for the free market side, and for the FOSS community.
As a result, it's also unsustainable to other coders because the OSS ecosystem grows replete with broken and stale code that is no longer maintained and which creates cognitive cost to ignore/prune.
Both might grow in a non-linear fashion, which would be really bad news.
Can you explain a bit more how it worked great for the bulk of maintainers / authors who don't see any return on their work, burn out and have to do something else?
And for communities, and for sponsoring companies, and for some (although not all) authors.
> if you ignore bombs like this logging bug destroying Western civilization.
...yeah, no; a library had a bug. Somehow, Western civilization is still here.
> Can you explain a bit more how it worked great for the bulk of maintainers / authors who don't see any return on their work, burn out and have to do something else?
Can you explain why you think the majority of authors/maintainers burn out?
That was exploited since April
https://github.com/nice0e3/log4j_POC
... this 'bug' is RCE on the logging infrastructure.
> Can you explain why you think the majority of authors/maintainers burn out?
Please try maintaining a popular FOSS project for a few years and explaining to your wife why you neither have any money nor have any time.
And yet, Western civilization is still here.
>> Can you explain why you think the majority of authors/maintainers burn out?
> Please try maintaining a popular FOSS project for a few years
The majority of projects aren't popular, so you're comparing apples to oranges. For many, I suspect most, projects, the user base is tiny and low pressure.
I don't understand this argument. Nobody starts an open source project - and posts it in the open to share freely - expecting to make any money. Are there even any significant amount of projects with a donation or a Patreon page?
Webnovels I read on RoyalRoad all have it and are much more successful that I would ever have thought given that the stories are all coimpletely free and all any one who pays a story author gets is a few chapters ahead of others, but I can't remember any of the numerous OS projects I use one way or another to even try to make any money.
I did see burnout in some projects. I once joined as co-maintainer of a medium sized project and was left as the sole maintainer because the main author just up and left and was unreachable (we only heard of him again over a year later, and he never touched that particular project again).
All the stories I saw had nothing to do with money at all though, just getting fed up with the expectations. In "my" project's case it also was the large amount of complexity and technical debt that made the original owner's attempts at adding and/or refactoring a huge time sink, and he probably would have been better off to start again from scratch (it's what happens after adding more and more features in a complex cross-mobile phone platform library project's code).
None of those "disillusioned open source maintainer" stories I saw ever included any attempt of making money with it. Disappointment of not being able to get money from anyone only ever comes from people starting a commercial project (a new company), if that kind of disappointment exists for freely shared open source software then I must have missed all instances of such a thing happening.
> It has certainly 'worked great' for leeches, if you ignore bombs like this logging bug destroying Western civilization.
All of life and especially commercial life in anything slightly sophisticated or at scale is "muddling through" to some degree. The same as biological life actually.
So overall I agree with the previous statement that it worked quite well. Nobody should be called a "leech" for using projects that were meant to be shared openly and freely, given the license and method of distribution (e.g. freely on Gitlab or Github).
Yes, it would be very good if more people started to contribute to software they depend on, but to call them "leeches" is not only against the spirit of free software, it is counterproductive as it will probably lead people to the idea that proprietary/closed source is better.
No... projects want contribution more than money, the idea of paying the author is that they can then continue to contribute in the long term by proxy for the payers.
But FOSS-systemwide, I give much more than I take. It just needs leechers, who systemwide, give nothing back, to do the same.
If you ask five different people to evaluate your contributions, how much would they agree? How much would these people be interested in contributing as well and/or paying for you to keep doing what you are doing?
The point I am trying to make: people express their preferences differently, and that is a Good Thing (tm). Market dynamics are a Good Thing (tm). Each of these critical RCEs work as shock on the whole ecosystem which makes it a little bit stronger. I'd rather have a dozen of RCEs on popular-but-amateurish maintained projects than a little totalitarian forcing everyone to "stop being a leech".
"Look around and notice how the world actually works"...
In other words open source as it was practiced was sustainable up until the point it got taken advantage of too much by big players not putting things back into the system. At this point it has become unsustainable.
In what way is this not an ask?
I imagine this could be a hard sell to people who just want to build some cool software and maintain it. Setting up an account, okay, that may be possible, but that's not the end of it. Companies pay invoices FOR something. That something means contracts, potentially about substantial sums, that means getting legal support to navigate said contracts & obligations.
But there are some things like Kafka, PostgressSQL, Spring Boot, Tomcat, Apache Math, ZooKeeper, the OpenJDK, and all that which are definitely non-trivial and a huge amount of time and effort, and you couldn't just take an extra month or two and have a dev on your team implement a replacement, unlike log4j and ua-parser.
I think those would be better example to discuss, and my impression has been that those things often have a company behind them offering support or offering them as a service that in some ways pays for some real devs to contribute to them, but maybe I'm mistaken.
Like for example, the author mentions working on the GO team at Google, and Go I would consider one of those big open source projects that truly are foundational and would be non-trivial and huge effort to replace. So that shows that the really big pieces do have companies hired and paid staff behind them.
Did you consider the fact that half of your examples of worthy things are using the unworthy log4j?
This is how the value is measured.
But if you take a much harder task, like building a performant and safe JIT language runtime like the OpenJDK, you'll see that even in the open source model, people can't actually deliver it effectively for free. It often starts out from a company that later open sourced it, or it's backed by academia, and contributions require deep expertise, so sometimes companies had to have their own staff contribute to it on their own payroll.
Log4j is a good example, anyway. It's an old library, very old. And a lot of other software depends on it. So the effort of replacing log4j is not proportional to it's feature list, but rather to the feature list times the number of projects already depending on it. (The replacement exists, btw, called slf4j, usually with logback, written by the same author as log4j.)
Java Logging is a subject in itself (I won't say "interesting subject" although it is interesting, in the same disturbing way the lifecycle of a tapeworm is interesting.) but I would argue that these logging libraries are old and have evolved over time in ways that are hard to anticipate or recreate. (Rewriting things also leads you to the xkcd "standard proliferation problem" - https://xkcd.com/927/)
The real problem is that it takes time, like real calendar time, to understand an implementation fully enough to fix it, and no-one wants to do that, because it's a job as critical as it is thankless.
An engineer with in Micronesia with specialized skillsets.
Try to convince these communities about the need for a well compensated team of people including product managers and designers all making 6-figures and honestly people just don’t believe you. The truth is that cost of living discussion doesn’t even matter, people should be compensated on the value they bring (and in those communities that is very easy to quantify.)
This has wildly slowed down many projects as UI and usability are completely neglected.
Its pretty much only been one year that an engineer in this space can reliably land compensation packages somewhat competitive to a tour in NAAAM
reign of chaos
This is easily solved with a universal basic income. Some of us would gladly forever maintain and contribute to free software if we had our basic needs guaranteed.
I certainly would
Open source has been incredibly sucessful using voluntarism.
We could also throw in political movements; the all-volunteer military, which has existed on and off since the American Revolution; science (the pay doesn't nearly match the efforts and value); non-profits; teaching (same as science); etc., etc. Why do people feel so motivated to sh-t on voluntarism, which has changed the world with great success. Almost every major advance in history has been accomplished by volunteers (depending on how you define it). Declaration of Independence, Newton, Van Gogh, World Wide Web, etc. etc. etc. ...
Moreover, there needs to be a fundamental re-thinking of the security model of languages and runtimes, i.e. even if I can eval() user input or load a plugin from the network, it should not be game over. There should be finer-grained access control in programs, both at the type-level and with how they interact with the OS. The global view of "your program can do anything unless said otherwise" needs to change.
0. https://github.com/amoffat/sh
It's a grand idea, and I hope it works. The path to not working is too achingly obvious though. Budgets are always tight (even if you're Apple and you have to artificially make money feel tight). What corp officer with budgetary discretion is going to greenlight a 5-6 figure payment to someone who's not doing work directly for the company? I think the key here is that that person is going to have to a) be principled, and b) smart about selling it, by emphasizing the fact that the changes were beneficial to our company, and leave out the fact that those changes were beneficial to every company. It wouldn't hurt if BigCorp got a measurable recruitment bump from it, too.
* In really big companies it's possible for admins to buy routine stuff below a threshold just to save on paperwork. So there's a scam in which someone sends out a bunch of $100 invoices for "printer paper" -- account payable assumes the department code was left off by the vendor but it seems legit so they pay it. Seems like a hard way to collect money.
In terms HN would understand, it's a stateful firewall for invoices that prevents paying orders that didn't originate from your company.
We all opted for centralized package repos though, so now only they know. And they’re not telling us.
Just another “free” opportunity lost to centralization, I guess.
I'm sympathetic to the view, but there really are some things that are better centralizing. Reducing code into binaries is something that a "fair" 3rd party is going to be better at than the 1st party. Why? The 3rd party central source is (presumably) mechanically cloning and building, whereas the 1st party is doing much much more. Effectively the 3rd party offers a better guarantee to the end user that this binary corresponds to that particular source.
Also, the Way to measure who's using your code is to put runtime telemetry in there. Distasteful, but so common now with every kind of software, it's crazy. Yes, even OSS CLI programs phone home now (heck, ohmyzsh phones home every time I open a terminal!). For a generic server library, you'd add a check to make sure it's the most recent version and print that out to stdout on startup.
See, it's not user hostile it's to keep them informed of updates! /s
are you talking about the update check that by default runs once every 14 days[1], or is there something else?
[1]: https://github.com/ohmyzsh/ohmyzsh#getting-updates
obviously these tools amplify their user's productivity. corps are organized to be economically productive, hence they benefit enormously from free power tools.
hobbists benefit too, but since their productivity is low they benefit relatively little in terms of economic surplus.
(sure, I might do my taxes using free software, but my taxes are also trivial, two lines and that's it. sure, I might whip up a blog/website using free software to share stuff with people, but again it's economic productivity is already zero, it doesn't matter if now it's a technologically amazing site.
and sure, I work as a freelancer using these free tools, but again my productivity is very limited compared to, relative to the systems I work on for corps.)
the solution is probably a mix of a bit of wealth tax and consumption taxes.
Do you know which organizations these are?
No idea whether it would help but clearly staying exactly
> I've maintained for over 10 years. I don't recall ever receiving a donation. I am still maintaining it, but I just don't have time to add the improvements that it needs to keep up with the ecosystem (asyncio, for example). If organizations who use it got together and chipped in some non-negligible amount, I would be much more serious about keeping up with it, but $0, or $5-20/month, is just not realistic incentive to compete with other priorities in my life.
may be a good idea.
Even if that would not help this project then making people aware about problem in general would help.
I would be pretty skeptical of projects that try to keep up with the ecosystem, if they are adding things just to keep up (rather than because they need them). The fundamental advantage of Free Software is that the people writing it are doing the ultimate dogfooding. A Free Software project that is adding functionality they don't need is no better than a company in terms of knowing what "customers" want or how to evaluate whether they did it right.
(Usual disclaimer, n=1, etc)
[0] https://github.com/jlevers/selling-partner-api
Building a business on a stack of other people’s hobbies isn’t sustainable. I mean, just tell that to anybody outside of tech and watch their reaction.
I can't imagine it would be as clear cut for a "library", but it can be done...
There’s tipping and sponsorship infra, but is there a service to plug an OS project into corporate-friendly licensing and support invoicing?
Perhaps this could work for any company size, but I guess it depends on what is your core business.
I find it difficult to blame developers individually. Individuals working at these companies aren't going to see it as their role to send some of their own after-tax income to maintainers via GitHub Sponsors unless they are unusually charitable. But I could definitely see my company sending thousands out the door (pre-tax) every year to the maintainers of the libraries we depend on.
For example, imagine your team is 15 people. Have the company budget for and send an additional one developer's worth of salary out annually to the open source maintainers, divided among the libraries in a proportion agreed to by the development team. Yes, it's an additional cost line item, but it's the right thing to do and it won't break the bank.
Open source has reduced costs dramatically for all of us who use it in our dependencies list. A nominal cost line item on our annual budgets is more than fair.
But ultimately the problem is the same: engineers, i.e. employees, don't control the money. They don't have agency to direct the money toward functions other than enriching the people who have the money.
They may have more agency relatively speaking than free software developers, but on an absolute scale, you can measure this kind of agency in dollars, and it's a pittance.
Maybe they could donate some of their own salaries. Maybe they could get employer matching. Still doesn't seem realistic, but it's closer.
Maintaining business relationships with $megacorp is one of the primary reasons OSS maintainers (maybe just speaking for myself, but I don't think so) do their OSS work, and don't develop proprietary software and market and sell it around a business venture.
If you start writing up contracts or accepting direct payments with any strings attached at all, the dynamic is completely changed.
Should OSS devs optimize for my (probably quite rare) use case? Probably not, but the feeling when making a patch for something that I like is still different when the maintainer runs it as a business compared to when they run it as a hobby.
(This is what the whole discussion seems to be about btw. Some people like to program in their free time as a hobby and other people would REALLY like guarantees about the software that cannot be made without losing the essential hobby-ness of it)
This can lead to corporate capture. We see this in some projects already.
Could you share some examples that weren't corporate projects to begin with?
Now the best way to get a job is leet code, leet code, and more leet code. Rather than spending <5 hours a week working with real code and producing real value on open source projects - most career minded engineers will simply focus on leetcode.
Not many people patch esoteric software that's been around for 10+ years because it's particularly fun or because there is specific business value in it.
Maybe more broadly: The only way to prove that you're good at X, is to do X well. An artist is only as good as his portfolio. The same is true for all creative jobs.
I'm thinking that these proxies (see all attempts at standardised testing) are a disease of our time.
I have seen first hand developer that are just okay or below average successfully deliver on open source, because you have infinite time, no constraints, no stress and get to choose exactly what you do or contribute. But in a work environment they struggle, given ambiguous problems they struggle, given time constraints they struggle, given changing needs and demands they struggle, working within a team they struggle, given something outside their area of knowledge they struggle, etc.
Moreover, with industry moving towards agile, having project and developing in a company are massively different kind of work.
Mediocre candidates getting leetcoded by mediocre companies may be a highly visible pattern but on industry scale I am not convinced it is the dominant mode.
Not only does it feel like I'm stolen value, open source work tends to be the most interesting, and as more and more is done and offered for free, my work becomes less and less interesting, and the job becomes more about connecting and configuring all these open source systems together.
Needing to contribute free work in open source before getting a job therefore sounds like the biggest of scams to me.
But overall I'm not in disagreement with you, you could say open source is done as part of the greater good and advancement of technology and computer science, and not for personal capital gain. That also means that it isn't meant to be a sustainable career path, or job that you can do full time though.
We benefit far more than we can ever repay.
As a user I agree, things would probably be more expensive if nothing was open source. But as a developer, I disagree, my employer would simply need to pay for the stuff I use, or they'd pay me or another developer to build them one. And this is precisely what the article argues, that companies should pay for it. If there wasn't any open source logging library, the maintainer could either work for a company that offers a paid one, start his own company, or work for a company that pays him to maintain one for them.
Good point, but you would have a much smaller industry and platform without FOSS, and there is no way you could build all the libraries, tools, etc., yourself. Even FAANG depends on FOSS. If everything had to be paid for and professionally developed, licensed, etc., there would be much less around, and nobody could fork and innovate - there's a reason people develop and use FOSS.
Lowering the barrier to entry by being able to leverage a lot of free stuff probably helps make the industry bigger in having more startups, but I also can't say for sure there wouldn't be more jobs or higher paid jobs otherwise.
In the end, I'm not trying to push to end FOSS, but I'm trying to bring to front the contradiction I'm seeing of people wanting FOSS but also wanting FOSS developers paid a full wage. It seems fundamentally at odds, if you want people working on logging libraries to be paid full wages, stop making FOSS logging libraries.
Yes, valid and important point. We could look at how other industries develop. Software + Internet is especially condusive to 'free' products. Other industries must at least share knowledge, which arguably is embedded in FOSS software.
> I'm seeing of people wanting FOSS but also wanting FOSS developers paid a full wage. It seems fundamentally at odds, if you want people working on logging libraries to be paid full wages, stop making FOSS logging libraries.
An inarguable logic ...
On the other hand, from the viewpoint of all of humanity, it is great that there exists a huge amount of software that is useable by everyone for free.
Yes, having open source competition means you'll have to either build a superior product that customers are willing to pay for, or find another niche. That's a good thing.
Good has many dimensions. I'm saying that as a developer, FOSS means people don't need to pay you to build those things, only to use them, and that's why FOSS developers themselves don't get properly compensated, because they chose to build it for free.
You could say FOSS is a good thing if you talked about computing progress, or barrier of entry for a startup wanting to build an app, or as a great source of example to learn from, etc.
As for your comparison, I don't think it holds, because very rarely are FOSS contributors hobbyists, most of them are professionals. So it is much more akin to a professional window engineer giving away free schematics for unbreakable windows, which means that companies manufacturing unbreakable windows no longer need to pay a professional window engineer to make schematics for them.
Of course, the smart glazier would figure out that giving away the schematics for a window-breaking device is in their interest.
Commoditize your complements, as the saying goes.
Too much of what we do, from education (standardized tests) to banning of users in places like YouTube, is centered on efficiency or administration. Aim for the center of the bell curve, ignore the collateral damage and reach those target metrics, as the mantra goes.
It'll get much worse before it gets better, if it ever does.
It's fair to describe software engineers as a profession of the professionally lazy. "This takes too long to do, therefore I code."
I think it's better to reinterpret the problem based on what Leetcode does well, and try to invent something that does it better.
The old world of make some giant Github project a company might appreciate, or might ignore entirely, holds little attraction to me at this point.
If by harder, you mean sitting down and having a real conversation, then yes, I suppose it's harder.
Edit: Value is a poor word here, now that I think about it. Let's say mostly pointless activities that generally don't apply to work they'll be doing with that skill. It's like playing baseball to practice for tennis.
#2 was the big sticking point. RedHat made a lot of money accepting that legal responsibility, but very few others were willing to do so. It made using software difficult (and a lot of us just ignored the policy).
But if you follow this advice, you may end up accepting legal responsibility for the software, and that may be bad.
I thought that was a joke. What did the warranty disclaimers say on your system?
https://xkcd.com/2347/
I'm starting to think, how could my next project provide the same value, and get paid for it?
The only reason why OSS has seen the up-pick it has is because major companies profit from it. Microsoft didn’t embrace open source because it had a change or morals, it embraced open source because it started making so much more money from enterprise orgs switching to Azure compared to selling us licenses for on-prem alternatives. Facebook and Google don’t share their massive front end-libraries and extensive tools because they are nice, they do so because it helps them dictate web-development and being able to on-board new hires who are already familiar with their tech.
If anything, I think it’s more likely that we are going to see a big player pick up a NPM alternative and make sharing packages much harder. I think the fact that no one has done this, should tell you all about how little the enterprise industry worries about the status que.
I don’t think it’s necessarily healthy, and I sympathise with OSS maintainers who don’t get paid for their work, but I don’t think it’s a massive issue either. The OSS world is still better than it ever was, and your tech stack isn’t actually in danger if you review that code you use.
In-house development, software BOMs, rising of standards and multiple rounds of code review are the processes that the industry is shifting towards and for good reason.
I haven't done a lot of consulting lately, so I haven't seen much in-house code in the last few years. But my experience is that the average in-house codebase is worse. And that makes sense from the incentives. Open-source projects that want more than one contributor need to be approachable enough that people join in. Whereas with most in-house code, people commit to working on it without ever seeing it. Switching to work on another open-source project is easy; switching to another job is hard. Open-source authors get to decide when to release; in-house code is generally driven by execs. And so on.
In fact one can safely say that top companies that attract top talent also have methodologies in place that lead to better than average code quality.
Most in-house code is crap.
"Works good enough" is how our world generally operates unless under strict regulatory guidelines.
... keeps resulting in shit code, too! There's no evidence standards of quality are rising. In my own extremely limited view of in-house software -- i.e. my own professional experience -- code quality is crap, standard quality practices are very low and actually worse than in FOSS projects (I've seen someone mention more than once that "this crap PR simply wouldn't fly if this were an open source project, it's so bad nobody would want to review it!"), absolutely dumb bugs keep hitting production, and people think of automated testing as "that thing we don't want to do".
In-house code is just code you don't know is garbage because you cannot look at the code.
Companies genuinely don’t care about the software they use, as long as it works and isn’t hacked. This is especially true in non-tech enterprise.
At my former place they still had hundreds of ASP Webforms with custom in-house ASP libraries that were utter shit, but they worked.
Companies genuinely don’t care about the software they use, as long as it works and isn’t hacked. This is especially true in non-tech enterprise. At my former place they still had hundreds of ASP Webforms with custom in-house ASP libraries that were utter shit, but they worked.
What I’m postulating is that this is the alternative to the current status que.
I’d personally love for NPM to review their packages, or for a big player like Microsoft to step in and make a more limited platform with reviews, but I just don’t think anyone is going to be willing to pay for it.
But the same is true of open source. I thought you wanted non-shit software.
In-house software is easily exploitable and full of security bugs as well.
I work in non tech enterprise. You’d think that things like the ransomware scandals, GDPR, the increased risk-awareness would have improved the business processes or management awareness or all the things are “corporate digital maturity” but the pressure to get things done fast with minimal resources has frankly never been higher.
In that environment we’re always going to have shit-software. If anything I agree with you, which is why I said that I thought that the current status quo was the best ever.
Where the GNU project always fell short in my opinion was that it thought there was a difference between free to use and free as in beer.
There was an abundance of people who predicted where the internet would head once big corporations got into it. There is an entire genre of cyberpunk authors who did after all, and I guess Stallman gets credit for trying to stop it, but it always comes down to money.
It’s very easy to fool yourself into thinking differently, but the harsh truth is that everything you do for money is being weighed and evaluated by someone in the management chain whom, at the very least, considers if you’re worth your cost, every three months.
I just don’t see how OSS is supposed to have changed in that regard. Maybe it was more ideological when it was mainly paid for by academia, but someone still paid for it, and considering how much OSS has improved in the wake of corporate capitalism taking over, academia don’t appear to have paid enough.
That’s easy for me to say of course, I have no solutions, but I still think we’re better off now than ever.
Tell that to everyone who depended on Log4j for the past 8 years!
it's a good thing even if MS benefits more than others. it's not a zero sum game.
the problem is on the other end, where the produced economic surplus is distributed to a very few.