Work in progress: Using FOSS at Prototype Fund

It all started with this post and our transition from Slack to Rocket.Chat. As the Prototype Fund was about to begin its fifth funding round, our first step towards using more FOSS tools was to set up our first self-hosted chat instance. A couple of months later, in a second post, the importance of avoiding rushed decisions and building structures slowly was emphasised, as was our plan to set up our own Nextcloud instance.

Move slowly and do things properly

So, what has happened in all these years? Does the Prototype Fund now exclusively use FOSS tools? Of course not. As wonderful as the idea sounds, unfortunately there are many constraints that make giving up proprietary tools entirely impractical. However, we are slowly taking step after step in the right direction.

Why so slow? Firstly, it's because we're not working alone. The Prototype Fund is the result of collaboration with various stakeholders behind the scenes. We work with agencies that require us to open Excel spreadsheets with macros (the kind that still break with LibreOffice), printers with specific requirements that Inkscape cannot yet fulfil, and coaching companies that have their own existing infrastructure which works well for them. We are also part of the much larger Open Knowledge Foundation Germany, which, like us, works towards more FOSS, albeit at a slower pace due to its size - and we still want to be able to work with our colleagues from other teams within our shared infrastructure.

Secondly, moving infrastructure is a lengthy and arduous process. It incurs costs in terms of time and energy (and often money). This is particularly true when a decision affects not only our team and processes, but also the people we fund. Moving to a new tool or platform means getting our grantees and alumni to join us on it. Even if the new platform is better, everyone has to set up new accounts and learn to use it, which can be a big ask. Some people will inevitably give up and lose access to the community.

Last but not least: because we needed time to focus on other things, such as supporting the projects we fund and securing funds for future rounds. Going FOSS can't always be the top priority.

Tools, tools, tools

So, where are we now? Which FOSS tools has the Prototype Fund started using, and how do they work?

Nextcloud

Back in 2019, we announced our intention to move to Nextcloud, and that's exactly what we did! It was a self-hosted instance that wasn't very powerful or reliable. However, we didn't give up, and when the Open Knowledge Foundation moved to a managed Nextcloud a couple of years ago, we joined them. No more Google Docs at Prototype Fund!

Zulip / Stackspin / HedgeDoc

Goodbye, Rocket.Chat; hello, Zulip! After struggling with Rocket.Chat for a couple of years, we decided to give up on it. However, we didn't return to Slack. Instead, we took the advice of our colleagues from Jugend Hackt and set up a Zulip instance. This gave us the chance to use Stackspin, a suite of projects that we funded, which includes not only Zulip but also a HedgeDoc instance that we use for shared notes.

Hypha

This one is a bit more niche, but funders need application platforms, and few of these are open source. In 2023, we stopped using the proprietary platform that we had relied on since the creation of the Prototype Fund and started using our own instance of Hypha, an application and funding management tool developed by the Open Technology Fund. Although it isn't fully tailored to our needs (yet), we plan to contribute a few features to the project that will hopefully improve Hypha for us and other funders, in keeping with the FOSS spirit.

Craft CMS

We've just launched a new website! While our previous WordPress site wasn't based on a proprietary tool, and Craft CMS is not fully Open Source, we're thrilled to be taking it a step further by making the code of our website available on GitHub. We‘ve written about that here.

Pretix

We funded this project and are excited to use it! Pretix has eliminated the need to collect registrations for our events via email — it works like a charm!

BigBlueButton, MediaWiki, Openbookstack, LimeSurvey, EasyAppointments

These are the classic tools of the self-hosted FOSS world that we need and use for making calls, sharing information with our grantees, publishing a knowledge base about FOSS, conducting surveys, and arranging appointments.

...and of course, all the things we don't think about, but which we use every day on our laptops: LibreOffice, Inkscape, Octosuite, Atrain, Ubuntu... We're probably forgetting many of them!

Learnings: the good, the bad and the ugly

In the hope that they will help other teams and organisations, here are the key things we have learned from previous years.

The good: these things work and have been very helpful.

• The power of the community! Don't just jump on the first FOSS alternative to a tool you're trying to replace. Ask the people around you which tools they use, how they use them and what their experience using them has been like. And if possible, ask to have a look at their instance of that tool!
• Work with experts: Self-hosting is a good option if you have the necessary in-house capacity and knowledge, but few small organisations have the resources to self-host all the tools they need. Fortunately, there are excellent hosting companies out there that are committed to privacy, FOSS and everything that matters to us. We love working with Cloud68 and Greenhost, for example. Not having to worry about updates is a luxury we've really enjoyed.

The bad: we wish we had avoided these mistakes.

• Too many tools: the wonderful world of FOSS has so much to offer that it's easy to get carried away exploring and want to try everything. Playing with new FOSS tools can certainly be a fun hobby if you have the time, but if yours is limited, focus on the essentials. You probably don't need several video conferencing tools. And will you really use that Kanban board, that shiny alternative to Notion, and that new Etherpad instance?
• Tools that are not ready: It takes time for software to mature, work reliably and prove that it won't let you down when the developer loses interest. While new tools can sound exciting, if you're looking for something to use regularly, look for tools that have been around for a while, have a good track record of releasing regular, well-tested updates, and have a solid community around them. Bonus points if you can trust that the tool won't suddenly pull one of these "hello we're open core now" moves where the features you love and need are suddenly not FOSS anymore.
• Quick moves: Transitioning to new infrastructure takes time. While setting up and migrating data are obvious tasks, your team then needs time to familiarise themselves with the tool and experiment with the settings. This is particularly relevant for publicly accessible instances. Believe us when we say that launching a public application phase while figuring out how to use our new platform is the closest thing to flying a plane while fixing it that we've ever experienced.

The ugly: never again!

• Don't make the mistake of setting up, announcing and getting users for a tool without first checking whether it's right for your team/project. You'll end up struggling with it for years before giving up and doing it all again with a similar new tool. Been there, done that.

Bonus learning: easier said than done.

The simplest approach would be to use FOSS tools from the outset when building an organisation. However, this is easier said than done, as new organisations rarely have the necessary resources to invest time, money and energy in carefully planned infrastructure. Things generally evolve organically, based on whatever is easiest and cheapest to use. Technologies also evolve quickly — Nextcloud, for example, was created in the same summer as the Prototype Fund, and its predecessor would not have met all the needs of our young organisation at that time. But if you have the opportunity to keep an eye on it, when setting up a new organisation, try to integrate FOSS tools into your processes from the outset wherever possible, as this will make things easier further down the line.