FOSS & Funding

Having joined the SFML community somewhen in 2010/2011, became part of the SFML Team (i.e. a maintainer) in 2014, and just recently been appointed to BDFL this year, I do feel like having some insights of what it takes to run a FOSS project, even if our scale is still relatively small.

From this point of view, I want to share some thoughts on funding and sponsorship of FOSS (Free and Open Source Software) projects, especially in light of the events from the beginning of August regarding Moq and SponsorLink.

The Recap

Feel free to skip this part if you closely followed the discussions around Moq as they happened. If you’re not following the .NET news or general internet tech drama, then here’s a recap for you.

At the beginning of August the discussion originally started on Reddit and then quickly spilled over to GitHub, with two issues currently sitting at 393 and 727 comments respectively.

The active maintainer of Moq, a .NET mocking framework, going by the nickname kzu is looking for ways to finance people working on open source software (OSS). That’s why he created SponsorLink and started to slowly introduce it in a couple of his smaller projects and then eventually into Moq, which averages around 103K downloads per day. The mechanism that SponserLink used to help get more GitHub sponsors were two-fold:

1. During the build, the user’s git config --get user.email is fetched, hashed and sent to an Azure Blob storage. If the user has previously installed the SponsorLink app on GitHub and they are sponsoring the relevant user/project, nothing will happen.
2. If sponsorship however couldn’t be confirmed and the build is running in an IDE, a build warning will be generated and as a bonus, the build will be paused for a second or two.

There’s no opt-in, no opt-out, the user doesn’t get informed about this, nor gets to consent to it. The SponsorLink library was closed-source and obfuscated, to “prevent the development of workarounds”.

Sending out hashed user email addresses, pausing builds, and potentially failing builds when “Treat Warnings as Errors” is enabled, unsurprisingly, and in my opinion justifiably so, caused an up-roar. Nobody wants code analyzers to make web calls, regardless of what information is sent, and nobody wants breaking or pausing builds.

While I hear a lot of people vouch for kzu and his intentions, it saddens me to see the refusal to not only accept, but admit his mistakes or shortsightedness, and instead see snarky comments and gaslighting. Don’t just read the two linked comments though, because there were also good discussions going on and some self-reflection of his own world view.

The good news is, that the latest version of Moq doesn’t reference SponsorLink, the bad news is, that kzu is determined to bring it back in some form, even if he agreed to not use a web call with your hashed email address.

The Expectation

In the past, I’ve written a bit out open source work and funding during the log4j debacle, and I had many discussions with colleagues and friends, when this post from the corejs maintainer made the rounds. I’ve also already posted some of my points on the Fediverse.

kzu’s intention of trying to get the attention of FOSS users in hopes of them sponsoring those projects is certainly a noble one. It’s a fact that multi-million and multi-billion dollar companies are massively profiting from free software. Be it Linux hosting most web servers, or .NET running a lot of enterprise software, or JavaScript libraries being used on basically all websites. It’s also a fact that all these thousands of companies, very rarely donate any monetary or time investments to those FOSS projects.

While these facts are true, I push back heavily on any arguments that try to turn this upside-down and claim something along the line of:

Because companies make millions of profits with the use of FOSS, we as maintainers of FOSS are entitled to some of their profit.

No! If you give away something for free, you can’t start demanding payment, when someone else starts making a profit with your gifted thing. It’s nice/wholesome/the-right-thing-to-do when you do get a kickback from a company or user, but by no means does it give you any entitlement whatsoever.

The Work

The arguments then often switch to the amount of work people put into these projects for free. Following all the demands and providing all those fixes as fast as possible. As a maintainer of SFML, I can certainly tell you that the work is not always seen, or properly appreciated, and I’m lucky (or unlucky?), that we aren’t getting company requests or demands.

Sadly, for all those arguing about the time investment and provided work, all I can say is: It’s your personally decision on what you’re spending time on. No company and no super-duper high priority issue physically forces you to spend more time on your FOSS project. Maybe you risk getting your project tagged as vulnerable, or having some package deleted. Maybe you loose some big name companies as users. Maybe your “competition” reaches feature-parity or starts being more innovative. Maybe people write angry posts on blogs and social media.

You will have social pressure and mental fights, but it’s wrong to blame the users of your free software, that they don’t start to support you (financially) for all the invested effort.

The Licensing

I’m a big fan of permissive licenses, as they rarely put a limit on the re-usability of the work. If I for example create something with an MIT licensed library, the library’s license doesn’t limit the possibilities of my own work. I really like nothings’ approach with the stb files and release most of my code dual licensed under either the Public Domain (Unlicense) or the MIT License.

Yet, it seems people don’t understand the impact of the chosen license, or only want the benefits of permissive licenses. A license such as MIT or zlib or BSD allows users to do pretty much whatever they want with the provided software, except claiming that they created it, and as such gives away your hard work for free, not just as in free beer, but also free as in freedom (though there are long discussions to be had about this).

If you don’t want to give away your code for free to everyone to do whatever they want with it, then the license is the first place you can and should codify your intentions. This is where I feel a lot of people embrace a double standard of wanting to profit from the potentially free popularity and word-of-mouth propaganda (“use this, it’s free!”), and yet expect big companies to pay for their software.

In case you want to stop large companies dead in their tracks, just switch your MIT project to a GPL one, and within days you’ll see forks pop up and companies quickly removing your software. Unfortunately, you’ll also lose a lot of other devs, who can’t justify the virality of GPL, and who don’t want to release their own projects under GPL.

I’m no expert on the license front and don’t really want to make specific recommendations, however there are projects that are successfully walking the line between being open source, but also cashing in on large companies using their tooling.

Choose your license wisely!

The Community

Patreon, GitHub Sponsors, and many other platforms show that crowdsourcing funds for your work can be a viable option. While kzu also set up GitHub Sponsors, he in my opinion didn’t understand (like so many indie devs) that getting crowdfunding requires a personal investment into the crowd, i.e. a community. It’s not enough to just write some posts on your personal blog or expect people to just jump on your created PRs and issues, you need to actively do community building.

Setup a forum, Discord server, social media account, sub-reddit, or however else you want to reach out and get people of a specific library or topic interested. Spend time there, engage with the people, new and experienced users, give moderation power to trusted and experienced people, do live streams, review code of others, create special and exclusive content, etc. etc.

Yes, I’d guess that building a community for an established testing library is much harder, since a large group of people just know how to use the library and see no need in engaging with a community, but it’s simple, if you don’t provide a place to gather as community, you won’t get a crowd and you won’t get sustainable crowdfunding.

Side note for the indie game devs: If you’re working on a game, but don’t have at least a core group of community members, you have to start now. The game market is tough, you won’t just magically get the interest of people, if you don’t invest into gathering the people!

The Funding

One critical question to ask at this point is, whether Free and Open Source Software (FOSS) and funding can really exist on the same level? As already said, I won’t go down the rabbit-hole of free as in freedom and all the philosophy behind that topic, and yet I do think we should be careful with calling software FOSS, when it starts mixing with commercial offerings.

If your product is only free up to a certain point or company size, I believe it’s misleading to mark it as FOSS, maybe OSS (Open Source Software) is still okay. This however is really a thin line to walk, since I do think dual-licensing your software is a valid path to take. You can provide a left-copy (e.g. GPL) license, keeping the software fully free and open source, while offering a commercial license on the side.

If your product offering keeps some core components closed-source, I honestly cannot call your project OSS anymore. Meaning, if you want to keep the OSS status, you cannot have commercial plugins/modules of core functionality, without which the overall product would effectively become unusable.

What you cannot avoid when setting up a commercial offering is additional effort on administrative/corporate work. You’ll need to do invoices, ensure taxes are paid, respond to some extend to customers, ensure everything is legally sound, etc.

In some of the GitHub discussions kzu says that he wants to avoid exactly this kind of work. In my opinion this is the main disconnect from reality kzu and others thinking in similar vain are having. We are living in a capitalistic economy. There are only very few who get to just work on what they absolutely love, with all their freedom on creativity, and who get paid for doing so. Neither SponsorLink nor any other demanded visibility feature from Microsoft will call that utopia into existence.

I’ve heard a lot of those “there are other ways”, but no concrete examples that don’t involve me setting up some kind of business around it. I just want to do OSS and code all day. I don’t care much for negotiating support contracts with corporations and generating invoices and the like.

kzu

Among other reasons it’s not surprising that companies are formed to reduce the administrative burden, so developers can focus much more on writing software.

To reiterate here’s a non-exhaustive list of potential ways to commercialize your open source work, all of which will have a certain corporate overhead:

• A custom license that requires (large) companies to pay a fee
• A separate commercial license for (large) companies
• Provide support as a paid-only service
• Provide additional features as private & commercial packages
• Only the newest version/features requires a commercial license
• Have people pay for requested features
• Change feature priority depending on the monetary investment
• …

The Response

Some days after the explosion of discussions, when things had cooled down a bit, kzu wrote another blog post reflecting on the “feedback”. I recommend reading it, as the next paragraphs are somewhat direct responses.

As much as I admire the effort to somehow help the OSS community in getting more funding, I can’t help but disagree with a lot of this opinions and views.

No, it’s absolutely not enough to think that writing some blog posts and merging a PR within 20min of creating it, is all the community engagement needed to introduce SponsorLink to a library utilized by thousands of people and projects. In German we have the two terms “Bringschuld” and “Holschuld” denoting that it’s debt that the creditor is obligated to deliver, respectively that the the debt needs to be collected by the creditor. Community involvement isn’t a “Holschuld”, but a “Bringschuld”, you as the maintainer have to reach out to (formerly) active contributors and start a discussion with them. Don’t just expect them to show up, because you’ve written a blog post on a completely separate platform and have linked it in some release notes.

The number one issue of SponsorLink is really not the method used. Yes, it’s a glaring oversight that sending around hashed email addresses is a privacy nightmare to unfold, but that’s just the icing on the cake. The issue is the one of trust and trust was, again, not broken because of the hashing method used, but because there was no discourse. There was no proper communication and informing of the users, and finally, there was no opt-out. All this doesn’t mean, that all that was needed was a better communication, no that means that proper communication would have yielded a massive pushback, which would’ve never supported the introduction of SponsorLink.

Many of the other underlying points in the response, I believe to have covered in the areas above already.

The Conclusion

Funding of software development is a tough spot and I haven’t even mentioned venture capital investments, but I’m convinced, if you put in the work either in building a community or in doing administrative work, you can successfully finance your open source work. You’ll unlikely get rich and working for any software company will likely yield a (much) high income, but maybe there’s a balance to be had?

I personally write open source software, because it’s fun to share work in the open and with SFML I’ve seen many young people and students get into C++ and game dev with the help of SFML and its community, which wouldn’t otherwise be possible with a commercial project. It fills me with joy being able to help someone and knowing that SFML might have just been their introduction to a whole new world of software development.

As for Moq, on our project we’ve replaced with with NSubstitute by now and noticed that NSubstitute makes some code more readable, but I don’t think that’s the only way forward. The trust towards kzu certainly remains broken, so it’s up to every maintainer to decide, whether the risk of sticking with Moq is worth it for them.

I wish kzu all the best on his quest for funding FOSS projects, and hope he can one day recognize his mistakes and provide a proper, well overdue apology to the user base of his projects.