OSS funding (on Redis et al)

There is a current brouhaha about RedisLabs effectively making some Redis modules nonfree. This has turned into the usual debate on realistic ways to fund open source, which y’all are obviously very familiar with, having been a recurring topic ever since the LUGRadio / early Ubuntu days.

As I wrote in this post, I think it’s high time for the Big Repos to start being proactive collectors for the projects that effectively created (and still drive) their business. My modest proposal (not ironic as Swift’s, but still somewhat outlandish at the moment) is that they should raise download paywalls, basically forcing businesses to pay their fair share; this money should then go to the projects almost entirely (e.g. 90-10 split, with 10 going to Github/Gitlab/Bitbucket to fund ongoing development of the feature).

With the right fee structure, I reckon this would be popular among maintainers and users alike, and would generate significant amounts of money.

What do you guys think? To be honest, I’m more interested in finding novel ways for OSS to raise money than in bashing the latest company having the gall to ask to be fairly compensated for their work (although tbh their choice of license was somewhat disingenuous, and was communicated very badly indeed).

And now you have to put infrastructure in place to allow people to pay for their access without interruption, and to pay for people to support the payments infrastructure, deal with the inevitable chargebacks, etc etc.

GitHub/GitLab/BitBucket already have teams in place to look after all that. Most projects already have significant commercial resources looking after their distribution channels (Ubuntu, npm, etc). The few extra resources needed would be pennies on the dollar, with massive scalability.

This may be an unpopular opinion (I don’t like coming to this conclusion, being a programmer), but I wonder if the problem with payment might sort of boil down to not making the distinction between a project and a product.

(I also reserve the right to look back on saying this years later and regret being such a jackass, like all the time I spent in and out of college complaining about the evils of the GPL…)

That is, there are a lot of software packages that expect me to realize I need them, find them, figure out how to download and configure them, and deal with any issues that aren’t bugs I’m willing to submit a patch for. I don’t object to them and use many. However, when they pitch a fit because users are saying mean things on Twitter, we want to treat them like a business that has done marketing, QA, and documentation, even though they’re not, and try to figure out who should be the middle-man to make their work profitable, though a lot of us seem to prefer the euphemism “sustainable.”

But there’s no “value proposition” for someone who’s walking in, and it’s a lot of effort to use the software, so expecting financial support on top of that seems…entitled, in the same way that people seem entitled when they complain about “wasting” their lives at a day job when they “could be” writing the Great American Novel. They both seem to want the revenue from having been successful without putting in the (make no mistake, extreme) effort to create a polished product.

I donate to a select few teams, so I’m not suggesting that hobbyists don’t deserve support until they can ship a shrinkwrapped box. But I am suggesting that there’s a world of difference between scratch-your-own-itch code that “goes viral,” commoditize-your-complements code launched by big companies or other well-funded organizations, and code where the team/community has gone to the trouble of making the user’s experience pleasant. It might be worth helping projects make the distinction, rather than assuming that a random new user (who may not have disposable income, for any number of reasons) should risk money on a no-name project. That’s not to mention the code that’s in use by many large companies, but none of them can spare a dime, so we home users are asked to front them until they find their wallets…

There’s a part of me that also wonders if license figures anywhere in this. For example, I wouldn’t be inclined to give money to many projects under non-copyleft licenses, because I may be indirectly subsidizing a project like macOS or LibreOffice. The former (FreeBSD or LLVM) feels like being conned and the latter (OpenOffice) might as well go to the project that’s actually in use.

That’s all to say that I’m not sure I have an answer, but hopefully there’s something in here that can help move the discussion forward instead of in the same cycle. I mean, a lot of this discussion reminds me a lot of the Interactive Fiction community, where talking about building a business (at least, back in the '90s) pointed out that, because the group that’s willing to pay for text-based games overlaps significantly with the group that’s willing to write them, they’d just be passing the same five dollar bills in a circle. Some free/open source software can have a much larger “customer base,” but a lot don’t.

This might be true in some cases (the umpteenth media player or feed reader…), but it’s definately not the case with something like Redis, OpenSSL, or PyPy – all very high-profile products of great quality, that have made commercial efforts to various degrees at one point or another, and simply require significant resources to keep going in the face of massive freeloading from businesses of all sizes.

Absolutely, but it’s unpopular to point it out. That’s why funding was never an issue for PyQt - double-licensed GPL/commercial, “keeping honest business honest”. If more projects went that way, accepting somewhat-reduced popularity in exchange for long-term sustainability, we’d see less begging. But here we are.

Developers want to be popular, and businesses want to get something for nothing - it’s just their nature, in both cases. It’s up to the infrastructure in between, I think, to figure out a way to save both actors from themselves. The third category (desktop users) is so small that it’s practically irrelevant, as distribution after distribution has discovered with any new “app portal” scheme.

definately not the case with something like Redis, OpenSSL, or PyPy – all very high-profile products of great quality, that have made commercial efforts to various degrees at one point or another

I may have chosen too loaded a term with “product.” What I mean by the term (in this context) is more that the team thinks of their work as a thing that they’re “selling” (maybe for free). That includes the marketing (messaging, market segmentation, value propositions, outreach, etc.), the design (brand, website, UI, API…), the documentation and onboarding, contextual examples, quality assurance, support, and everything else that someone considered when you buy a pair of pants, let alone enterprise software.

Like I said, I need to figure out that I have this specific problem, then guess the industry jargon that lets me search for other people with the problem, then find the tools that solve the problem, then evaluate them, then figure out how to set the winner(s) up and hope the documentation is sufficiently precise, accurate, and up-to-date that I can solve my problem. I’ve worked for some hilariously crappy companies, but none of them would ever let a product out the door where the customer needs to come find them. Compare OpenSSL to something like Kubernetes where, sure, they’re commoditize-your-complements territory and OpenSSL isn’t, but they’re everywhere they can be to find the people who need them and make sure they’re able to get moving.

A more head-to-head comparison might be Linux distributions. Apart from the big-two (RedHat and Ubuntu), only CentOS, Trisquel (of all things), and to a lesser extent elementary OS seem, on a very quick review, to have considered the possibility that visitors aren’t already experts who know what they’re looking for, so they’re what I’d call the “products.” Everything else is very project-y, where you can thrill to the latest release notes or getting the subscription information for the mailing list. Seriously, check out Trisquel’s website; they could stand to do some outreach and the interface design stinks to high heaven, but when I say “product,” that attention to convincing people to be interested is exactly what I mean.

It’s a huge, multidisciplinary ask, of course, but so is asking for people to fund you in a market with effectively infinite competition and people/companies who might be willing to do the same work without asking for money in return, for whatever altruistic/sleazy reasons might be involved. But I don’t think that the free/open source community can play the “we’re just programmers doing this in our free time” game when it comes to things they/we don’t feel like working on, but ask that we (by “we,” I mean rank-and-file users, not monopolistic corporations) pay them to do just parts of the job they enjoy so that someone with infinite money can use their work for free.

And the unpopularity of the licensing issue, honestly, might be a big part of why I’m so stingy on this front. If a team makes a big deal about their license of choice being “freer” than the GPL, I’m very unsympathetic when some large company forks their code off behind a paywall without any compensation. If the goal is popularity, that’s how popularity works. And there’s a related reason that so many famous actors burn out.

Now I kind of wonder what it’d take to overcome the long-term attacks on the GPL and similar licenses. I note that, in the non-software space, things have gone too far in the other direction, with too many people slapping non-commercial licenses on their work instead of realizing that the copyleft clause is more than enough to handle what they mean by “non-commercial.” Like, what’s the optimal ratio of Eric Raymond to Cory Doctorow to…not Richard Stallman, since nobody listens to him, but…Bradley Kuhn, maybe? And if that ratio is fixed, how does that change the calculus of people and companies supporting software they use.

Please respect our code of conduct which is simple: don't be a dick.