our model of society is not compatible with open source
there needs to be a massive shift and appreciate more the work of volunteers, contributors and benevolent
until then, these problems will amplify
and i'm not talking about github sponsors since it's opt in, and it's more of a popularity check than anything else
i'm talking about that dude who will randomly appear to send a PR that fixes something important, the dude who decide overnight to open source his work but is agoraphobic, that other dude who help write documentation, that other dude who help triage issues, countless hidden people who never are rewarded
> If it's not compatible, then how come it thrives so well?
Careful — some societies a while back "thrived" by relying on slavery. OSS is not slavery, but drawing conclusions just from apparent thriving is dangerous. (Other analogies: recent bubble collapses from the housing market & dotcom before that — those seemed to "thrive" too, before the bubble collapsed.)
> […] let's ask why it works to begin with, […]
One thing I'd throw on that list is people trying to build a name and reputation hoping to get hired in the future. This includes bright youths fresh out of high school, but also PhD students whose thesis delivery is turning into a dreading life change. They're running on borrowed time, and if it doesn't work out it's both them and their projects that are screwed.
It's got a weird bit of nuance to it. I think Open Source does well because it's economically infeasible for it to fail. The cost of hosting source code is next to nothing, and the idea of writing a shared library/tool gives it long-term appeal. The problem boils down to human nature, and the greed/ambition/entitlement we feel isn't balanced with a proper respect for our surroundings. If you train people to be entrepreneurs, they'll nickle-and-dime every free software product they find.
There's not really a problem with FOSS software, as I see it. It's okay to disagree with it's principles (or even for the purposes of a single project), but the concepts of public licensing are completely moral and just. If we frame this as a money problem, corporate FOSS benefactors will build us a money pit. That's not what Free Software (capital F) needs.
> our model of society is not compatible with open source
I’d say evidence is to the contrary. This message wouldn’t be possible without open source working on multiple devices at every layer of the network.
I think the problem of funding open source well, that is a different problem and has a lot of the same problems getting anything funded does. Not every piece of code can have an enterprise built around it, and that means there will be no one to even look at bugs.
Finally, let’s talk about volunteering. Most often volunteering is doing something that doesn’t get cash budgeted towards it. You go in doing something necessary but unbudgeted because you want to… and with no reward other than knowing you made something work. Maybe you even give up something you could be doing with time instead of volunteering. Manning the directions kiosk at the hospital, picking up garbage in a neighborhood, nailing the roof onto a house the owner can’t afford to buy, putting letters in envelopes, and answering the phone at a fundraiser are all examples of this. You know what you are getting in to and you know what you are getting paid. No injustice in it at all. And for a lot of people it’s the most important thing they do.
One of the unspoken benefits of paying OSS projects is that you then attract the money motivated rather than the ideologically or politically movement. That has value in and of itself.
I have a project that I have thought about open sourcing. When I hear horror stories about demanding 'customers' who don't pay you anything but somehow expect you to drop everything and address their immediate concern (feature, bug, documentation, etc.), that gives me pause.
I wonder how many other projects have also been kept out of the OSS realm for the same reasons.
If you choose a license like AGPL then this will exclude most corps who will not pay for open source from using it, which turns out to have a large overlap with the corps that expect you to drop everything and address their immediate concern. It keeps the project within OSS more, or those who are willing to invest in OSS (because if they do anything more than just use the library / application then they now have a burden to publish changes and be visible so they're forced to invest something from their side).
Recently this has been my thought... that my future projects should be AGPL from day one.
To the existing ones, especially the successful one... if it does get too much for me, I shall relicense.
> Recently this has been my thought... that my future projects should be AGPL from day one.
If that means that companies can't use it, because that would mean, if they use it they would be required to open-source their managed SaaS solution ... that's a feature?
Where I think it's a feature is that instead of them taking from open source and expecting to be able to do that without having to do anything from their side (except demand fixes / updates / features)... AGPL forces them to invest some time and money into sharing any changes they've made and contributing back.
It prevents corps running their own version without sharing those changes back, and it forces corps to think carefully about whether they are willing to invest (their time and effort) in the OSS projects that they consume.
I doubt it would mean that they have to OSS their SaaS offerings. Most likely things are all implemented as little services and the boundary of what they'd have to OSS at most is one of those. More it forces them to be a better and more mindful consumer of OSS.
IANAL, but the AGPL scares people (like lawyers) simply because it’s untested legal waters. The GPL at least is clear about what counts as distribution, but the AGPL, depending on who you ask, may or may not be. The GPL also has case law in a few countries; the AGPL doesn’t.
Some developers at $BIGCORP may think they’d be fine using an AGPL library/utility in one spot, but legal gets nervous, so they recommend management shut it down to avoid lawsuits.
BTW, the AGPL network clause triggers on modification, not on distribution (which the AGPL has the same provisions for as the GPL) or public performance or something else.
AGPL doesn't force companies to share back upstream, only that their users can get the source code. Most of those users probably are non-technical folks who don't understand software development or even if they are power users won't bother to download the source, let alone contribute back upstream. The company can choose who their users are too, so they don't have to accept the OSS devs who want to get code back as users.
"If you choose a license like AGPL then this will exclude most corps", period. It is nicknamed Anxiety GPL for a reason... the discussion of what other parts of your system are a 'derivative work', and would require licensing under AGPL, hasn't been settled and depends on individual lawyers' or judges' interpretation.
The definition of what counts as a "derivative work" has nothing whatsoever to do with the AGPL: it's defined by copyright law. (Although you're right that it's almost entirely defined by case law, rather than being explicitly defined in statutes or regulations.)
If something is a derivative work for the purposes of the AGPL, then it's also a derivative work for the purposes of the GPL, or any other copyright license.
Its not exactly hard to comply with the AGPL, just publish the source as part of the deployment process. I don't understand why corps refuse to use AGPL.
> horror stories about demanding 'customers' who don't pay you anything but somehow expect you to drop everything
But isn’t that just a matter of setting your own boundaries? Someone demands somethign you don’t want to deliver you say “no” and that is it. If they are unpleasant about it you block or filter them.
You don’t own them anything. Not legally, and not morally. Just say no.
Or if you feel like it today say yes, and when the circumstances change say no. No biggie. You didn’t promise anyone anything. Any expectation on their part is a figment of their imagination.
Just don’t wrap yourself into pretzels over other people being unreasonable.
I think that is how it should work but it seems if one day you decide to stop supporting your software, or stop distributing it, then you get a "left-pad" or "log4j" situation and the whole world decides you owe them supported available software.
I don't think any of those things are comparable to requirements to support.
Left-Pad: dev deleted their software name in a package manger. Nobody demanded any maintenance, however intentionally screwing other people over is entirely different. Dev could have just never touched left-pad again and everyone would have been fine with it.
log4j: That was a maintained package, so i don't really see the comparison at all.
So yeah, no requirement to maintain your software. Taking a positive action to screw other people over is going to get those people mad at you. You're free to do nothing, you're not free to intentionally cause problems without hurting your reputation.
I beg to differ and say that requesting better documentation is fair, and it goes without saying that maintainers don't need to fulfill these requests, as I don't think that these requests are driven by an inexplicable sense of entitlement or unfairness to OSS maintainers, but instead a desire for more knowledge about the projects and since no one knows the codebase better than the creators themselves, it becomes obvious that you turn to them for answers to your questions or technical problems that you might face.
I don't think that most requests by OSS users are unreasonable or unfair. Anyone who puts out code that is not perfect (i.e. all code) should expect there to be bug fix requests, support questions, documentation requests, and suggestions for new or better features.
But even if you say NO to the vast majority of requests, it generally requires some real time and effort to address each one. If the originator does not feel like 'maintaining' a project and their is no financial incentive for doing so; then I think that can be a big barrier for many projects and can prevent them from being open sourced to begin with.
On the other hand I know more incidents caused by overfunded corporate OSS developers who have taken over projects and justify their existence by manically rewriting the code base for no reason.
Many of these incidents are covered up. Contradicting the corporate politicians is dangerous, because often they have installed dozens of other developers who always agree with them and are ready to libel dissenters.
OSS funding is a hard problem. OSS was best when it wasn't funded at all.
Your post is controversial, but hard agree on that last sentence. The environment changed completely in the past decade after the lines were blurred, and not in a good way.
I flagged your post because at this point, talking about systemd is just flamebait.
You have an opinion about what an init system "should" be. Systemd developers have another. If you don't want systemd, don't use it. What's that, you can't "not" use it because your distribution decided to use it? There's a good reason they did. If you think you know better, use one that doesn't, or do your own distro…
Systemd is also a poor example of an "overfunded" project. Some of its developers are paid, but it's not funded "as a project", it's just maintained by a company.
Want an overfunded open source project? Look at React. And yet, look at how incredibly popular and useful it is. The "overfunding" goes into conferences and developer advocacy.
Bad thesis, bad examples, easy to find counter examples. Money in open source can be problematic. More often than not, it's the lack thereof that is.
I'm not sure what rose tinted glasses you're wearing but this is certainly a take.
systemd sure does a lot, but it does it drastically better than how it was done historically. It's been over a decade, this vitriol feels misdirected at this point. I cannot imagine going back to the cesspool of sysv rc-style init. What a headache.
> This default is almost always the last way you want an init system to do. It should never be the default.
What do you propose is a better default? If there is one, then distro maintainers are free to select it. I think the default chosen is very reasonable.
> And now it thinks it should add another OOM killer, before the kernel! Talk about feature bloat!
There absolutely should be another OOM killer. This strikes me as pure ignorance of dealing with OOM situations with any sort of intelligence.
The problem you highlight lands squarely with the Ubuntu maintainers not configuring their desktop environment properly. They should be configuring the user session slice with looser memory pressure constraints, but generally handling OOM further down the stack is a very, very good thing. A proper desktop environment might take advantage of these controls to suspend resource-hungry applications not in the foreground. This also opens up the door to things like asking browsers to dump cache when they create memory pressure, and generally playing nicer with other applications.
I'm not sure what rose tinted glasses you're wearing but this is certainly a take.
Experience, maintaining 1000s of concurrent servers, VMs, for dozens of companies, over 30 years, had shown me how systemd has been a negative, not a positive.
Part of the issue, as I highlighted, is feature scope. In fact, I said nothing bad about core systemd, as an init system.
As I said prior, as an init system, it would have been fine without all the added bloat. But here we have it handling everything under the sun, but again.. poorly.
Which leads to another issue, change. An init system is about stability, and stability is absolutely more difficult with change.
Systemd should shed everything not directly init related, and spend all efforts to stabilize, and keep pace with mainline, and kernel changes. That, and nothing else.
In terms of OOM, there is little point of discussion here, you're too far out in left field, too far from the admin world, to even hear me.
> In terms of OOM, there is little point of discussion here, you're too far out in left field, too far from the admin world, to even hear me.
I'm not sure why you feel the need to attack my experience, but I maintained an internal Linux distribution for a Fortune 500 through the transition to systemd, managed fleets of 10-100k concurrent hosts, written hundreds of systemd units...
You're simply fighting against the grain. As a systems administrator, systemd helps you get stuff done. It's very powerful, and almost every feature can be simply ignored if it's not for you, which is great. The problem is that so much is intrinsically coupled to init. Want to start per-user daemons at user log in? Manage logging uniformly without the pitfalls of traditional syslog? Define reliable service state targets across network state changes? Isolate subsystems? Zero-downtime deploys without writing complex application daemonization logic? Portable services? Snapshots? Peripherals? Not to mention all the incredible work to make multistage bootloaders (and single stage!) completely integrated. Straightforward to debug, patch, build yourself.
It's definitely the worst, except for every alternative. I'm sorry that you find it so miserable. You linked to Ubuntu, so if that's the bulk of your experience, I encourage you to try a better managed distro. Debian, Arch, NixOS, or roll your own.
> When you think killing all of apache2 is a good idea, because one thread OOMs, out of 1000 apache2 threads, of course I question your experience.
I've never mentioned apache2 so I don't know why you think I care about it at all -- I don't. I'm not sure what this has to do with my experience.
Your gripe appears to be squarely with the maintainer responsible for packaging apache2 for your distribution, or distribution maintainers who are responsible for configuring systemd defaults. If you blame systemd for setting a default that maintainers ignore the consequences of, then I'm not sure what to tell you other than that you're barking up the wrong tree.
> OSS funding is a hard problem. OSS was best when it wasn't funded at all.
“Best” is subjective yet I don’t disagree. But what you don’t mention, which I think is important to mention here, is the proliferation of OSS that other vital, closed source software (often monetized) depends upon. OSS has always powered vital software, I’m just making the point that it’s increasingly, alarmingly common.
“Alarming” because the OSS developers often feel they should be compensated if their work is monetized and/or powers other vital software. There is a license for this, but it’s difficulty and complicated to enforce. And it’s not surprising for someone to license their work as “do whatever you want with it” at first, only to change their mind later when they see it used in FAANG products. But then it’s too late, and bitterness and anger creep in.
Take the anger and bitterness of a generation+ of OSS developers and you have our current predicament :(
Unfortunately things have changed in a way that makes this route not viable. Forking a popular project maintained by a corporation is guaranteed failure, as people will look at github stars, number of existing users, and corporate backing itself as indicators of 'quality', while you have none.
I’m not sure that that’s worse than before. Before GitHub, your fork would probably be just as hard or if not harder to discover. The same issues would exist with credibility, too.
These always ignore the possibility that a large % of OSS development happens during working hours at an existing employer. Very few projects are led by devs who decided to do OSS full time without an existing income source.
Some real numbers on this would be nice to have too. If you've seen any research in this area please share.
> These always ignore the fact that a large chunk (maybe the majority?) of OSS development happens during working hours at an existing employer.
Do you have any sources for this? It doesn’t seem right to make a vague statement (a large chunk) which sounds bad, nor a somewhat less vague conjecture (maybe the majority?) without sources.
In my very limited experience, any developer who is significantly supporting OSS with code contributions is a high contributor for their employer, and if they don’t always do the agreed-upon number of hours/week for their employer, I doubt it’s far off. So I disagree with you anecdotally, which doesn’t matter much, and I question your sources, which matters more.
Fair point, edited to be less vague. These statements are based on my own observations. Would love to see a poll in 'the state of X' style regarding who contributes to OSS or not.
I think what they meant is that a lot of popular open source projects are maintained/created originally by companies. So, Facebook created React. FB devs are, i assume, paid for working on React, even though it doesn't directly benefit FB itself (they aren't writing a new messenger feature, for example)
For every React there are 1000 other open source projects run entirely by volunteers.
I am curious if there is actual data on the number of man-hours that are spent on open source per year, and how many of those are funded by corporations. My guess is that it is less than 1%.
When other people rely on your hobby it can be hard to just walk away. There is pride, dedication and the feeling of providing value in FOSS. But if others make tremendous amounts of money based on your unpaid work, and show entitlement to its benefits and free support or development, it is hard not not feel a tiny bit entitled for compensation.
If other people are making money off of your hard work... stop rewarding them with free work.
But it's nauseatingly entitled to just expect people to pay a person for their hobby. Pick a different hobby if it upsets you? There are other things a person can do with their time.
None of those categories seem to be "caused" by underfunding or unappreciation, except perhaps the faker.js issue? There are more incidents in that category though, for example many Python developers stopped maintaining their projects in protest when pypi.org put additional requirements on people whose projects were particularly popular (those people were forced to enable 2FA).
Some of them could've been caused by underfunding, if a maintainer would have preferred to spend more time and care on their project but had to some other work to make ends meet, and got sloppy with their OSS project.
This is arguably true of anything, and therefore not very interesting IMHO: any project could be better with more funding, any bug could have been avoided with more effort.
Yes but this would be measurable with effort. If something like this happened, investigate, talk to maintainers and assess the situation the project is in. It would be interesting what the ratio of "that's just how we roll" vs. "I'm stressed out and can't keep up with bug reports and PRs and just committed stuff to keep up" is.
> There are more incidents in that category though, for example many Python developers stopped maintaining their projects in protest when pypi.org put additional requirements on people whose projects were particularly popular (those people were forced to enable 2FA).
Yikes. Everyone is absolutely free to ignore security wherever they wish on their personal projects, but that just means I won't let any such code anywhere near a production codebase.
I have been wondering about this, whether this is not simply a shift of the problem? Let’s assume we get into a world where we pay for open source. Who would we pay? The maintainer I guess. What about the contributors? When the maintainer(s) receive financial rewarding for the code, will contributors receive a part of this as well? And how would that be divided?
I've been thinking about this on and off. I try to support OSS (currently via Patreon only) and am currently at about 55€ per month. It is really hard to pick the right projects, because I use a lot of OSS, and it's not like I have infinite money to spend.
So right now I mostly fund smaller projects because it feels they need it more, but at the same time I think I should also consider how important some piece of software is to me, or how much I depend on it, which gets really hard as soon as you don't just include "visible" software, but also libraries. I guess I'd have a really bad time without a jpeg library, for example. But that leads into your point about rewarding contributors. Ideally, every project that receives donations will fairly redistribute a share of it to every contributor and library they depend on, but that seems absolutely impractical to get right, especially for larger projects.
Also, should you take the complexity of a project into account? Not to diminish the work of the folks behind eg libjpeg-turbo, but a jpeg encoder/decoder isn't exactly rocket science, so should they receive less than for example libx264?
So yeah, I think this is a fairly deep topic that you can put a lot of thought into, and even get a bit philosophical about. Interested to hear other people's approach to this.
Lots of open source projects have a foundation that manages the money. The foundation decides how to allocate the funds based on what they think will provide most value to the community, whether that is covering server costs or paying specific individual contributors to write code.
Examples: Python Software Foundation, Haskell Foundation
The node ecosystem takes the micro-package architecture to extreme. Examples are the infamous is-odd and is-even that is just `return !isOdd(i)`. The result of building an app utilizing numerous dependencies and the dependecy tree that is formed is an increased incident surface.
From my vantage point: Lots of people use Node and projects built with it seem notorious for having a lot of dependencies, so incidents such as the ones listed are high profile and easily proliferated.
NPM has an order of magnitude more packages than the other language-specific package registries. It has more packages than every other registry put together (including Maven Central, PyPI, crates.io, etc).
Isn't this the responsibility of the team choosing to use that project (transitively or directly)?
If this was a commercial vendor that went out of business, we wouldn't be discussing it. It would be a failure in the procurement process that didn't detect
(and risk manage) the supplier's insolvency.
The same due diligence should apply to open source projects. The benefit of open source is that it makes code escrow (and follow-on maintenance) a lot easier.
In theory you are right. In the real world the reality is that most of the software out there is built on the shoulders of open source. Due diligence for every thing you pull in (along with planning on what to do if you need to remove/maintain yourself) is prohibitory expensive.
If you rely on something you should try to ensure that it survives and trives. Especially if you are raking in money as a result of using that something.
Paying for maintenance is part of a viable risk management plan.
Due diligence is a measure of the size of the risk. Eventually, the risk will outweigh the cost of checking. Some firms will track the cost vs risk and act based on that, others wait until it explodes.
e.g. The company is using software stack "D", and is launching a new business. They have no money. If they get sued, they close up shop and move on.
They have a successful funding round and get an injection of $100m. This hits the news, and they are immediately hit with a lawsuit alleging copyright infringement through their use of "D" (GPLv3 perhaps?).
Somewhere between launch and funding there was a point where the cost of diligence (detecting the license problem) would have dropped below the risk adjusted settlement cost (remediation + lawyers fees + lost sales), hopefully allowing the lawsuit to be avoided.
Then again, it might never have crossed below. Knowing that line is an acceptance of the risk. That's also perfectly valid.
This is a list of "destructive" incidents, rather than the usual "the project died and dropped off the web as a result" that you're thinking of (based on the vendor going out of business reference).
A more apt comparison would be if a vendor didn't want to support an obsolete product anymore and so they remotely rig it to intentionally take down their client's business portal when they try to update instead of just not being available anymore.
(And of course, that's the analogy, many of the items on this list don't hold up to it, as is the case with all analogies)
Risk management reveals risks such as: "the vendor disappeared", "the vendor hacked us", "someone hacked us through the vendor", "the vendor is no longer providing support".
Those are all risks associated with using a vendor, regardless of whether or not you are paying for the software. If your business relies on it, it should manage those risks (insurance, escrow, business processes, paying for support, etc).
The project disappearing/bankruptcy is only the easiest to point to.
I think it is. It's way too normal to build a product and pull source code from hundreds or even thousands of packages that you have no idea about. Even worse, loading these dependencies may execute install scripts that have full access to your dev computer.
Open source is fine and using it is great. I trust many dev teams, but not all. Many languages (JS, Python, Rust, Go) have a super extensible, developer-friendly library of open source components for you to reuse, but this model also encourages relying on these tiny libraries often written by volunteers with no time to prune and maintain their own dependency tree.
Personally, I try to just grab the code I need from small projects (with a link back to the library of origin) rather than add the dependency. This makes license management more difficult (as the source code usually comes with license terms) but packages like left-pad are better off in some kind of helper folder than in the dependency graph.
So half the time when I claim there’s a social contract to be maintained by FOSS creators with regard to fitness to purpose and documentation, I get downvoted to invisibility.
But you guys think it’s okay to have a social contract on enjoying that software? Isn’t that being a little precious?
People don’t get paid for play. So we collectively need to decide if open source is for fun or adulting. You can’t have your cake and eat it too, and insisting on it is going to get us labeled as narcissists. They label everything as narcissism these days, but still.
The middle class suburban neighborhood beautification model works. None of us work as full time landscapers, we all mow our lawns so all our houses look better as a group.
People too antisocial to live in our neighborhood... don't. There would have to be a solution to those people. They probably don't drag us down too much so they might not matter, either WRT neighborhoods OR source code.
I don't mow my lawn because my neighbor sends me micropayments for it or I have some elaborate and weird "HOA"-like contractual obligation to mow my lawn, I just mow it because that's what homeowners do around here and I moved here to fit in with them so obviously I don't mind, its good exercise at worst and almost hobby recreation when I'm planting flowers in the springtime. Likewise I do a pitiful amount of FOSS stuff but more than nothing, because that's what 'my people', and the people I like to hand out with, do.
Don't have a day job doing ONLY corporate work or ONLY FOSS work, do some of each. And don't expect a paycheck for the volunteer work. When I help pack boxes of food for hungry people at church I don't expect much of a paycheck either, but its just something I do with some of my spare time.
The hidden assumption is always that if paid corporates had not relied on free FOSS their paid for code would be higher quality... Naah they'd probably get powned twice as much its just they wouldn't be able to outsource the responsibility for bad code to some other organization. Fundamentally at the end of the day every org in the link "made more money" because of FOSS than they would have lost if they wrote inferior non-FOSS copycats of the FOSS code.
give money to somebody to develop something given away for free? just because it enables businesses / keeps people secure / gives agency to customers / reduces monopoly dependency / increases derivative works? that's Commie talk!
I'll take it if someone makes it free, of course. but I'll be damned if I'm going to pay some insignificant tax to support it!!
This is a very flawed comparison. Nobody uses your lawn to make business.
If someone depends on your lawn mowing for their business, and they require it to be on a high level of quality I would expect no less of a payment for that
> Nah, they sold you land, a commodity. They don't care if you tear the house down to put in a parking lot (though your city probably does).
That is not how developers work. They very much do care if you tear down your house and put in a parking lot, because unless you bought the last lot in the development, they still have more land in the area to sell, and your actions could decrease the value of that land.
Bad comparisons aside, maybe you should try not mowing your lawn for a while and see what actually happens. My guess, you'll learn a lot about that contractual obligation you don't have.
Mowing the lawn as often as most suburban americans do is a pretty awful thing for a breadbasket of environmental reasons (pollution, noise, soil quality, biodiversity, …). And yet.
I can agree that it's foolish to expect payment for labor done without agreement of compensation, but your likening of volunteering at a soup kitchen to Amazon profiting from FOSS contributions doesn't quite land for me.
I suspect we're going to end up with a separate set of OSS licenses based on author and contributor behavior that is fair play for the project.
The other hidden assumption is around building your own or selecting existing tools. We used to call that 'Build or Buy', but there's no demand for proprietary tools in a landscape full of Free ones. There's often not even demand for new Free tools in a landscape chock full of mediocre options. So the choice has been taken away and replaced with a false one. It's reinvent the wheel or use unsupported software and never ever complain about it where anyone can quote you on it. Or do without, which puts you at a competitive disadvantage with the rest of your industry.
> When I help pack boxes of food for hungry people at church I don't expect much of a paycheck either, but its just something I do with some of my spare time
But you might get jaded if VPs of fortune 500 companies were turning up for the free food.
Both Tidelift and Paydevs solve a pretty specific scenario. IMO, they are not useful unless you are writing a library, or similar type of open source project which is usually invisible (yet can still be critical).
Most libraries rarely need the kind of maintenance work that justifies paying people full-time on them. It's often the case that a library is written and then done - future development may be maintenance type work (supporting newer versions of whatever), or increased coverage of the library's use cases. For all this, Tidelift and Paydevs are a good fit.
But most projects that really need continuous chunks of money are going to be end user apps, adapters/sdks (i lied, those are libraries, but they're more visible and often against a moving target), web services, infra services, etc.
For those, I recommend taking more ownership of the finance and setting up sponsorships via Open Collective (https://opencollective.com/)
Source: I run my own open collectives, have corporate sponsorships through there, I've helped several OSS projects monetize, created my own successful open source startup, etc.
If you're an open source maintainer and need advice on this, feel free to email me and AMA (see profile)
I think software distribution is a lighthouse problem. Software distribution has close to zero marginal cost. Any cost imposed on zero marginal cost good will reduce the benefit provided by the good. If a developer wants to make software for better cause, open source is the way to go. But I have no solution to how to support the effort of developer. This is the challenge faced with journalism: free but rubbish articles yet with ads or paywalling everything. Both are not ideal IMO
where is the list of these open source projects that get funded? i dont want to use any of them. of course no sane person would use node in the first place
It's probably helpful context that this repo is a startup who wants to act as a middleman for OSS monetization payments.
- "PayDevs is "Monetization as a Service" for open source libraries. At paydevs.com, we provide closed registries for OSS maintainers to publish their compiled software libraries (or built packages). We restrict access to these registries and collect a contribution from private and corporate users to fill a money pool that is distributed each month based on the number of users a library has."
https://thanks.dev has a good model for this. By default they'll split your monthly contribution equally among your dependencies (and exponentially decaying among transitive dependencies) but you can go in and "boost" or "unboost" specific dependencies or developers by up to a factor of 20 up or down. So if I have 2 dependencies which are equally important to my project but one is vastly higher effort to maintain, I can reflect that in the allocation.
This paydevs "startup" is made by this german dude called Jörg. 2 weeks ago he scraped all emails from npm/github and spammed everyone with his cheap promo for paydevs.
I would not trust whatever he does.
Having maintainers be well paid will not magically make your software bug free. Google pays their devs, their software still has bugs.
I wonder if the real problem it solves is a bunch of corporate types are starting to feel the ethical pressure of leeching off open source, and a nominal fee is the only way they understand the concept of giving back.
No, of course not, but everyone's gotta eat and money can reduce stress and eliminate the risk of someone deleting or sabotaging their code due to reasons related to a lack of money.
I guess the core issue here is if open source is volunteer work, a hobby or art.
If you see it as volunteer work, then yes you should not be paid, but you should also not provide services to wealthy organizations as they don't need it and can pay for their own needs.
If this is a hobby, then why are you putting your code on GitHub? you should just share it with small communities you enjoy hanging out with. And don't provide any services unless you personally know the requester and like them.
If this is more like art (think music), then you want to make it big, you want to share the code far and wide and for it to become popular, you help out developers from big companies (like record labels) hoping they notice you and pay you some day.
I personally think open source can take any of those forms as it's more about how the person works and their aspirations.
> If this is a hobby, then why are you putting your code on GitHub? you should just share it with small communities you enjoy hanging out with. And don't provide any services unless you personally know the requester and like them.
I'm confused. The vast majority of code on github pretty obviously falls into this category.
And quite frankly its pretty condescending. Would you tell someone who enjoys gardening to only do their backyard lest other people see it? For that matter, who are you to tell people who they can and cannot "provide services" to. Do you also object to people acting in local community theater?
> If this is more like art (think music), then you want to make it big, you want to share the code far and wide and for it to become popular, you help out developers from big companies (like record labels) hoping they notice you and pay you some day.
Similarly, how many artists have you met? Some do actually yearn for that sort of thing, but most are not in it to do that.
No, but I would tell them to not do their gardening in the public botanical gardens unless they want the demands and responsibility that goes with that.
As for being condescending, I found your comments only considering the volunteer side of open source equally so, and I am a big fan of answering in a tit for tat manner on the internet.
I have met a bunch of artists, and all of them wish to make a living from their art. I have yet to meet one who only wants it to be a hobby.
---
edit: I for got to respond to this
"I'm confused. The vast majority of code on github pretty obviously falls into this category."
And that is obviously causing a lot of friction between the professionals there to do a job and the hobbyists (a person can wear both hats at different times). Both sides would be better off not being on the same platform. My argument is that the hobbyists should get out of the botanical gardens (to keep going with the gardening analogy) and take their stuff to a community garden or home to their front garden.
> No, but I would tell them to not do their gardening in the public botanical gardens unless they want the demands and responsibility that goes with that.
A weird example given many botanical gardens do rely on volunteers.
> As for being condescending, I found your comments only considering the volunteer side of open source equally so
I personally was previously employed doing open source work. I have no problem with people making money off open source if they want and are able to, just with the idea that it should automatically be the aim.
> I have met a bunch of artists, and all of them wish to make a living from their art
"Making a living" and "being discovered" are very different things. But if you really think every artist wants to do art professionally, you should umm, meet more people.
> And that is obviously causing a lot of friction between the professionals there to do a job and the hobbyists.
How so? I have yet to encounter any friction.
Although i suppose it also depends on what you mean by "professional doing a job". Even professional open source does not look like a real software job. There are no SLA's or garuntees from a professional open source project unless you pay for that seperately, so what even distinguishes professional open source from amateur open source.
> Both sides would be better off not being on the same platform.
Why?
More to the point, although there certainly are some open source projects with big $$$ involved on github, the really famous ones tend to be not hosted on github. E.g. linux is not on github.
> My argument is that the hobbyists should get out of the botanical gardens (to keep going with the gardening analogy) and take their stuff to a community garden or home to their front garden.
The phrase "corporate appropriation of the commons" comes to mind.
I have kinda run out of steam for this discussion. Thinking about it, I have realised that I don’t really care deeply enough about any of the points either way to continue it.
So, have a good day, and sorry for getting you excited.
- FOSS is high quality because really talented people with drive work to build the best they can, across global boundaries
- FOSS is also high quality because it's an almost perfect market - discoverability is high, transfer costs low and so the best becomes dominant
- There is also a lot of bad FOSS code out there.
- Lots of FOSS like lots of proprietary code is just bloated.
- There needs to be some maintenance - but equally some ... it used to be called
systems integration.
- I think the layer of for profit, not for profit and charitable work should focus there - systems integration. Imagine a world where a ISV gets "certified"
on say a Python MatPlotlib, with at least two employees having made accepted pull requests. or something.
Now we have a layer of companies that have profit and cash flow and an interest
in maintaining those foss projects. Not merely using them for free.
You publish the software under a permissive free license and then make a pikachu confused face when people start using it according to the said license.
What the hell did you expect would happen? If you wanted to get paid for software, why did you instead tell everyone that it can be used for free?
If you want to get paid for maintenance, then why are you doing it for free, instead of setting up some kind of a bug bounty, when you only react after payment? Just add a bot that automatically adds payment link to new Github Issues or whatever you use. If you don't want your software to be used for making money without paying you, then add this explicitly to your LICENSE. It's srsly THAT simple.
And don't give me that "evil corporations make money on free software" bullshit. I remember it were the devs themselves who pushed for the use of OSS for their own convenience, back in the day the use of OSS was a hard NO in most enterprise shops, somewhere it's still is.
Throwing a tantrum just cuz people use the software the way that YOU explicitly told them to is plain stupid.
124 comments
[ 3.3 ms ] story [ 203 ms ] threadthere needs to be a massive shift and appreciate more the work of volunteers, contributors and benevolent
until then, these problems will amplify
and i'm not talking about github sponsors since it's opt in, and it's more of a popularity check than anything else
i'm talking about that dude who will randomly appear to send a PR that fixes something important, the dude who decide overnight to open source his work but is agoraphobic, that other dude who help write documentation, that other dude who help triage issues, countless hidden people who never are rewarded
In addition, why not come say this with your main account?
We can improve it, sure, but let's ask why it works to begin with, and then improve on that. I don't think money is an issue.
Careful — some societies a while back "thrived" by relying on slavery. OSS is not slavery, but drawing conclusions just from apparent thriving is dangerous. (Other analogies: recent bubble collapses from the housing market & dotcom before that — those seemed to "thrive" too, before the bubble collapsed.)
> […] let's ask why it works to begin with, […]
One thing I'd throw on that list is people trying to build a name and reputation hoping to get hired in the future. This includes bright youths fresh out of high school, but also PhD students whose thesis delivery is turning into a dreading life change. They're running on borrowed time, and if it doesn't work out it's both them and their projects that are screwed.
Have you thought that maybe (a lot of) people make OSS for the fun of it?
There's not really a problem with FOSS software, as I see it. It's okay to disagree with it's principles (or even for the purposes of a single project), but the concepts of public licensing are completely moral and just. If we frame this as a money problem, corporate FOSS benefactors will build us a money pit. That's not what Free Software (capital F) needs.
Construction industry in Quatar thrives so well, specially thanks to the construction of their brand new football stadiums for the world cup
Manufacturing industry thrives to well in Asia, specially thanks to their ability to mass produce cheap Nike shoes
Do you endorse kids labor and slavery, is it compatible?
And i never mentioned "money", it's funny that you thought about it yourself
I can understand that it is hard to seek VC funding if you have to split the money with the real contributors, and not just that idea dude
I’d say evidence is to the contrary. This message wouldn’t be possible without open source working on multiple devices at every layer of the network.
I think the problem of funding open source well, that is a different problem and has a lot of the same problems getting anything funded does. Not every piece of code can have an enterprise built around it, and that means there will be no one to even look at bugs.
Finally, let’s talk about volunteering. Most often volunteering is doing something that doesn’t get cash budgeted towards it. You go in doing something necessary but unbudgeted because you want to… and with no reward other than knowing you made something work. Maybe you even give up something you could be doing with time instead of volunteering. Manning the directions kiosk at the hospital, picking up garbage in a neighborhood, nailing the roof onto a house the owner can’t afford to buy, putting letters in envelopes, and answering the phone at a fundraiser are all examples of this. You know what you are getting in to and you know what you are getting paid. No injustice in it at all. And for a lot of people it’s the most important thing they do.
I wonder how many other projects have also been kept out of the OSS realm for the same reasons.
Recently this has been my thought... that my future projects should be AGPL from day one.
To the existing ones, especially the successful one... if it does get too much for me, I shall relicense.
> Recently this has been my thought... that my future projects should be AGPL from day one.
If that means that companies can't use it, because that would mean, if they use it they would be required to open-source their managed SaaS solution ... that's a feature?
It prevents corps running their own version without sharing those changes back, and it forces corps to think carefully about whether they are willing to invest (their time and effort) in the OSS projects that they consume.
I doubt it would mean that they have to OSS their SaaS offerings. Most likely things are all implemented as little services and the boundary of what they'd have to OSS at most is one of those. More it forces them to be a better and more mindful consumer of OSS.
Some developers at $BIGCORP may think they’d be fine using an AGPL library/utility in one spot, but legal gets nervous, so they recommend management shut it down to avoid lawsuits.
https://www.theregister.com/2017/05/13/gnu_gpl_enforceable_c...
BTW, the AGPL network clause triggers on modification, not on distribution (which the AGPL has the same provisions for as the GPL) or public performance or something else.
If something is a derivative work for the purposes of the AGPL, then it's also a derivative work for the purposes of the GPL, or any other copyright license.
But isn’t that just a matter of setting your own boundaries? Someone demands somethign you don’t want to deliver you say “no” and that is it. If they are unpleasant about it you block or filter them.
You don’t own them anything. Not legally, and not morally. Just say no.
Or if you feel like it today say yes, and when the circumstances change say no. No biggie. You didn’t promise anyone anything. Any expectation on their part is a figment of their imagination.
Just don’t wrap yourself into pretzels over other people being unreasonable.
Left-Pad: dev deleted their software name in a package manger. Nobody demanded any maintenance, however intentionally screwing other people over is entirely different. Dev could have just never touched left-pad again and everyone would have been fine with it.
log4j: That was a maintained package, so i don't really see the comparison at all.
So yeah, no requirement to maintain your software. Taking a positive action to screw other people over is going to get those people mad at you. You're free to do nothing, you're not free to intentionally cause problems without hurting your reputation.
But even if you say NO to the vast majority of requests, it generally requires some real time and effort to address each one. If the originator does not feel like 'maintaining' a project and their is no financial incentive for doing so; then I think that can be a big barrier for many projects and can prevent them from being open sourced to begin with.
On the other hand I know more incidents caused by overfunded corporate OSS developers who have taken over projects and justify their existence by manically rewriting the code base for no reason.
Many of these incidents are covered up. Contradicting the corporate politicians is dangerous, because often they have installed dozens of other developers who always agree with them and are ready to libel dissenters.
OSS funding is a hard problem. OSS was best when it wasn't funded at all.
Extraordinary claims require extraordinary evidence. This vaguely conspiratorial comment about things "they" have done is a problem.
You have an opinion about what an init system "should" be. Systemd developers have another. If you don't want systemd, don't use it. What's that, you can't "not" use it because your distribution decided to use it? There's a good reason they did. If you think you know better, use one that doesn't, or do your own distro…
Systemd is also a poor example of an "overfunded" project. Some of its developers are paid, but it's not funded "as a project", it's just maintained by a company.
Want an overfunded open source project? Look at React. And yet, look at how incredibly popular and useful it is. The "overfunding" goes into conferences and developer advocacy.
Bad thesis, bad examples, easy to find counter examples. Money in open source can be problematic. More often than not, it's the lack thereof that is.
If you disagree with my post, downvote. If you engage in what you call flamebait(it wasn't), you are therefore fanning the flames, and out of line.
I do not believe your actions are in good faith here.
I didn't engage in your flamebait, I addressed the underlying side-premise that systemd might be an overfunded project.
(Again, you were wrong, however...)
Therefore, if you engage in any discussion related to systemd, as a reply, you have waded into what you claim is flamebait!
There is no escaping this logc. Hand waving, misdirection won't help here. Your actions were wrong.
systemd sure does a lot, but it does it drastically better than how it was done historically. It's been over a decade, this vitriol feels misdirected at this point. I cannot imagine going back to the cesspool of sysv rc-style init. What a headache.
> This default is almost always the last way you want an init system to do. It should never be the default.
What do you propose is a better default? If there is one, then distro maintainers are free to select it. I think the default chosen is very reasonable.
> And now it thinks it should add another OOM killer, before the kernel! Talk about feature bloat!
There absolutely should be another OOM killer. This strikes me as pure ignorance of dealing with OOM situations with any sort of intelligence.
The problem you highlight lands squarely with the Ubuntu maintainers not configuring their desktop environment properly. They should be configuring the user session slice with looser memory pressure constraints, but generally handling OOM further down the stack is a very, very good thing. A proper desktop environment might take advantage of these controls to suspend resource-hungry applications not in the foreground. This also opens up the door to things like asking browsers to dump cache when they create memory pressure, and generally playing nicer with other applications.
Experience, maintaining 1000s of concurrent servers, VMs, for dozens of companies, over 30 years, had shown me how systemd has been a negative, not a positive.
Part of the issue, as I highlighted, is feature scope. In fact, I said nothing bad about core systemd, as an init system.
As I said prior, as an init system, it would have been fine without all the added bloat. But here we have it handling everything under the sun, but again.. poorly.
Which leads to another issue, change. An init system is about stability, and stability is absolutely more difficult with change.
Systemd should shed everything not directly init related, and spend all efforts to stabilize, and keep pace with mainline, and kernel changes. That, and nothing else.
In terms of OOM, there is little point of discussion here, you're too far out in left field, too far from the admin world, to even hear me.
I'm not sure why you feel the need to attack my experience, but I maintained an internal Linux distribution for a Fortune 500 through the transition to systemd, managed fleets of 10-100k concurrent hosts, written hundreds of systemd units...
You're simply fighting against the grain. As a systems administrator, systemd helps you get stuff done. It's very powerful, and almost every feature can be simply ignored if it's not for you, which is great. The problem is that so much is intrinsically coupled to init. Want to start per-user daemons at user log in? Manage logging uniformly without the pitfalls of traditional syslog? Define reliable service state targets across network state changes? Isolate subsystems? Zero-downtime deploys without writing complex application daemonization logic? Portable services? Snapshots? Peripherals? Not to mention all the incredible work to make multistage bootloaders (and single stage!) completely integrated. Straightforward to debug, patch, build yourself.
It's definitely the worst, except for every alternative. I'm sorry that you find it so miserable. You linked to Ubuntu, so if that's the bulk of your experience, I encourage you to try a better managed distro. Debian, Arch, NixOS, or roll your own.
When you think killing all of apache2 is a good idea, because one thread OOMs, out of 1000 apache2 threads, of course I question your experience.
Obviously we won't agree here, we're too far apart, so I guess there is no point in discussing further.
I likely won't be checking back.
I've never mentioned apache2 so I don't know why you think I care about it at all -- I don't. I'm not sure what this has to do with my experience.
Your gripe appears to be squarely with the maintainer responsible for packaging apache2 for your distribution, or distribution maintainers who are responsible for configuring systemd defaults. If you blame systemd for setting a default that maintainers ignore the consequences of, then I'm not sure what to tell you other than that you're barking up the wrong tree.
Lennart Poettering has already left RH for working at MS.
“Best” is subjective yet I don’t disagree. But what you don’t mention, which I think is important to mention here, is the proliferation of OSS that other vital, closed source software (often monetized) depends upon. OSS has always powered vital software, I’m just making the point that it’s increasingly, alarmingly common.
“Alarming” because the OSS developers often feel they should be compensated if their work is monetized and/or powers other vital software. There is a license for this, but it’s difficulty and complicated to enforce. And it’s not surprising for someone to license their work as “do whatever you want with it” at first, only to change their mind later when they see it used in FAANG products. But then it’s too late, and bitterness and anger creep in.
Take the anger and bitterness of a generation+ of OSS developers and you have our current predicament :(
Or you can fork the project and ignore the politics altogether; FLOSS licenses will always protect your right to do this. Open source is a do-ocracy.
The closest example I can think of is firefox seemingly getting worse every version since they removed native extensions.
Some real numbers on this would be nice to have too. If you've seen any research in this area please share.
Do you have any sources for this? It doesn’t seem right to make a vague statement (a large chunk) which sounds bad, nor a somewhat less vague conjecture (maybe the majority?) without sources.
In my very limited experience, any developer who is significantly supporting OSS with code contributions is a high contributor for their employer, and if they don’t always do the agreed-upon number of hours/week for their employer, I doubt it’s far off. So I disagree with you anecdotally, which doesn’t matter much, and I question your sources, which matters more.
I am curious if there is actual data on the number of man-hours that are spent on open source per year, and how many of those are funded by corporations. My guess is that it is less than 1%.
It's a hobby, not a job. If it's becoming too much of a distraction - just...stop doing it?
Sounds good, I'll just remove my libraries from npm... (oh wait, that's left-pad)
Okay, plan B, I'll hand it over to a random person... (oh wait, that's event-stream)
Like the internet will collapse without left-pad?
But it's nauseatingly entitled to just expect people to pay a person for their hobby. Pick a different hobby if it upsets you? There are other things a person can do with their time.
You made a good point for asking for money instead of providing free work by the way.
Some of them could've been caused by underfunding, if a maintainer would have preferred to spend more time and care on their project but had to some other work to make ends meet, and got sloppy with their OSS project.
Yikes. Everyone is absolutely free to ignore security wherever they wish on their personal projects, but that just means I won't let any such code anywhere near a production codebase.
Gamification of contributions… shoehorning projects into other projects that get funding.
Forks just to try to rake in contributions.
Just free avoids a lot of problems, but certainly isn’t problem free.
So right now I mostly fund smaller projects because it feels they need it more, but at the same time I think I should also consider how important some piece of software is to me, or how much I depend on it, which gets really hard as soon as you don't just include "visible" software, but also libraries. I guess I'd have a really bad time without a jpeg library, for example. But that leads into your point about rewarding contributors. Ideally, every project that receives donations will fairly redistribute a share of it to every contributor and library they depend on, but that seems absolutely impractical to get right, especially for larger projects.
Also, should you take the complexity of a project into account? Not to diminish the work of the folks behind eg libjpeg-turbo, but a jpeg encoder/decoder isn't exactly rocket science, so should they receive less than for example libx264?
So yeah, I think this is a fairly deep topic that you can put a lot of thought into, and even get a bit philosophical about. Interested to hear other people's approach to this.
https://www.petekeen.net/ascap-for-open-source-software
Examples: Python Software Foundation, Haskell Foundation
In practice this seems to work well.
http://www.modulecounts.com
If this was a commercial vendor that went out of business, we wouldn't be discussing it. It would be a failure in the procurement process that didn't detect (and risk manage) the supplier's insolvency.
The same due diligence should apply to open source projects. The benefit of open source is that it makes code escrow (and follow-on maintenance) a lot easier.
If you rely on something you should try to ensure that it survives and trives. Especially if you are raking in money as a result of using that something.
Due diligence is a measure of the size of the risk. Eventually, the risk will outweigh the cost of checking. Some firms will track the cost vs risk and act based on that, others wait until it explodes.
e.g. The company is using software stack "D", and is launching a new business. They have no money. If they get sued, they close up shop and move on.
They have a successful funding round and get an injection of $100m. This hits the news, and they are immediately hit with a lawsuit alleging copyright infringement through their use of "D" (GPLv3 perhaps?).
Somewhere between launch and funding there was a point where the cost of diligence (detecting the license problem) would have dropped below the risk adjusted settlement cost (remediation + lawyers fees + lost sales), hopefully allowing the lawsuit to be avoided.
Then again, it might never have crossed below. Knowing that line is an acceptance of the risk. That's also perfectly valid.
A more apt comparison would be if a vendor didn't want to support an obsolete product anymore and so they remotely rig it to intentionally take down their client's business portal when they try to update instead of just not being available anymore.
(And of course, that's the analogy, many of the items on this list don't hold up to it, as is the case with all analogies)
Those are all risks associated with using a vendor, regardless of whether or not you are paying for the software. If your business relies on it, it should manage those risks (insurance, escrow, business processes, paying for support, etc).
The project disappearing/bankruptcy is only the easiest to point to.
Open source is fine and using it is great. I trust many dev teams, but not all. Many languages (JS, Python, Rust, Go) have a super extensible, developer-friendly library of open source components for you to reuse, but this model also encourages relying on these tiny libraries often written by volunteers with no time to prune and maintain their own dependency tree.
Personally, I try to just grab the code I need from small projects (with a link back to the library of origin) rather than add the dependency. This makes license management more difficult (as the source code usually comes with license terms) but packages like left-pad are better off in some kind of helper folder than in the dependency graph.
But you guys think it’s okay to have a social contract on enjoying that software? Isn’t that being a little precious?
People don’t get paid for play. So we collectively need to decide if open source is for fun or adulting. You can’t have your cake and eat it too, and insisting on it is going to get us labeled as narcissists. They label everything as narcissism these days, but still.
People too antisocial to live in our neighborhood... don't. There would have to be a solution to those people. They probably don't drag us down too much so they might not matter, either WRT neighborhoods OR source code.
I don't mow my lawn because my neighbor sends me micropayments for it or I have some elaborate and weird "HOA"-like contractual obligation to mow my lawn, I just mow it because that's what homeowners do around here and I moved here to fit in with them so obviously I don't mind, its good exercise at worst and almost hobby recreation when I'm planting flowers in the springtime. Likewise I do a pitiful amount of FOSS stuff but more than nothing, because that's what 'my people', and the people I like to hand out with, do.
Don't have a day job doing ONLY corporate work or ONLY FOSS work, do some of each. And don't expect a paycheck for the volunteer work. When I help pack boxes of food for hungry people at church I don't expect much of a paycheck either, but its just something I do with some of my spare time.
The hidden assumption is always that if paid corporates had not relied on free FOSS their paid for code would be higher quality... Naah they'd probably get powned twice as much its just they wouldn't be able to outsource the responsibility for bad code to some other organization. Fundamentally at the end of the day every org in the link "made more money" because of FOSS than they would have lost if they wrote inferior non-FOSS copycats of the FOSS code.
Some FOSS projects will require people working on them full-time.
I think a better, long-term approach would be to make FOSS work sustainable.
I'll take it if someone makes it free, of course. but I'll be damned if I'm going to pay some insignificant tax to support it!!
If someone depends on your lawn mowing for their business, and they require it to be on a high level of quality I would expect no less of a payment for that
And everyone who sold their home for a profit did.
And everyone who is now making their home available as a traditional rental is.
And everyone who provides their home as a short-term (vrbo, airbnb, etc) rental is.
Nah, they sold you land, a commodity. They don't care if you tear the house down to put in a parking lot (though your city probably does).
> And everyone who sold their home for a profit did.
> And everyone who is now making their home available as a traditional rental is.
> And everyone who provides their home as a short-term (vrbo, airbnb, etc) rental is.
And those people are the ones who own said lawn.
Imagine if Walmart/Amazon/Google decided to open a shop on your lawn without compensating you.
That is not how developers work. They very much do care if you tear down your house and put in a parking lot, because unless you bought the last lot in the development, they still have more land in the area to sell, and your actions could decrease the value of that land.
It might look like some smaller packages are just toys, but people take them seriously.
Mowing the lawn as often as most suburban americans do is a pretty awful thing for a breadbasket of environmental reasons (pollution, noise, soil quality, biodiversity, …). And yet.
Also, the american lawn really sucks. That's kind of another topic, but it's still a worthwhile plug to this excellent video: https://www.youtube.com/watch?v=6tfao7CZ0xQ
The other hidden assumption is around building your own or selecting existing tools. We used to call that 'Build or Buy', but there's no demand for proprietary tools in a landscape full of Free ones. There's often not even demand for new Free tools in a landscape chock full of mediocre options. So the choice has been taken away and replaced with a false one. It's reinvent the wheel or use unsupported software and never ever complain about it where anyone can quote you on it. Or do without, which puts you at a competitive disadvantage with the rest of your industry.
But you might get jaded if VPs of fortune 500 companies were turning up for the free food.
I tried reasoning with the founder about how, as a build engineer, I find that highly disturbing, but they don't see any trouble with that.
Wouldn't recommend, for that reason alone. Tidelift may be a better option here.
Most libraries rarely need the kind of maintenance work that justifies paying people full-time on them. It's often the case that a library is written and then done - future development may be maintenance type work (supporting newer versions of whatever), or increased coverage of the library's use cases. For all this, Tidelift and Paydevs are a good fit.
But most projects that really need continuous chunks of money are going to be end user apps, adapters/sdks (i lied, those are libraries, but they're more visible and often against a moving target), web services, infra services, etc.
For those, I recommend taking more ownership of the finance and setting up sponsorships via Open Collective (https://opencollective.com/)
Source: I run my own open collectives, have corporate sponsorships through there, I've helped several OSS projects monetize, created my own successful open source startup, etc.
If you're an open source maintainer and need advice on this, feel free to email me and AMA (see profile)
https://courses.cit.cornell.edu/econ335/out/lighthouse.pdf
https://lwn.net/Articles/909625/
- "PayDevs is "Monetization as a Service" for open source libraries. At paydevs.com, we provide closed registries for OSS maintainers to publish their compiled software libraries (or built packages). We restrict access to these registries and collect a contribution from private and corporate users to fill a money pool that is distributed each month based on the number of users a library has."
Having maintainers be well paid will not magically make your software bug free. Google pays their devs, their software still has bugs.
I wonder if the real problem it solves is a bunch of corporate types are starting to feel the ethical pressure of leeching off open source, and a nominal fee is the only way they understand the concept of giving back.
Let volunteers be volunteers.
If you see it as volunteer work, then yes you should not be paid, but you should also not provide services to wealthy organizations as they don't need it and can pay for their own needs.
If this is a hobby, then why are you putting your code on GitHub? you should just share it with small communities you enjoy hanging out with. And don't provide any services unless you personally know the requester and like them.
If this is more like art (think music), then you want to make it big, you want to share the code far and wide and for it to become popular, you help out developers from big companies (like record labels) hoping they notice you and pay you some day.
I personally think open source can take any of those forms as it's more about how the person works and their aspirations.
I'm confused. The vast majority of code on github pretty obviously falls into this category.
And quite frankly its pretty condescending. Would you tell someone who enjoys gardening to only do their backyard lest other people see it? For that matter, who are you to tell people who they can and cannot "provide services" to. Do you also object to people acting in local community theater?
> If this is more like art (think music), then you want to make it big, you want to share the code far and wide and for it to become popular, you help out developers from big companies (like record labels) hoping they notice you and pay you some day.
Similarly, how many artists have you met? Some do actually yearn for that sort of thing, but most are not in it to do that.
As for being condescending, I found your comments only considering the volunteer side of open source equally so, and I am a big fan of answering in a tit for tat manner on the internet.
I have met a bunch of artists, and all of them wish to make a living from their art. I have yet to meet one who only wants it to be a hobby.
--- edit: I for got to respond to this
"I'm confused. The vast majority of code on github pretty obviously falls into this category."
And that is obviously causing a lot of friction between the professionals there to do a job and the hobbyists (a person can wear both hats at different times). Both sides would be better off not being on the same platform. My argument is that the hobbyists should get out of the botanical gardens (to keep going with the gardening analogy) and take their stuff to a community garden or home to their front garden.
A weird example given many botanical gardens do rely on volunteers.
> As for being condescending, I found your comments only considering the volunteer side of open source equally so
I personally was previously employed doing open source work. I have no problem with people making money off open source if they want and are able to, just with the idea that it should automatically be the aim.
> I have met a bunch of artists, and all of them wish to make a living from their art
"Making a living" and "being discovered" are very different things. But if you really think every artist wants to do art professionally, you should umm, meet more people.
> And that is obviously causing a lot of friction between the professionals there to do a job and the hobbyists.
How so? I have yet to encounter any friction.
Although i suppose it also depends on what you mean by "professional doing a job". Even professional open source does not look like a real software job. There are no SLA's or garuntees from a professional open source project unless you pay for that seperately, so what even distinguishes professional open source from amateur open source.
> Both sides would be better off not being on the same platform.
Why?
More to the point, although there certainly are some open source projects with big $$$ involved on github, the really famous ones tend to be not hosted on github. E.g. linux is not on github.
> My argument is that the hobbyists should get out of the botanical gardens (to keep going with the gardening analogy) and take their stuff to a community garden or home to their front garden.
The phrase "corporate appropriation of the commons" comes to mind.
So, have a good day, and sorry for getting you excited.
The Log4J incident?
- FOSS is high quality because really talented people with drive work to build the best they can, across global boundaries
- FOSS is also high quality because it's an almost perfect market - discoverability is high, transfer costs low and so the best becomes dominant
- There is also a lot of bad FOSS code out there.
- Lots of FOSS like lots of proprietary code is just bloated.
- There needs to be some maintenance - but equally some ... it used to be called systems integration.
- I think the layer of for profit, not for profit and charitable work should focus there - systems integration. Imagine a world where a ISV gets "certified" on say a Python MatPlotlib, with at least two employees having made accepted pull requests. or something.
Now we have a layer of companies that have profit and cash flow and an interest in maintaining those foss projects. Not merely using them for free.
https://www.fossjobs.net/ https://github.com/fossjobs/fossjobs/wiki/resources
You publish the software under a permissive free license and then make a pikachu confused face when people start using it according to the said license.
What the hell did you expect would happen? If you wanted to get paid for software, why did you instead tell everyone that it can be used for free? If you want to get paid for maintenance, then why are you doing it for free, instead of setting up some kind of a bug bounty, when you only react after payment? Just add a bot that automatically adds payment link to new Github Issues or whatever you use. If you don't want your software to be used for making money without paying you, then add this explicitly to your LICENSE. It's srsly THAT simple.
And don't give me that "evil corporations make money on free software" bullshit. I remember it were the devs themselves who pushed for the use of OSS for their own convenience, back in the day the use of OSS was a hard NO in most enterprise shops, somewhere it's still is.
Throwing a tantrum just cuz people use the software the way that YOU explicitly told them to is plain stupid.