Open Source volunteerism is the result of the early hacking culture and of what makes the Internet special: people choose to experiment and share their work, and their work can reach every corner of the world. It has no significant parallel in other industries, it's beautiful, and I owe it my career.
However, it's not a sustainable, fair, or effective foundation for an industry with the responsibility to power modern society. We need the critical role of Open Source maintainer to professionalize. This is most likely to happen through capture by large intermediaries, but I wish to see it happen through the formation of a serious professional role, organized independently or in small firms, like lawyers.
This will require changes both from the maintainers [1] (become legible, get a LLC, send real invoices, offer guarantees) and from companies [2] (pay the maintainers, pay them real money, pay for maintenance, and keep paying them).
I think it's fine when you are doing open source for fun, and for other individual users.
If a company is basing their livelihood on your library, they should (in my opinion) be supporting it somehow -- either by paying you, or paying someone to keep an eye on new versions.
The other choice is they are trusting you to fix bugs and not be malicious, which isn't (in my opinion) reasonable, as you get nothing in return.
Nobody has any right to expect labor from an unpaid person. I get feature requests from people who make money with my OSS work (which I don’t begrudge), but unless I find the work inherently interesting to prioritize then I respectfully ask them to compensate me, make a PR, or file a GitHub feature request so that someone else can. I fix legitimate bug reports for free ASAP because I care about the quality of my work. Nobody has ever offered my compensation, despite the fact that my work has been used by millions of people. That’s fine with me though, OSS is just a hobby for me. :)
Anyone can choose this strategy, and I don’t quite understand why more OSS maintainers don’t.
> Nobody has any right to expect labor from an unpaid person.
I'm very grateful for OSS projects and maintainers but this is an interesting question: is doing something for free a free pass for false promises (advertising)? If I commit to help someone for free I then have a responsibility to show up. If an OSS developer advertise their projects as production ready then they have a responsibility to honor what is promised. Otherwise it should be stated plainly that the project should not be used in production ("This is a hobby project, use it at your own risks"). Sure it's less attractive and can be incompatible with success and resume building, but it's not possible to have it both way.
Yes, it is possible to have it both ways. Your reliance on something isn't material when trying to get support from someone you're not paying. Full stop.
Maybe it's important to you and maybe people you support -- but that has nothing to do with your right to make demands against someone who put their work out there for free.
If you need a guaranteed support model, you either do it yourself or hire a company to provide that for you. I've used _supported_ commercial software that's garbage, and I've used FOSS software which has been absolutely rock solid. Also, commercial or not, just because it's supported doesn't mean the problem will be fixed or a feature added.
If you aren't directly paying someone to be there for you, then you're trusting goodwill and/or the community at large to fill that role for you. If you need that assurance, pony up to one of the consultancies like IBM which will support "X" for price "$Y". That support you're referring to is available, at a price -- but doesn't necessarily involve the original contributors.
I've had far better luck with FreeBSD on servers for the past 20 years than I have with Microsoft Windows, but I also understood the deal: "Fix it yourself, or submit a bug report and see if anyone else wants to work on it."
The corporate software method: "Pay us lots of money to look into the bug report, and maybe we'll fix it, maybe we won't -- but you'll need to pay hourly until we determine if its a bug. Then MAYBE we'll refund your money."
The primary difference is that OSS gives you the source and the ability to fix problems on your own, without any involvement from the original contributors/projects. You can also hire any number of other companies to provide support. With a traditional commercial model, you're entirely at the mercy of the company which originated the software, and you likely have no rights to the source or tools which would enable you to fix the problem yourself.
Sure I don’t disagree, I think I was too broad. I’m talking about only a subset of projects that are not just free work put out there, but actively promoted as some serious building block with a business agenda behind like personal brand building. There is OSS and OSS, I’m not talking about FreeBSD, Linux or PostgreSQL types, but projects that are part of a company marketing strategy or resume building and kind of white lie about their seriousness. My issue is with marketing, promises and expectations, and not OSS as it is to its roots. Edit: for a concrete example, I agree with you in the case of say curl, but not for React.
Also tangentially I don’t buy into the binary distinction “it’s free it can be poison I can’t complain / I paid it’s my right to be an entitled asshole”. The cost is irrelevant with the promise for me, the first cent doesn’t have magical entitlement, and its absence is not a free pass to (white) lie.
> Also tangentially I don’t buy into the binary distinction “it’s free it can be poison I can’t complain / I paid it’s my right to be an entitled asshole”. The cost is irrelevant with the promise for me, the first cent doesn’t have magical entitlement, and its absence is not a free pass to (white) lie.
There is no binary distinction and it isn't about the amount of money per se.
What you're missing is that full extent of what you can expect is spelled out in the license.
Whether it's an open source license or a commercial one, a common one or a custom one. If you don't prefer the terms of the default license, attempt to negotiate a different one. You can always negotiate. If you expect more, expect to pay more.
There is no clause in any license (that I've ever seen) that says if this project is more popular or shows up more often in search results then the license grants the recipients more support. That's not how it works. Read the license, that's what you get, nothing more.
… PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
I think it’s particularly clear, and that part is even in all capitals.
Sure, but it’s for legal responsibility. I’m talking about marketing, i.e. lies/false promises and/or error inducing landing pages regarding the reality of the project. It was not general point about all OSS projects, but to point a difference between projects that are part of a dishonest business strategy (company or personal) and “classic” OSS.
> is doing something for free a free pass for false promises (advertising)?
If you have a specific project in mind, have you read the license under which that project has been made available to you?
If it is under most of the common open source licenses, you will find that it already states very clearly what applicability and support you can expect (none).
You are free to pay for a support contract if you need anything beyond what the free license guarantees you.
The dead simple solution to this nobody is talking about is to fork it. If you want to ensure that some random stranger (our friendly FOSS maintainer) isn't going to sabotage your product, the only solution short of negotiating a support contract with them (which some FOSS developers are not amenable to) is to bring that software internal. You still benefit from FOSS because you get a huge head-start from all the up-front work, but software maintenance going forward should be the responsibility of the user of that software, not of some random stranger.
But commercially this is unpopular because it means that companies have to actually account for the cost of maintaining a complex software stack instead of pretending all the open source dependencies maintain themselves.
This is really the only correct solution. Either pay the maintainers to do the work (preferable) or in-house the work (second choice).
Long ago at Sun the practice was that all code had to have an internal team maintaining it. If the code was brought in from outside that's fine, but some team internally still had to be where the buck stops for fixes. If all bugs can be fixed by bringing in updated version from open source, that's great. But if not, there's still a customer with a bug and it must be fixed by the internal team if that's what it takes.
Of course, this wasn't too popular with some management, since they wanted to bring in all the free code but offload all the work to unpaid volunteers, instead of budgeting for maintenance.
management and investors, whose goals are clearly stated by their roles, have no trouble taking "shares" and then some.. while people who build things "craftspeople" are motivated in a plurality of ways, and have often and quickly been written out of the bargain by the aforementioned. In each extreme, the situation is obvious. Yet, whole portions of a "modern economy" are now built on this..
You both feel right to me. We've found a vast amount of really important& exciting technology come from unhindered & unencumbered open sourcerers, people enjoying buding great things.
And I agree with you, that these people as their software ascends in use & importance, need support.
The term professionalization is dangerous to apply here though. There's a lot of baggage & constraint, power/hieraechy dynamics, employer/employee relationships that are no fun, are against the spirit of the thing. To have this vibrant, radical, free spirited altermative, & to turn around & try to consume the spirit of the thing, digest it into the the dun, boring, mundane mediocre shit-show world is a sure & sad way to wreck the thing. Yet these people deserve & need support somehow. Finding innovative ways to support those doing vast social good without binding & restricting them, without entailing them into your projects & curtailing their potential.
That all said, at this point, we just need to start funding these people far far better, step 1. These concerns about whether professionalization see destroys our golden vibrancy are abstract when so few (& only such select industrially useful) projects garner any support at all.
I, and a number of other people that possibly includes you, like programming enough that we do it for free.
I don't like doing free tech support for entitled mean people on GitHub, which is what you're really asking about, but I'm perfectly happy to throw code over the fence for the general public to use if they don't bother me about it.
What happens if the log4j developers just... don't fix the bug? Other people who rely on the library fork it, development continues with more funding, the world keeps turning, and maybe a few tens of millions of dollars of additional economic damage are inflicted in a diffuse fashion across the global tech industry.
The thing is, if you aren't getting paid, people can demand all they want. Scream until their faces turn blue, stomp their feet, bawl like a baby, write mean things on twitter, stick a voodoo doll full of needles.
It isn't nice though, as the maintainer. I gave up on doing any kind of open source stuff probably a decade ago for way less than screaming. Just getting bug reports is depressing, it was a relief to walk away and never have to think about it again. I know I didn't owe people anything, but hearing that I'd written buggy incomplete code (which worked and was good enough for me) sucked the joy out of it all.
For me, getting bug reports and feature requests is actually fun and makes the project more interesting. It is telling me that someone uses my software seriously and the bug was worth reporting. Many people don't report bugs because it takes some effort.
It can be, yeah, it just ground me down in the end. Deciding to stop was a huge weight off, I can only imagine the stress someone running a big successful project must feel.
I’ve always found people are reasonably happy when I send them big reports — though I always either send a fix or, if I can’t figure it out on my own, a test program that demonstrates the problem.
The last time was for some random library I was writing a python wrapper for and the author seemed way too happy to be getting a bug report for the code he based his master’s thesis on. Pretty amusing to be perfectly honest.
Yes, I like working for free. I tried doing open source work for money but the only thing that happened was that I lost all motivation. It stopped being fun and became yet another job. And I make more than enough money from my main job.
In my opinion Filo is completely off base. It's the Americanization of Open Source. Notice some of the OSS conferences in the US are big sponsored events by O'reilly, to some extent big recruiting events.
Contrast that to FOSDEM, which is completely different. This isn't just an offspring of early hacker culture. This is as offspring of how "socialist" european university systems were.
A lot of bigger OSS projects were started during peoples university time and what's so fundamentally different between how universities in Europe were before? You didn't have care about graduating. Some people stayed in University for 10 years, it was free and sometimes even had some benefits, like cheaper healthcare.
Now studying forever subsidized isn't always a good thing, but it has some nice side effects, like being able to work on your side project without having to worry about your livelihood(something that is unthinkable in the US).
The European higher ed systems has gotten more and more close to the US system with the Bologna process[1].
Most Americans immediately think about how to monetize things, and don't get me wrong, being able to live off of your open source project is nice, but it wasn't the focus in the past.
It's not as if this was something that started elsewhere and is being adapted to the American value system: Free Software / Open Source started in the U.S.[1] That's largely due to the fact that for the first couple of decades of it's existence, Internet access[2] was heavily concentrated in the U.S. as it was originally a U.S. government funded project. There are a variety of factors that have changed the open source ecosystem, Americanization isn't one of them. Quite the opposite: if anything, Open Source has been globalizing over the past 25 years or so.
[1] Free Software originated with GNU which was started by Richard Stallman, an American at MIT. Open Source originated in Palo Alto, CA as an alternative (less political, more business friendly) approach to Free Software. There was freely available software prior to the formalization of terminology and licenses from organizations like FSF and OSI, but even then most of it was from developers in the U.S.
[2] Prior to the Internet, most open source projects were heavily concentrated in the U.S. as large scale distributed projects weren't a thing until the 90's with widespread availability of Internet access.
I was in the room with Richard Stallman, in Palo Alto, in the 1980s, as he gave a careful and serious presentation to about twenty chosen people.. from my point of view, the statement above does show one part of the OSS evolution. Meanwhile, the "net" was growing as a combination of ex-dot-mil and their allies, and people who were deeply committed to signals, evolution and in most cases math or physics training, for its own sake, and the social evolution it implied (science fiction readers and highly creative signal processors like musicians but different).
both sides of this odd couple had different motivations and restrictions, but they cooperated in building the network and the software that ran the network. People here have complained, but I claim, TCP/IP was not the only network game in town then, and the massive scaling that you see today was not done yet, and did not work for lots of reasons. Many OSS projects related to the network itself, the signals across the network, and math/science. The media world was largely influenced by commercial print and Hollywood, and was less influential in the early days, as they stuck to the commercial distribution mechanisms. Network media tended to be odd, music-oriented, or sick things, in those early days. Also note that single, massive source code repos were not a thing, so people traded "tarballs" with important releases of whatever.
Linux has been developed by paid professional developers for 20 years or more. I agree that the European university model is interesting for initial R&D, but things have to professionalize over time.
If you just want to share code, that's fine as well, but that's not an OSS project (sure, it can be an open source "project" - but not a project that grows)
The alternative is not the status quo. Look at all the talk of supply chain security from the big players. The alternative is that all power and profit is just moved to large institutional middlemen or directly to a few big companies who can afford such a program.
If you don't care about control over the downstream of your project, or funding, no one is forcing you to professionalize! I just want that to be available as an option to those who do.
I worry that if the majority of open source contributors professionalize, then we're left with something that resembles top-down directed corporate work (and an absence of a lot of the freedom that draws people towards developing free and open source software in the first place).
Proprietary and corporate players are equally useless at securing their supply chains; I don't love that (from my perspective) they're now blaming and trying to coerce open source to become more like them to ostensibly fix the same problems they propagate themselves.
I'm not a security nihilist: I think improvement is possible. But in my experience, not many corporate managers or project sponsors ask for removal of features and reduction of attack surface.
Anticipating a counter-argument: wouldn't individuals become the arbiters of the software functionality that is developed, if all open source software was based on a sponsor model? Isn't that more democratic?
Perhaps; some financial statistics that I'd suggest to consider would be:
- As of June 2018, U.S. households in the 0-40% income-level group had $0 median savings[1]
- From the same source: the median savings for a household in the U.S. is approximately $11k. There are approximately 120m households in the U.S. according to the U.S. Government census[2].
- As of 2022, thirteen firms from within the S&P 500 hold a combined $1 trillion in cash-on-reserve[3]
And yep, it'd be sensible to debate whether individuals or companies would be more likely to influence the direction of software; it's a disingenuous comparison to draw in that regard.
But even if we consider only individual citizens, there would still be significant disenfranchisement in dollar-voting ability.
The recent elementary OS melt down shows the problem with this path. Creating a business to act as a middle man creates a situation where no one can reach the people who want to do maintenance because business interests will develop and want to hold the code hostage. It is better to form non-profits that hire maintainers.
Elementary's problem is it has two inexperienced founders who aren't negotiating with each other very well, I'd hardly call it a meltdown, nor particularly relevant to the examples in this article.
The entrepreneur in me will never understand this problem: "programmer creates world famous software used by Microsoft and NASA and doesn't make any money and is burning out from all the work."
Here are your solutions:
1) If the users want support, charge them for it. Split the proceeds with someone who will actually do the support. If it's still too much work, raise the price.
2) If the users want features, charge them money to put those features on your roadmap. If they're asking for features you don't want to add, just raise the price or say no until they go away.
Here is what will happen when you ask for money: people you don't want to deal with will disappear. Also you'll have more money, and you will work less.
Do you need to think about business a bit somewhere in there, sure, but probably a lot less than most people think. The "business side" for the Grunt guy could probably be "register an LLC online then get an Upwork account and let them handle the other shit like your payments and tax forms for 5%." Yes, fucking Upwork.
There's nothing wrong with a consulting model yet I wouldn't use code under their direct/complete control. Plenty of Apache Projects have members that are in consultant companies, their willingness to make changes for cash is balanced by other orgs that only want to contribute directly, ensure existing functionality, etc.
I'm arguing against middleman businesses, not for.
I don't see the non-profit model scaling to the whole industry, and the examples we have today of non-profit foundations mostly don't pay maintainers. For example, Log4j is under the Apache Foundation but none of the developers on its committee were being paid.
Elementary OS as a business was the two initial maintainers and that fell apart pretty spectacularly, plus a lot of the work was really not theirs they were just a distribution.
Apache's model is the traditional one which isn't aggressive enough. Linux foundation is more aggressive about offering lessons as products etc. I'm not as happy with LF' model as the hippie model but it is better than devolving into no new work causing no one to donate because ex-maintainers are supposed to have vesting future stock, etc.
Said it elsewhere, Elementary's problem is that "Desktop OS" is a deceptively stupid business model. "The Desktop" was essentially solved about 20 years ago, but Microsoft and Apple are powerful and interested enough to really screw around with them in a way to make it seem like this is not the case.
Most companies are just free-riding because they can and because it makes financial sense, at least superficially. I don't see why this would change. Sometimes they get hit by the occasional security vulnerability in a badly supported dependency, but if it's commonly used in the industry the fallout will be negligible anyway, so why would they reevaluate their stance?
Companies that heavily rely on one specific FOSS project and have well-defined requests naturally get more invested in them one way or another. But even for these, which tend to be bigger tech companies with more cash, "just pay the maintainer" is a tough sell when they can just either come up with their own project (even FOSS and recoup the "losses" in proprietary IP with hiring marketing) or fork it if PRs from employees are not well-received by the maintainer.
> "just pay the maintainer" is a tough sell when they can just either come up with their own project (even FOSS and recoup the "losses" in proprietary IP with hiring marketing) or fork it if PRs from employees are not well-received by the maintainer.
Also "just pay the maintainer" doesn't contribute towards most managers' primary goal of empire-building. In my experience even getting individual contractors paid for work can be a tough sell, managers want headcount and the opportunity to abuse their minions.
A "maintainer" receiving funds somewhere on the internet to play in their sandbox just looks like enabling escape from management's prison.
Maybe liability would encourage some changes. If you pay the maintainer they are liable for security vulnerabilities but if you don't pay then you are liable.
There are an uncountable many "consultants" that basically did this, and use their GitHub basically for lead gen (I've gotten a good handful billable hours off people finding mediocre little packages I've posted for articles, and that's without even trying).
I think the disconnect is for devs that don't want to do that. But those same devs probably don't want to incorporate and go through the hassle of running their own business either. For them, who really just want to hack around and make software, I don't know if there's any real path. The whole value proposition of full time employment for a company is that someone else takes care of all that nonsense and you get to just do the thing you're trained for. Trying to extract that narrow piece out onto its own doesn't work well, and I honestly don't know if your solution really solves for that.
Academic publishing is a very interesting parallel to think about, indeed!
In particular the fact that often when a publication turns out to have industry value, a company is formed around it to commercialize it: both to extract profit from it, and to make it accessible and legible by companies. Companies by and large don't take academic papers off arXiv and implement them.
The rest are funded through grants, which have the side effect of directing a sizeable chunk of the academics time to writing grant applications rather than science. I think that would be a regrettable outcome for Open Source.
> The rest are funded through grants, which have the side effect of directing a sizeable chunk of the academics time to writing grant applications rather than science.
That's not a consequence of grant funding itself. The traditional academic career path jumps directly from a trainee to a manager, and managers have to do what managers do.
Larger research institutes have positions for professional researchers. Those researchers don't have to spend that much time on grant writing, unless they want to become managers or they are trying to remain competitive for positions in the traditional PI-centric academia.
That's a key lesson for FOSS. If the development is funded by grants and donations, the organization should be large enough that every senior developer doesn't have to become a manager.
Thank you for these blog posts. One thing that isn't immediately clear to me is how one should start a new open source library (before there is any traction) to be prepared for this structure of maintainership.
For example, I'm already a freelance developer with (my countries equivalent of) an LLC and I send invoices to my clients for my work. I'm also in the process of writing a few libraries in the mobile/desktop/web shared-code space that I want to release as open source. Should I just mention this on the projects Github and website properties? A simple "contact me for an invoice" link and process the invoices/payments manually? Is there a platform a la Github sponsors/Patreon that is compatible with this workflow?
Honestly, I can't give you an actionable plan at the moment. We are simply not there yet.
Eventually I hope there will be social norms (like how you advertise the option), tools (like payment rails and platforms, hopefully not like Patreon, but more like those lawyers use to invoice clients), resources, and even training. I hope it will become a standard transaction, that companies have processes for approving with no ad-hoc work.
But for now, whoever wants to try this is in uncharted territory, will have to discover what works by trial and error, will have to teach companies how to think about them, and will need some significant leverage to spend (such as personal networks, visible projects, and savings).
If people were adept at consistently setting their boundaries, in the face of demands that can be overwhelming, indeed the problem would be trivial maybe. Just say no.
But just saying no for many people is still a non-trivial skill.
Also, just saying no in the face of consistent and repeated demands while mixing that with a desire that many creators have to be responsive to the people who use their software and to satisfy those people to some extent, compounds the difficulties creators face.
I definitely think it's an obvious opportunity to bring more order and structure to these currently ambiguously defined exchanges. I believe we can do better than stress and ambiguity on either side of that.
Sure, one solution is creators just saying, "I don't want to do this right now," so just shut it down, close it, block them whatever, heh. I actually think that that's not as much of a general purpose solution as it looks like at first because creators do actually want to help people with their stuff, and they also want to get rewarded for doing so (because you know they need to eat and everything), and doing so actually takes a lot of time, and they also want to control their taskflow to some extent.
I can't read the article because it's paywalled, so I'll respond to this comment instead.
> Open Source volunteerism is the result of the early hacking culture
I don't agree with that take. There was not, to my knowledge, a "volunteerism" component of either early open source or early hacking culture (though my roots only go back to about the mid-80s). The "volunteer" part came later, as there was an explicit effort to emphasize open source as free as in free labor. What I used to see was openness in the sense of knowing what the code did and being able to make changes if you want. It was more of scratching your own itch and letting others play with the code if they wanted.
I agree! I think Open Source volunteerism is the result of that culture, not its embodiment.
No other industry had a large portion of its R&D done by people scratching their own itch and sharing the results freely. That led to relying on that freely available work, which led to volunteerism.
I remember the volunteerism as being a way for non-developers, who couldn't otherwise support a project, as being able to contribute to a project: write docs, triage bug reports, answer user questions etc. so that the developers could focus on the code, which usually was to scratch their own itch that others found useful. It wasn't ever really a hard sell, just an alternative way for less- or non-technical people to participate and also shut up whiners. As open source foundations started popping up all over the place hoovering up sponsorship dollars, that's when I recall the 'hard sell' of volunteerism starting (i.e. making people feel better about scratching someone else's itch for no money... what most of us call jobs and demand payment for)
Isn’t what you’re describing just the business model of open core companies like Confluent, or MySQL -> MariaDB? The intermediaries tend to grow large for successful open source projects, because there’s a lot of money to be made, but it’s not uncommon in my experience for the core maintainers of a project to go found a company around it. If it’s just an awareness thing, by all means, let’s make sure open source maintainers know this is an option available to them.
Part of a workable solution might be to incentivize companies funding the FOSS they depend on. Tax incentives and the like. Developers only get so much say, get the beancounters involved.
That would pivot a lot of those merch and drop-shipping hawkers on YouTube to “here’s how to make your own FOSS library and collect your friends’ €100!”
We’d get a lot more of “things that qualify for the €100”, but it’s not clear that we’d get a lot more useful FOSS.
Your average citizen probably doesn't know what open source is, let alone could name one project.
So most likely most people would not give anything because they don't know/care, and a few marketable projects (like VLC) would get most of the rest, way more than they need.
In many ways it was (and is). Many research projects are government funded and produce FOSS. The entire industrial/academic space surrounding the development of Unix, sharing of source code tapes, and the emergence of RMS and GNU were running primarily on government funding. The long-running jokes about Linux and beowulf clusters were echoes of the actual government funding driving many activities where FOSS interface with computational science.
Now, you might have the mistaken idea that science or other R&D funding is easy to access like ticking a box on a tax form. No, you need lots of bureaucratic support and so to work under government funding is to get a job in a university or other research lab that is equipped to chase, win, and collect government funding. Your position is "soft money" and depends on either you (as a principal investigator) or your boss engaging this constant struggle to win the next contract that keeps you from losing funding and your position. Some of this money splashes around to student workers, graduate students, postdocs, or interns. A lot is spent on more permanent, full-time faculty and staff as well as other infrastructure and administration.
The big shift I have seen in my ~25 year career is that the industrial participants in this environment have shifted from being primarily government-contract focused to being consumer-focused. The whole cloud/internet revolution has brought these new corporations who no longer depend first and foremost on government grants from the science or defense research complex. Earlier, we also saw shifts with enterprise, B2B-focused corporations and vendors, but I think they often had more overlap with the traditional government funding sources and also blended in a little more.
Via grant proposals that all include obligatory tenuous connections to the "big" issues of the day (anti-cancer research and green energy in case of the sciences)?
I'm an open source maintainer. I have a different take. Yes many projects lack funding, but I'm hesitant to ask for funding for my projects. Because: what sort of social contract would it imply if people fund me? Should funders be elegible for faster response times? Should their feature requests be implemented with more priority, or must they guaranteed to be implemented? What are the expectations of me? Can I take an extended holiday and go offline for a while? None of this is well-specified.
One can argue that funds are donations and thus are free from attached strings, but psychology doesn't work that way. Funders will feel entitled to something, but what? You can see this pattern more obviously in Patreon: donors get something in return, such as faster access to content. So even though it's a "donation", people psychologically still experience it as a trade.
With Phusion Passenger, I've commercialized a open source project. The contract is clear: if you pay then we both know exactly what to expect from each other.
Formalizing the expectations to funders of my other open source projects, effectively turns those projects commercial. But to me, the appeal of my other projects is just that I can code on my own leisure, as a hobby, and give a gift to the community at the same time. It sucks that I have very little time for that because I work on those projects in my free time only, but I'm hesitant to turn those projects into "work" where I have to give guarantees in return for money.
I maintain an open source project which is used by a few hundred companies, and I also sell a couple commercial products which enhance the functionality. I don't accept donations since I much prefer to offer well-defined commercial products instead of ill-defined donation benefits.
Despite this, I've still had users who insist I should accept donations, often claiming that I would make some absurdly unrealistic amount of money if I did so. In one case the user kept arguing with me and demanding to know more reasoning as to why I didn't want to accept his donation. Of course these same users are absolutely not interested in the well-defined paid products and always offer weird mental gymnastics as to their thinking.
I just can't relate to or understand this behavior. Do these people burst into random businesses in real life and say "Hello, I love your store but don't want to buy any of your products! I demand to know why don't you have a GoFundMe?"
I understand why you structure things the way you do, but I can speak for myself in a hypothetical scenario where I had money (now) to donate to an open source project that offers paid features. I might be concerned about paying for the paid features, because if I become reliant on them and then my capability to pay for them changes in the future, I'm now in an unfortunate position of having to re-write the features I've grown dependent on, or rewriting other parts of my codebase to remove the reliance on those features (a big refactor later can be more costly than planning properly in the first place)
I might then prefer to just use the open source version, and donate when I can, to avoid accidentally becoming dependent on something that I'm not confident of my ability to afford later.
That's a good point, and I can somewhat understand that perspective for some types of software, especially projects geared at individual developers or very small companies.
For infrastructure tools that are typically adopted by an entire org or company though (as my products are), the situation is less understandable to me, even in the scenario where the user is a small bootstrapped company or solo dev.
I mean, my own company is small and bootstrapped, and I still pay for a number of commercial products because they provide benefit to my business or my own productivity. If I ever can't afford them in the future, that would probably indicate there are deeper existential problems with my business besides needing to rewrite some code to avoid use of those commercial products :)
Also, personally if I wanted to give money to open source software but was unsure about the future affordability of doing so, I would especially focus on donating to open source projects that are actively soliciting donations in the first place -- rather than arguing with a business owner over their lack of interest in donations, which is what some users have done in my case.
I’m an open source maintainer that asks for donations with a basic “Buy me a cup of coffee” link.
IMHO the person donating already got something in return which is the free software + the good feeling of having donated.
I don’t offer anything in return for a donation because I also don’t want those strings attached and I feel at that point it’s no longer a donation. If I offer something in return it turns into sponsoring or simply buying services/access.
> I don’t offer anything in return for a donation because I also don’t want those strings attached and I feel at that point it’s no longer a donation
Couldn't agree more. The scope creep of this term hurts both parties. If there are expectations, call it a sponsorship program and state them clearly what it entails.
I depended on a FOSS project once that was mostly done by one maintainer, and would sometimes send feature or fix patches upstream. Once I sent an e-mail that I could give him hundreds of dollars for some bug bounties - his program would improve and he would make some money out of it. He said thanks but no, he made enough in his day job and only had limited time to maintain the program.
I think your experience may be different from the psychology-of-obligation issue that the GP describes.
For someone in a stable, salaried job that pays reasonably well (assuming USA level or the better paid parts of Europe), it rarely makes financial sense to accept "hundreds of dollars" for a complex task.
That's due to the amount: "Thousands to tens of thousands" would likely get a different sort of response, assuming it sounded like a reliable offer, not a gamble.
Most FOSS bounties pay terribly if counted by the hour. I'm guessing the bounties came to "hundreds of dollars" for several days (at least) work on the developer's part, because so many other FOSS bounties do? They would have to take formal vacation from their day job to do that work, or extend their working hours to focus exclusively on your issues across many evenings or weekends, at cost to their personal life? They would have to change the way they file taxes to accomodate this payment outside the regular flow of salary? Or, if they work in a job paid by the hour already and with flexible hours, they would be getting less accepting your bounties than they make at work?
The burdens and typically low pay make it a net negative to accept small FOSS bounties, for a reasonably well-paid salaried worker, just on the basis of economic rationality. The psychology of feeling obliged to finish the project after agreeing to do it is just one more burden.
> They would have to change the way they file taxes to accomodate (sic) this payment outside the regular flow of salary?
This affects my end as well - I was monetizing their product, and could probably justify an unsolicited bug bounty as external work. I don't know what the status of an unsolicited donation would be, I would have to ask my accountant.
The main premise is that some FOSS projects turn down smaller donations. In my case for a bug bounty, in GP's case a more general donation. When people discuss the need for FOSS donations, these cases aren't always mentioned.
In this specific case for me, the upstream was already fixing bugs in the tree, (as was I), and upstream was monetizing their product as well, so I thought it might work out well for everyone. At the end of the day I felt better about it anyway, because I was monetizing and using their product, and I did make an offer. I wound up contributing back with feature and bug patches (the bugs I could figure out how to fix).
I don't think funders should get any more say in or influence the direction of a project than anyone else. That should be up to the maintainer, of course taking advice from the users and contributors to the project. Funders are simply buying sustainability of the project, and that should be enough for them. This is how it works in projects like Inkscape, Krita or Debian.
I view it as two separate categories; donations & support contracts.
Donations are a thank-you payment for the code as it exists today. If someone finds it useful or includes it in their commercial product, give me a donation to reflect that thankfulness. It doesn't get you anything in the future, it is a payment for what exists today as-is today.
If someone wants a guarantee of future work, whether features, bugfixes or support, that requires a support contract with a much higher payment and more formal terms. In that case, they can influence the future direction but it'll cost orders of magnitude more.
I'm not saying doing this would be trivial (and you'll definitely want to engage lawyers to help do it), but if you do take support contracts it will have to be well-specified in the terms of the contract.
So the answer to all those questions is that it'll be whatever you and the contracting party want them to be as part of negotiating the contract. The more they ask in terms of speed, guarantees, availability, they more you'll make them pay for the support. If there are things you don't want to do, make the price so high nobody will pay it (or if they do, then hire out the work since they paid you so much for it).
At the same time I think there exists an opportunity to bring the ordering and structuring function of transactions to the open source marketplace.
And I don't think the donations are subscription model really works for the reasons you enunciate meaning that everything is too unspecified, yet there are definite implicit expectations of some sort of transaction or exchange. The non-specified nature contributes a lot I think to inefficiency as well as to stress for both sides of that marketplace. It's only one of the factors that makes changes in open source currently not ideal.
With current models, even if you do specify it it acts maybe in a sort of way like a patreon model which doesn't really make sense in open source which has almost unlimited number of discrete continuously redefining tiny tasks.
The way I see payments working is more as a formalization of your choice to say yes or no to things so basically like okay here's sort of like my minimum fee or here's what I'm quoting to take a look at this. There's no guarantee that you know the entire issue that is unspecified and that could balloon into multiple future directions is going to be solved by this but here's the amount which I need right now to take a look at the next step.
Some people might view that as a way for them to make money or extract value or get reward for themselves out of their projects that is sort of tied realistically to the actual demand that people are prepared to put their money where their mouths are.
Whereas other people might see it simply as a way ensure they do not get overwhelmed by allowing the market to decide priorities, and provided down regulator or gatekeeper on the amount of incoming work. The filtration function happens before the requester even makes the request ideally because then once the expectation for the transaction occurring sometimes is established requesters may think more about steps they could take themselves other than operating in a more depending on demanding way. Possibly anyway.
For the creator, you can formalize your no by putting a price in front of it saying it'll cost you this much for me to take a look at it. But the thing is the person who made the request isn't the only person looking at that issue presumably and they don't have to be the one that pays that through.
Anyway I just just an experimental idea. The real interesting thing and where the meat is here is like how do you structure these sort of micro transactions, that sells problems on both sides of that marketplace. In other words you're allow developers to exercise more control over their incoming workflow which is a key driver of happiness you provide the opportunity for them to get rewarded for their open source efforts in a way that's actually tied to specific toss rather than a nebulous sort of funders model or sponsors model, and you provide a bit more like clarity and definition for requesters you know to think well is it really worth it to me to to make this request and how much am I prepared to kind of you know put up to have this creator I take a look at the next step for me.
I think there's multiple ways you could configure bringing the ordering and structuring function of transactions to the open source community. The above is just Possibility.
I don't think things are nearly as "broken" as these types of alarmist takes make it out to be. Quite the contrary I think FOSS is a model that other industries would do well to adopt.
People talk about companies "free riding" on FOSS, but the corollary to that is that this allows an individual developer to be massively more productive, justifying the high salaries we see. To obtain value from just about any open source project, companies need to hire developers, individual developers are in a position to benefit as the gatekeepers to all this "free" value.
Everyone is benefiting from this. Free is absolutely essential to making this work. Free is frictionless, free is equalizing. I'm not choosing between Redux over Mobx based on price, I'm choosing purely of intrinsic merits and community.
It is always easy enough to find problems, but looking over the past couple of decades, I don't think you can argue but that things keep getting better.
On the contrary, SaaS company are advantaged at exploiting FOSS and this is creating increasing inequality in access to software, hardware, knowledge/skill, markets and capital.
In short, FAANGs and SaaS take all.
There's a reason why progressive taxation and public funding has been invented: infrastructure that benefits everybody need to be paid according to income.
Part of the problem is probably the high amount of churn. In the Javascript world this is absolutely ridiculous, people just can't seem to leave things alone and it causes a cascading effect, where one developer makes an API change and suddenly thousands of developers have to deal with a change that typically brings them no benefit. It's pretty much a self-inflicted wound.
I don’t understand the sheer volume of major version increments in JS projects. Avoiding breaking changes should be one of your main goals as a developer, yet I swear some libraries have major version increments multiple times per month.
Modern JavaScript grew up in the culture of “move fast, break things”. Combined with JavaScript having a limited “vocabulary” and being the new PHP, you end up with a lot of churn as people start building large applications without the tooling for it.
One of the most important things a FOSS (and not only) engineer can do is learn to say no.
And then decide if they do it for fun, or want money. There may be some overlaps, but it should be crystal clear which is the main one. This is 100% their choice. Trying to sit on two chairs usually ends in misery.
And if they treat it as a hobby (fun) and a company, NASA or someone else needs a fix or a feature ASAP, well, they can always do it themselves. You do it if and when it works for you. The software will likely be better that way, too. My 2c.
Sure 300k barely supports US market rates, but should it?
There's plenty of people working the same job for many years with low-ish salary? Sure they could find new one and get the latest high market but they haven't
I mean the project was already being developed before even having full time staff, and some contributors are not in the US and could live less for sure
many OSS projects can go a long way the same way
and that's the point, why should babel take "a big chunk" of OSS donations, while many others take nothing
and looking at another comment below, seems it's becoming irrelevant, so it would make sense to reduce funding further and let staff to move away to other projects or take full time employment at a profit making organization and take market rates.
Babel should get however much of the donations as people want to donate to it. If other projects want more donations, they should be looking to users of their project, not to users of babel.
If babel users become unhappy, the pace of donations will decrease naturally. That’s a good thing, IMO.
Yup. I was assuming $200k total cost for a senior developer in the Midwest. If you want someone on the West coast, you’re easily looking at $300k for just the salary due to the cost of living being more than double.
Babel is now a less-than-useless project. It's a hack; which, like most hacks, was kind of useful when it first came out but was supposed to have a short shelf life. It only became popular because its creator was hired by Facebook and was promoted heavily to developers. IMO, it had no use outside of Facebook or any large corporation... Updating code to make use of the latest language feature at a later time is not difficult at all unless you have millions of lines of code; and even then, it can be automated to some extent.
People should simply stick to the slightly older JS syntax while waiting for new versions of JS to reach mass adoption... Essentially all of the new features add very little value nowadays (mostly cosmetic value)... Surely you can wait 5 years or so... There hasn't been any significant 'must have' feature since async/await anyway. It's not worth adding 100+ Babel tooling dependencies and sub-dependencies to your project and adding a transpilation step just to reduce your project's code size by 2% (that's what cosmetic changes to ECMAScript are about really)... Just use the older feature; this is the most compatible approach.
Babel is particularly shady, because before asking for this money they dropped making their own polyfills in favour of core-js, which turned out to be a bad move considering the main contributor of that library found himself doing time in a Russian penal colony.
Unfortunate about the maintainer of core-js. But how does that make Babel shady? Especially if they made the change before asking for money.
Sounds more like they were struggling with workload and made what, at the time, seemed like a reasonable decision to offload some of the work to another library.
Also the core-js maintainer single handedly carried that project, with no financial support from Babel (or hardly anyone else for that matter). It became a vital part of the ecosystem, and then the community hung him out to dry when he asked for more support. The whole thing was shameful, especially those who mocked him for his unfortunate personal situation.
Quite shady that one of best funded OSS projects come public asking for more money, but when the community start questioning the expenses/the specific contribution from a certain member there's only silence
(I haven't seen any response regarding their post in May last year asking for money)
The project is big enough that it should be a _lot_ more transparent :)
Okay but how many FOSS projects decide to pivot like Ukuu did and just drop the F? If the free is killing you, stop being free. Leave your free repo as is, add a link to your purchase page for future versions.
Where’s the problem? People seem hell bent on sticking to core principles until their dying breath, but that’s not healthy.
Edit: and before people start laying into me about free as in speech/beer, this article is about the latter, not the former.
If you want your software to be FOSS, then you must accept than people can and will fork your work and make more money than you while doing it.
If you don't want your software to be FOSS anymore, then you have to accept that at some point previously the "meat" of your code was already FOSS and you will be effectively competing against yourself.
I still don't understand the problem, it's inherent in the decision to become FOSS in the first place. Or do you mean these folks who are complaining just didn't understand what FOSS meant before they got into it?
Open source contribution has shifted from bare technological enthusiasm to career and marketing strategy.
Users feels that, and started to show more and more entitlement which erodes contribution satisfaction.
Open source only works if contribution is of selflessness sharing, as soon as it starts to be an investissement, users have the really legitimate feeling that a weird kind of reciprocity is in play, that tatters confidence and candor.
I believe this article actually depicts the insanity of how some people "work" and getting paid for that.
> many are quick to press him on what's taking so long.
> people are shouting at you that you need to work on something
This is not normal even in a workplace!
Article not necessarily about open source but workplaces in general (not even IT only) only difference is that people in workplaces are getting paid to work in those horrible conditions.
Disclaimer: I'm unemployed, released some open source stuff https://mkws.sh/, https://adi.onl/projects.html and surviving as I can rather then being pressed or shouted at I need to work. I value my mental health, thanks!
I think the "critical software industry" story is fascinating and if research does not already exist in these areas let's fund more of it:
1. Let's baseline the usage and spread first. What code is used, where and by whom. It ought to be possible to get complete pictures of this most large orgs scan their whole estate constantly - but publishing it academically?
1.a. A central "phone home" FOSS library that everyone "trusts" will just report the minimum might be a good idea here.
2. So if we know what codebase are critical we can then ask are they supported? Are the top five contributors paid in connection with the code base? Lots of ways of finding this about but email or bug requests is most likely winners.
3. A move I think is a good idea is to have some form of "Foss Tech Support Mesh"
Library X is really useful, so several ISVs announce they support it, understand it etc. Maybe if an ISV account gets a commit accepted they get a badge. This will start to bridge the gap between volunteers and paid positions.
while we are at it, what is the proprietary story? I am pretty sure Facebook has funds to keep its codebase updated, but there were MRI Scanner companies that cannot afford to move off windows XP, so there is bound to be a grey area of for profit companies producing code at not much more than subsistence level.
Phoning home doesn't sound right, but maybe a bunch of FOSS developers can get together at some point and form something analogous to ASCAP.[0] i.e., monitor the public and commercial use of members' FOSS projects; shake down the users for financial contributions; and redistribute any proceeds to members as royalties. (I wouldn't be surprised if this has been tried already and failed. Nothing seems to make a difference.)
I like what the React Training guys did with react-router: use the organic traffic from their library fuel their training business.
Treat the FOSS project as your lead funnel, then sell a service to those leads.
Maybe the service is training, maybe it's hosting the project (e.g Wordpress), perhaps it’s just leveraging it to get a lucrative job offer. You need to sell a service though on top of the project itself.
Please not. I understand that this kind of works and provides income for a lot of people but especially in the Wordpress world every plugin is just one huge piece of upsell ads with limited functionality. I don't blame the developers who do this but it's not a solution.
The article sums up to 'programming is hard', support FOSS devs. Which is hard to find a fault with. The tone is a bit chicken little given that everyone experiences burnout if they have complex jobs that people depend on.
In the end, devs probably need to stop being so easy going. Everyone probably needs to be a little more Linus.
This is the most difficult part of FOSS projects, and why relatively few of them match commercial products in quality or usability.
FOSS programming tends to be largely recreational or a labor of love, and a lot of the discipline and organization required to make good software is not fun, and will be actively avoided in recreational projects, especially for people who do the "not fun" parts of projects in their day job.
A really successful project has to have someone (or several someones) at its head who can organize everyone and keep things moving in the right direction. Part of this is being willing and able to say "no" even if it means someone may walk away from the project.
If you want to produce really, really good open source software, provide a stipend for the programmers so they don't need to keep day jobs and pay market rate for a small number of managers with the skill to organize, the charisma to get agreement from the team, and the knowledge of when to tell people "no".
I disagree with these broad strokes you're stating as universal facts, but I do agree that everyone should have access to some kind of UBI/stipend. That'd be awesome.
Recent security incidents have shown how quick open-source is to address vulnerabilities compared to closed source.
It has shown that FOSS does not come w/o a cost (open-source does not mean free) and it's advantageous and necessary for companies to support FOSS financially.
> Even more recently, researchers discovered two "critical" security flaws actively being exploited in Mozilla's open-source Firefox browser. Additionally, the open-source Linux operating system was just hit in "its most high-severity vulnerability in years."
OK, but these security flaws are ubiquitous in closed source software as well. The difference in FOSS is the source is there for people to look at and scan for security bugs if wanted, and is there for people to patch when needed as well.
Closed source has these problems as well, it is all just less public.
Almost all devs that care too much about their work burns out eventually. It is just FOSS devs have higher percentage of "caring too much about their work" syndrome, to the point doing it for free.
As someone that had similar issues, I would highly suggest everyone to view their job as job. You work on the time you were supposed to, do your best within your capabilities, raise issues when you see them but that is all. Don't overwork and try not to worry so much when things are not going the way you want them to be. You can still enjoy your work, just try not to have personal attachment to it.
But I guess that is harder for FOSS devs, since the reason they work is being too attached to their projects.
OSS developers perceived some value to be gained by them, at some point they seem to be disillusioned by the outcome or don't want to pay the cost of further investment beyond what they put (and got back) thus far.
This just seems natural and could be followed by one of either
1. productise OSS project and start making money from it
2. allow other top maintainer to take the lead
3. work at some BigCo where they can afford to pay full time working on this OSS project, if that makes sense
There is at least a project aiming at specifying a protocol (and at developing associated tools) defining how developers can be paid, in order to let users support what they use (even through dependencies) according to their will and without too much of a burden.
No, it can't. More contributions require more maintainer effort, not less, if you want the project to follow a design and pursue a goal, rather than be a kitchen sink.
Yeah… no. I’m working on a pretty important project at my job that needs to be done well and as fast as possible without sacrificing quality. I’m writing code solo because I know exactly what I need to write and having to keep a second person in line would use so much time and energy, I wouldn’t get work done.
Don’t worry about the bus factor, other people know what I’m doing and I have a backup who can take over. Might delay the project a month or two, but the company can manage without me.
I maintained a project like this for several years. My genuine advice to anyone considering creating an open-source library: either keep it super small forever, or make it closed-source + charge for licenses.
Web3 is said to change this and incentivize development and maintenance of protocols and commons. There is a recent piece at decrypt suggesting that this creates another form of 'community'. Any opinions?
Join (from the part of the developer) idealistic goals, rose tinted glasses, naiveté, with (from the part of the users/contributors) lack of respect, lack of project visibility, lack of tact in dealing with OSS maintainers, sometimes lack of technical prowess and too much initiative, and the environment is set for conflict.
If you give away your work for free and then complain and act all surprised/hurt when nobody pays you in return then you are the problem. Not the people using your work. Accept it and move on. Or make people pay for your work. It's that simple.
Personally, I don’t really sympathize with the “sabotage” stuff. To me, that’s just immature. Nobody can stop you from quitting out, archiving or deleting repos, etc. but choosing the route of trying to use your influence to try to cause harm is not helpful to anyone and only serves to mess up your reputation (and to a degree, the reputation of all of us maintaining open source projects.)
I am yet again still annoyed by how the “problem” here is portrayed. Open source doesn’t need to be “sustainable” for anything in particular. I like open source because I can work on anything I want, and other interested parties can join. I also work for money, and in that case, I don’t get to work on whatever I want to.
The problem of internet entitlement is also not unique to open source devs. I’m sure I am not the only one here who has ran internet communities of various sorts, and that, too, can be quite rough. Possibly even worse sometimes.
I do sympathize with people who can’t mentally deal with the stress, because after all, people are only human and I think they have only good intentions at heart. But if you are feeling overwhelmed by your successful projects, I think it may be necessary to step back and make sure you’re still in it for the right reasons.
Because big tech companies depend on open source, it is often seen as a problem that open source code is mostly unfunded… but frankly, that only matters if you care about the fate of the tech companies more than the open source communities. I say fuck it; Google can fork whatever project if it goes unmaintained. I wouldn’t really want my project to be controlled or influenced by Google, Facebook or Microsoft, but if they get no such influence, exactly what incentive do they have to support the original maintainers instead of forking it for themselves?
> again still annoyed by how the “problem” here is portrayed. Open source doesn’t need to be “sustainable” for anything in particular. I like open source because I can work on anything I want, and other interested parties can join. I also work for money, and in that case, I don’t get to work on whatever I want to.
Everyone's different. Some people paint as a hobby. Some people are full-time artists and want to be full-time artists so they get paid and make money doing what they want basically. Even full-time artists have got to deal with gallery owners, other artists in exhibitions, marketing publications, buyers, patrons and grant money.
Somehow the way that open source works where it's never just what you want because you got a whole lot of ideas, inspiration, requests from other people so I don't think the traditional models of patronage or sponsorship are going to work for all cases.
And some people like yourself they're not going to be relevant at all because you just like to work on what you want as a hobby and don't care if you get paid for it and that's perfectly fine but there's plenty of other people who will be choosing to be full-time professional creators and I think that's wonderful and I just don't think there's the right options for them to monetize that at this time.
I don’t consider this to be giving up control; I use open source projects from corporations by choice, mostly due to their merits. This is a mutual thing.
On the other hand, having a big corp take over the direction of something I’m writing for fun to fit their needs is a totally different ball game.
After all, many developers also use Windows or macOS, and that can have an impact, too. But for the most part, it’s inconsequential.
The way I see it, open source is not different from freeware in this sort of way. If you release something out to the world under some set of terms, then you shouldn’t be surprised when people adhere to those terms. You also aren’t owed anything for being nice or giving people gifts. If you really care about getting a return on your investment, then I can only say that open source is a strategically shitty choice.
Open source gives me the rare opportunity to work on stuff I actually care about, with other people who also happen to care about those things. Mutual benefit. For corporations that release software, it’s not really about autonomy, but it is still about mutual benefit; Facebook was even honest with this, mentioning that a reason for opening up React was to help make it more general and mature, and help flush out idiosyncrasies that plague the design.
I wonder if this will be expanded to 'open' content as well, i.e. people sabotaging their previously free content in order to steer people to paid content
Eh, what, this is not a kitchen. This is a hobby project, a child-toy-kitchen, some people seem to mistaken a a career. Patch is welcome and if you want software work for free, fork it and do your own work on it.
Is that really the outcome we want? That large companies fork all the OSS they need and take control away from the maintainers? Because it's what is going to happen if we don't build an alternative where maintainers have a proper career path.
They're in control of the license from the very start. Anyone who doesn't want that doesn't need to use a license that is so open.
I like most others' careers has been deeply enriched by open source, but I find it hard to have sympathy for anyone releasing under a very open license and then pulling a pikachu face when their project is used within the boundaries of how it is offered.
This same discussion has previously devolved to 'well projects with non-liberal licenses don't tend to get traction', the answer to which is there's a false assumption here that every oss project should trend towards adoption. That should never be the primary goal and is one of the main pillars of why the entire ecosystem is becoming dysfunctional.
As I understood, this is how apache httpd started. NCSA had publicly released httpd, and people wrote all kinds of patches for it. After a while, someone made the effort to combine and organize all these patches, creating what he called a patchy httpd, hence the name apache httpd.
If you intend to make things other people will use and come to depend on, you cannot have this attitude toward open source. Stop thinking in terms of hobbys and toys. You are still building serious software for mass market distribution, you just have an alternative funding model.
OMG - another one for the annals of ridiculous feminist claims:
"The free nature of open source also leads to inequity. Open source is dominated by men, and people who don't have as much leisure time or stability might be less likely to contribute to open source when there's no compensation involved."
So an article lamenting the horrible lives of FOSS open source developers who work for almost nothing then turns around and blames the same OS developers for driving women out of tech by working for free.
Never mind that women tend to be paid by their husbands, so they would have lots of spare time for FOSS development.
Both what you quote and what you said are both asinine: I've met a lot of female FOSS developers, several of them have worked their ways into management positions at major companies. The era of pretending FOSS is a sausage party is over, and the use of this as a talking point needs to end.
https://web.archive.org/web/20220320083930/https://www.busin...