How Can Governments Pay Open Source Maintainers?

When I worked for the UK Government I was once asked if we could find a way to pay for all the Open Source Software we were using. It is a surprisingly hard problem and I want to talk about some of the issues we faced.

The UK Government publishes a lot of Open Source code - nearly everything developed in-house by the state is available under an OSI Approved licence. The UK is generally pretty relaxed about people, companies, and states re-using its code. There's no desire and little capability to monetise what has been developed with public money so it becomes public code.

What about the Open Source that UK Government uses?

The state uses big projects like WordPress, as well as moderately popular NPM packages, and small Python libraries and everything in between. But can it pay the maintainers of that software?

A version of this blog post was originally published on Hackernoon.

Fixing The Plumbing

Open Source is facing a crisis. The code that the world relies on is often developed by underpaid engineers on the brink of burn-out. While I don't think anyone wants Open Source to have a paywall, it seems obvious that large organisation should pay their way and not rely solely on volunteer labour.

Here are some of the problems I faced when trying to get the UK Government to pay for OSS and how you as a maintainer can help make it easier for large organisations to pay you.

Firstly, lots of OSS doesn't have a well defined owner; so who gets the money?

I'm not saying that every little library you create needs to be published by a registered company, nor am I suggesting that you should remove your anonymity. But Governments and other organisations need to know who they are funding and where the money is going. The danger of accidentally funnelling money to a sanctioned state or person is just too big a risk for most organisations.

If you want to receive funding - make it really clear who you are.

What Can You Offer?

Even when there is an owner, there often isn't an easy mechanism for paying people. Donation sites like GitHub Sponsors, Ko-Fi, and Patreon are great for individuals who want to throw a small amount of money to creators but they can be problematic for larger organisations. Many OSS projects get around this by offering support contracts. It makes it much easier for an organisation to justify their spend because they're no longer donating to something which can be obtained for free; they're paying for a service.

This doesn't have to be a contract offering a 24/7 response and guaranteed SLA. It can be as simple as offering best-effort email support.

The important thing is to offer an easy way for a larger organisation to buy your services. Many organisations have corporate credit cards for lower-cost discretionary spending which doesn't require a full business-case. How easily could a manager buy a £500 support contact from your site?

Maintainers don't only have to offer support contracts. Many choose to offer training packages which are a good way to raise money and get more people using your product. Some project maintainers will speak at your conference for a suitable fee.

Again, the aim here is for maintainers to offer a plausible reason for a payment to be made.

Playing Well With Others

Open Source has a brilliant culture of allowing multiple (often anonymous) contributors. That's fine when there's no money involved, but how does a moderately sized project decide who receives what share of the funding? Services like OpenCollective can make it easier to show where the money is going but it is better to discuss in advance with all contributors what they expect as a share.

If people think they're being taken advantage of, or that a project maintainer is unjustly enriching themselves, it can cause arguments. Be very clear to contributors what the funding is for and whether they're entitled to any of it.

Finally, we faced the issue that some OSS projects didn't want to take money from the "big bad state". They were worried that if people saw "Sponsored by the Government" they would assume that there were backdoors for spies, or that the developer might give in to pressure to add unwanted features. This (usually) isn't the case but it is easy to see why having a single large organisation as the main donor could give the impression of impropriety.

The best defence against this is to have lot of paying sponsors! Having the state as one of many partners makes it clear that a project isn't beholden to any one customer.

It isn't impossible to get Governments to spend on Open Source. But state spending is heavily scrutinised and, bluntly, they aren't set up to pay ad hoc amounts to non-suppliers, who aren't charging money. While large projects often have the resources to apply for Government grants and contracts, smaller projects rarely have the time or expertise. It is critical that maintainers remove the barriers which make it too hard for organisations to pay them.

In Summary

• Make it easy for Governments and other large organisations to pay you.
• Be as obvious as possible that you are able to accept payments from them.
• Don't be afraid to put a large price on your talents.
• Offer multiple paid-for options like speaker fees, support, and feature development funding.
• Talk with your contributors to let them know how any funding will be shared.

Featured Krita artist: Syn27

https://krita-artists.org/t/gato-al-aire-libre-wet-paint/169092

#krita #DigitalArt #DigitalPainting #MastoArt

Now I'm curious how the data looks for us nerds over here on the fediverse: where do you register your domains?

If at multiple places, let's interpret this as if you were registering a domain today, where would you register it?

tackily if you don't mind boosting I'd actually like a lot of data on this I'm really curious!

yay lihzahrd can now successfully write valid Terraria worlds, not just read them!

#Terraria

Sometimes, just for fun, you have to actually use your shit and feel proud of yourself.

Other @collabora folks are preparing for a demo at an upcoming trade show. They're going to do an NVK demo at the booth again and this year we decided to demo some games. (Last year was some WebGPU demos running in Chrome.) So I installed Jedi: Fallen Order and fired it up.

At first, it was kind janky. It was playable but you wouldn't want to play like that for hours. Then I realized it was running at 4K. At FHD, it was a buttery smooth 60 FPS. At max settings. On a laptop! Honestly, the fact that I could keep 4K above 20FPS on a laptop GPU was pretty surprising.

So, yeah, I spent a chunk of the afternoon being a Jedi. Got to make sure the demo is good and stable! 😂

The Vulkan Working Group has published, Building a Simple Game Engine, a new in-depth tutorial for developers ready to move beyond the basics and into professional-grade engine development.

Learn more: https://www.khronos.org/blog/new-vulkan-game-engine-tutorial-build-your-own-production-ready-rendering-engine?utm_medium=social&utm_source=fosstodon&utm_campaign=game_engine&=
#vulkan #tutorial #programming #gpu #gameengine

i built an entire x86 CPU emulator in CSS (no javascript)

you can write programs in C, compile them to x86 machine code with GCC, and run them inside CSS

https://lyra.horse/x86css/

This is truly glorious #AISlop from #Microslop in their "Introduction to Github" course.

I don't know why Tim is working in the opposite direction, but I can see that he never once "morges" his code back into develop, let alone doing it "continvoucly"

https://learn.microsoft.com/en-us/training/modules/introduction-to-github/3-components-of-github-flow

Update:

It looks as though after 4-5 months the page has been updated, but if you want to see the image in situ still then the way back machine has you covered.

https://web.archive.org/web/20260216165612/https://learn.microsoft.com/en-us/training/modules/introduction-to-github/3-components-of-github-flow