Slashdot Mirror
How Should Open Source Development Be Subsidized? (techcrunch.com)
"Open source maintainers are exhausted and rarely paid," writes TechCrunch's editorial manager. "A new generation wants to change the economics."
An anonymous reader quotes their report: [Patreon] is increasingly being used by notable open source contributors as a way to connect with fans and sustain their work... For those who hit it big, the revenues can be outsized. Evan You, who created the popular JavaScript frontend library Vue.js, has reached $15,206 in monthly earnings ($182,472 a year) from 231 patrons... While Patreon is one direct approach for generating revenues from users, another one is to offer dual licenses, one free and one commercial... Companies care about proper licensing, and that becomes the leverage to gain revenue while still maintaining the openness and spirit of open source software...
Tidelift is designed to offer assurances "around areas like security, licensing, and maintenance of software," CEO Donald Fischer explained... In addition, Tidelift handles the mundane tasks of setting up open source for commercialization such as handling licensing issues... Open Collective wants to open source the monetization of open source itself. Open Collective is a non-profit platform that provides tools to "collectives" to receive money while also offering mechanisms to allow the members of those collectives to spend their money in a democratic and transparent way.
TechCrunch warns that "It's not just that people are free riding, it's often that they don't even realize it. Software engineers can easily forget just how much craftsmanship has gone into the open source code that powers the most basic of applications...
"If you work at a for-profit company, take the lead in finding a way to support the code that allows you to do your job so efficiently. The decentralization and volunteer spirit of the open source community needs exactly the same kind of decentralized spirit in every financial contributor. Sustainability is each of our jobs, every day."
An anonymous reader quotes their report: [Patreon] is increasingly being used by notable open source contributors as a way to connect with fans and sustain their work... For those who hit it big, the revenues can be outsized. Evan You, who created the popular JavaScript frontend library Vue.js, has reached $15,206 in monthly earnings ($182,472 a year) from 231 patrons... While Patreon is one direct approach for generating revenues from users, another one is to offer dual licenses, one free and one commercial... Companies care about proper licensing, and that becomes the leverage to gain revenue while still maintaining the openness and spirit of open source software...
Tidelift is designed to offer assurances "around areas like security, licensing, and maintenance of software," CEO Donald Fischer explained... In addition, Tidelift handles the mundane tasks of setting up open source for commercialization such as handling licensing issues... Open Collective wants to open source the monetization of open source itself. Open Collective is a non-profit platform that provides tools to "collectives" to receive money while also offering mechanisms to allow the members of those collectives to spend their money in a democratic and transparent way.
TechCrunch warns that "It's not just that people are free riding, it's often that they don't even realize it. Software engineers can easily forget just how much craftsmanship has gone into the open source code that powers the most basic of applications...
"If you work at a for-profit company, take the lead in finding a way to support the code that allows you to do your job so efficiently. The decentralization and volunteer spirit of the open source community needs exactly the same kind of decentralized spirit in every financial contributor. Sustainability is each of our jobs, every day."
I've spent several years being paid to do open-source development full-time. The Moodle project made it easy for my organization to contribute. In fact, that's mostly what the maintainers did - maintain the community and developer documentation, not write the code.
First, the software is modular. One can write a Moodle module without touching the rest of the code, or even understanding it. The Apache web server and Linux kernel are similarly modular, and I've been paid to write modules for both.
There are example modules of various types, and how to showing how to develop for Moodle.
There is a well-maintained forum, both user forum and developer forum.
Unit tests are included and easy to run.
Utility functions are included, so you don't have to know *how* Moodle does things, the internal functions, you just call "add block" and Moodle adds your block to page.
All of the messaging welcomes participation and contributions.
All of these things encourage business, government, and non-profit organizations to contribute - meaning paying their employees to contribute.
What Moodle didn't do was offer the ability to BUY Moodle directly from the people who run the project. You CAN sell GPL software. You just can't prevent other people from selling it under a different name. The government agency I worked for probably would have purchased it if they could have. Competing proprietary software sells for thousands of dollars per year, so $500/year, or $200/year, would have been seen as super cheap. Even though we could get the same product for free, I would have encouraged them to buy a copy, and I think they would have done so.
Moodle allows you to DONATE, but as a government agency we weren't allowed to just give away tax money. We WERE allowed to purchase software, and there was no law that we couldn't buy software if similar software is available for free.
You may not consider $182,472 a year hitting it big in your country but in a lot of places that would afford you pure luxury.
In places in the US that is true too. Where I am you can live comfortably and still save money with a quarter of that every year, anything more can pretty much go to luxuries.
I'd take that over money any day :)
[($)]
You doing that after work. On weekends. For the community.
Work in your free time so the programs you support do one thing and do it well.
*NO*. this is extremely dangerous advice, for certain classes / types of projects: those with extreme complexity. you're no doubt familiar with the adages and articles that have made the rounds here on slashdot: the ones about attention span (how it takes 20 minutes to recover from interruptions), about information retention (the "7 things in your head" myth), and so on.
an article that *hasn't* made its way onto here in the 15+ years i've been on slashdot is the difference between, and purpose of, electrical and chemical neuron memory. electrical is the short-term "immediate" memory. it's what you lose if you get hit on the head. chemical memory is long-term retrieval and it's much more difficult to access ("it's on the tip of my tongue", "just sleep on it", "author syndrome" and so on).
what happens is that things that you can't recall and those things you're not recalling regularly are swapped over during sleep. it's why you can remember things if you're working on them regularly, and why if you're struggling to remember something you can do so the next day (it's also why not getting decent sleep before exams is not a good idea).
you should by now have the basics of why i'm posting this, but it's worth explicitly writing: certain kinds of complex tasks, which require *significant* information retrieval and cross-referencing, as well as creativity *and* engineering, are just far too much for any human being on the planet to achieve without ***FULL TIME*** focus.
reverse-engineering is one such task. it literally took me six to eight weeks in some cases to find a single bit amongst hundreds of packet replays, that one bit being responsible for whether it was possible to proceed to the next packet or not. that was six to eight weeks FULL TIME at 12 to 14 hours a day.
and that resulted in me going into serious, serious debt... which i'm still paying back, over 12 years later! why? well... was any fucking fucking fucker paying me to do that work? was anyone fucking well giving me money to do that work? no they fucking well weren't. and when that work was released under GPLv2+ licenses, what did people do? they went "oo thank you very much, i'll have that, it saves my business an absolute fortune"... completely failing to reward or compensate me for that work. some other free software projects actually even blatantly copied my work (used it as a template) and failed to give credit so it's not even *known* that i did that work.
several people in high-profile projects - myself included - have not been properly compensated for our work, and gone into serious, serious debt as a result. the gentoo developer who ended up with USD $40,000 of credit-card debt and had to get a job with *microsoft* of all companies. the GPG developer who ended up with USD $10,000 of debt despite the fact the GPG is one of *the* most widely-used security programs around!
the only reason why certain critical software projects (openssl for example) actually started to get funded a few years back was because of shellshock, heartbleed and other serious vulnerabilities. companies started to realise that they were making an absolute fortune but were spongeing off of peoples' expertise and not properly paying them to be able to do the work to fix even basic security vulnerabilities.
so no. it is NOT the case that everything can be broken down into the unix maxim "do one thing and do it well". certain classes of engineering projects simply do not succeed until they have reached a particularly high level of internal complexity (DCOM is one extremely good example, i won't go into details like i have in the past).
to imply that *all* free software projects can be broken down into small tasks that can be done "in people's spare time" is to completely misunderstand software engineering and to do free software
Ok, you got past the clickbait ..... basically my answer is why should it be subsidized by anyone, UNLESS, they have a vested interest in seeing changes/core features added to whichever part of the software that they are particularly interested in ...... so the answer is .... the people working on the projects in their spare time for fun, do it as long as it's fun for them, and when it isn't, when it starts feeling like a job, either find someone that values your contributions and get them to pay you to work on it, or stop and do something else.
Myself, I enjoy prestige. I like that my name is in the kernel changelog.
I NEED money. I HAVE to eat, and my kid has to eat.
Prestige is nice, money is required. Given the choice between no money and lots of prestige, or the opposite, I'd take the money, so my kid can eat.
I was fortunate to be able to get paid to work on open-source for several years. I'd like to do that again, but due to changes related to globalization I don't think that's very likely to happen. Not for me at this point in my career.
Very early in my career, it occurred to me that if I wanted power, fame, and money, I should start with fame. Being very well known carries with it a degree of power - even Instagram models and other "social influencers" have the ability to influence others by being well-known. If you well-known for being very good at something, being an expert, that's more power - Stephen Hawking influenced a lot of people, and his opinions could sway others. Heck, even being really good at basketball set Dennis Rodman on a path to influencing international relations. Not deciding them, but influencing them. Once you have game and influence, it's not that hard to leverage those to get money. Especially if you're well known for being very good at something, people will pay you to do that thing - or write books about it. So fortunately you don't have to choose between prestige and money, long-term.
For people early in their careers, or stagnating, making significant contributions to open source can add some prestige to their resume, which can definitely lead to more money. Once or twice in interviews I've had the good fortune to be asked of I was familiar with certain software and been able to say I've helped write that software, I've contributed to it. Someone asked if I know LVM (a major part of the Linux storage stack), I mentioned that I'm the maintainer of the Linux::LVM Perl module. (Which needs a new maintainer, btw, and probably a rewrite to the API).
And beer!
How about freeing up some of that $7.5B?
That's what Microsoft paid for GitHub.
Oh shut up, you live in Taiwan, you need like 50 dollars a year to live there.
actually it's around USD $1200 a month ($400 for rent, and food for myself and my family is around $700, because things like butter cost around USD $3 for 250 grams, and a 1L bottle of milk is around USD $4). if i was in taipei city that would be around USD $3,000 or above, as rent there is about the same level as shenzhen, london and cambridge.
If we're talking about subsidizing software, why does it even have to be FOSS? If there's a more self sustaining way of producing software that helps people in a non-profit or even for profit manner, why not look to that instead?
We need the FOSS software because we have seen the risk of having things that we can't look into. Software companies put in spy systems like Microsoft Telemetry or the Android spyware Chinese manufacturers add to their phones. Governments insist on ways to break the cryptography and we can never see them without the source code.
Unfortunately, Microsoft, together collaborators like ESR, have convinced us that we don't need strong copyleft any more. It was copyleft which sustained Linux as a single cooperating project as the BSDs kept splitting every time someone found a commercial niche. FOSS developers who are doing it for altruistic reasons should always release under the strongest copyleft license they can and then only come down from that if they get enough money to more than compensate for the value of their software. It doesn't even matter if you keep the money (in which case others will see the idea and do more FOSS) or you give it to create more software. What matters is insisting that we always have an increasing pool of guaranteed available FOSS software.
Freeloaders - as in users - are fine. Freeloaders - as in developers - will always be a problem because they will suck away value from your project, often without even getting benefit themselves, just transferring money to VC bloodsuckers.
But one thing the FOSS community sometimes forgets is that creating software costs time and money, lots of it.
No it doesn't. This is something that the FOSS community explicitly acknowledges. The difference between Free and Proprietary software is that FOSS acknowledges that copying software doesn't cost money. The premise of TFA is flawed, because a lot of people are paid to develop FOSS, but they're not paid to produce copies of it. If someone wants a feature added to a FOSS program or library, then they can pay either the original author or someone else to develop it and that's how a huge amount of FOSS is funded. In contrast, in the proprietary off-the-shelf software world, someone pays to have a feature developed in the hope that they can charge money for copies of the software. This business model is problematic, because developing the software is expensive but copying it is trivial and so you need to rely on legal and technical protections to try to prevent people from doing the easy thing so that they will pay you for the expensive thing that you did for free.
Now, it would be nice to have an easier mechanism for 1,000 people to each pay for 1,000th of the cost of developing a new feature...
I am TheRaven on Soylent News
"...those entities that benefit the most from open source software - be they large commercial enterprises or government agencies - should be the ones to contribute the most."
In fact they do. The problem is that corporations are such pathological structures that they can't help themselves.
Some years ago, it came into fashion the term "coopetition": companies identify where are they really competing and what's just scaffolding (i.e.: infrastructure software) where they could cooperate instead.
They idea is sound, it's simply corporations are so toxic they can't develop on it themselves alone so they require another company to do that for themselves. I currently work for a big bank which, in turn, pays high bills for in-house Red Hat consultors. The biggest value those consultors bring to the table is that they talk to their colleagues that are doing exactly the same for other banks of the competition and share problems, tricks and solutions. If we were sane, we could do exactly the same and save the steep profit Red Hat is making out of it, but, you know, we just can't (I would probably be fired if tried to do what those Red Hat consultors are doing, and payed for doing).
If your code is so complex that you need significant amounts of work just to maintain it, you have done something wrong.
i replied to this already (and moderators reacted badly to plain simple facts and the detrimental consequences that had for my health and my family's well-being, so i'll have to repeat it again). certain classes of (desirable) technical designs / problems are simply not possible to implement in "simple" ways. you just can't. these include things like dynamic name-registration / publication / defending services (like nmbd and sadly zeroconf which is nearly identical to nmbd), NT Domains Interoperability, MSRPC, DCOM, Firefox, webkit, and pretty much absolutely anything and everything to do with cryptography.
anyone can *and has* written a web server, and anyone can and has written a web framework. modular, too, and damn good designs.
but things like the NT SpoolSS service took TWO YEARS to reverse-engineer. the network neighbourhood in samba for example took THREE years to implement correctly - that was with about 3 separate people working on it at different points.
Firefox is a particularly sad case, unfortunately, where even with money and funding they still didn't go far enough in the "complexity". if you recall that adage "must be as simple as possible but no simpler", Firefox's XPCOM was "based" around DCOM. DCOM is *extremely* well-designed and when you drop a dynamic programming language (like python) on top of DCOM it's absolutely unbelievable: so simple to use that absolutely nobody using it has any idea that there's been man-decades of work gone in behind it: everything "just works".
in DCOM there's something called co-classes. co-classes are like the dynamic run-time equivalent of c++ multiple-inheritance. even using c you can do "default parameters" by declaring two (or three, or four) near-identical functions, each slightly longer (one extra parameter), and declare a "co-class" that MERGES all those near-identical functions into one (new) interface.
Firefox failed to implement co-classes in XPCOM.
that resulted in some absolutely disastrous consequences. absolutely any and every change to the API resulted in a cascade of incompatibility for 3rd parties trying to use the XULRUNNER engine in their code. why did they change the API? because normally you would declare a new interface and co-class it. without co-classes you're completely f*****d, you *must* change the API, and that completely and utterly wrecks interoperability: it's not like gcc dynamic linking, the actual *interface* DISAPPEARS because it gets renumbered as part of the change.
am i painting a picture here that this sort of thing simply is too complex for a single person, part-time, to cope with? am i painting a picture that trying to SIMPLIFY something that should not have been simplified results in disastrous consequences? if so then i've managed to get the point across.
p.s. you can fund my current work here - http://liberapay.com/lkcl - that's a libre version of patreon.
"Are you kidding? Dairy isn't exactly a luxary - eating healthy isn't something you should expect people to give up"
What's healthy about eating dairy? It's a lousy way to get calcium or vitamin d, and literally only certain WASPs and their descendants have the gene for digesting dairy in adulthood. Don't get me wrong, I love butter, but I don't imagine that it's health food. Most of the world consumes very little dairy, all of it cultured.
Well, cultures that don't consume much dairy are generally shorter, less healthy and die earlier. And its absolutely the most efficient way to get calcium but seeing as you need calcium for your brain to function well, you might not realize it. I'm sure you think taking vitamins is the best way to get calcium but most of that calcium will get passed right through you as we are not evolved to digest pills. And you can't digest milk because you stopped drinking it at some point (probably before or during college) and when you do that for long periods of time, your body stops producing the protein that breaks down milk sugars which makes you lactose intolerant. While my body might keep making more of that protein longer, it is still your own fault that you can no longer digest milk (which is a basic food stuff for all humans since long before recorded history). Plenty of WASPy folks are lactose intolerant for the exact same reasons as you.
Also, fuck you for using open source software and then trying to deny the folks that built that software basic food stuffs. Seriously, fucking just kill yourself as if you can't even find it in your heart to think that those that are giving your free software libraries (that are often better than the ones your preferred vendor write) should have access to basic nutritional requirements. Maybe that milk isn't even for him and is for his niece. But then again, drinkypoo I've been here for years and remember some of your other posts. You've always been a piece of shit...
"Those that start by burning books, will end by burning men."
I started and have headed a large open source project for the last 10 years: (plug!) http://mooseframework.org/ (quick description: think open source COMSOL on steroids).
We have a few thousand users spread across the world... but only a fraction of them contribute monetarily back to the project. We are lucky though that we are based at a US national laboratory where we are able to use government programs in support of energy research to pay for our project.
Going open source was a measured decision that took at lot of time to come to. Ultimately, we decided that creating an open platform for science was better than trying to charge license fees... and instead of taking money from our users our model is to partner with them to write proposals for joint funding. That model is working out ok so far (some years better than others!).
However: we not only create an open source library... we rely on many as well. The two biggest ones that we use are libMesh ( http://libmesh.github.io/ ) and PETSc ( https://www.mcs.anl.gov/petsc/ ). In both cases we have paid for full-time developers on those libraries for pretty much the entirety of our project. Sometimes we ask them to complete certain tasks for us - but for the most part the money is given with minimal strings attached so they can maintain their software and continue to make it better (not just for us, but for everyone).
For some of the smaller libraries we use we often fund work at universities associated with those projects. Sometimes it's a small amount of money - but we try to give _something_.
Everyone that is making money (for-profit or non-profit) while using open-source software should try to fund the projects you directly rely on as much as possible. Like many other things: even a little bit goes a long way. Open-source has never meant "you should use it and not monetarily support it"... people need $ to keep going.