Resources for Free Software
Part 2 – Funding & Sustainability
Every project lives in a unique environment of contributors, users and other stakeholders.
A typical mistake that we see when projects apply for financial support is a focus purely on technical matters. We advise projects to think about its environment and “soft” goals, like growth in the number of external contributors, user support, design discussions, documentation and other tasks that should be taken into account in your description of work (if only in the number of hours you plan to have available).
All these aspects are not “overhead” and don’t have to happen on the side, these are essential parts of your work! It is useful to read best practices documents such as the Best Practices Badge by the Core Infrastructure Initiative with this in mind. Which of these apply to your project, and in what order? How can you best include them in your planning?
Financial sources usually do care about the bigger picture, and want to see secondary aspects taken into account when you describe milestones and goals. It is a big misunderstanding that developers feel they are asked to have the design nailed down already to accurately describe achievable goals. We’ve seen too many applications where way too much time has been spent (unpaid) on the preparation of the funding application, and we see way too many canceled proposals because developers lack the time to (in their eyes) accurately describe what the project wants to do next.
In general, this is not the expectation when funding sources ask for a plan. It makes your life easier to merely describe the current state of the project and what needs to happen next. These “next steps” very likely include more detailed planning and refinement of (later) milestones, but nobody expects you to already have an exact list of tasks already in place, with the discussions and prototyping already done. On the contrary, as you well know things will change faster than you think, and you might later feel compelled to stick to your original plan as described (in too much low level detail) at the beginning. This creates unhappiness, and don’t we all be happy? (This leads to a second typical mistake, which we will cover later in this document.)
We are not aware of much good material that helps with such planning, but found “Software Estimation: Demystifying the Black Art: The Black Art Demystified[1]” by Steve McConnell a good entry point and recommend at least browsing the first hundred pages of it.
Regardless of who you want to help with your project, and whether that requested help is financial or not, taking a step back to think of a high level roadmap can be very useful (and that in itself should be a proposed activity when you apply for funding!).
If your goal is to attract more developers, why not propose relevant activities that help you achieve this goal, instead of strict development tasks? Depending on the funding source, it might make everyone’s life easier to propose a number of hackathons and suggest to fund travel for contributors.
With that in mind, think of such activities as time well spent on improving the long-term sustainability. And time well spent should be equally valued (and paid for!) as development hours…
Planning and Change of Plans
“Life is what happens to you while you’re busy making other plans.”
Another very typical mistake that we see projects do is to try too hard to stick to whatever plan was agreed upon. With many funding entities a successful proposal leads to scary legal language in a contract or grant agreement, and regardless of how often your contact person tells you otherwise, it is only natural to feel bound to what you agreed upon. Especially if it is based on what you came up yourself in the first place, the idiot You of a year ago.
This is wrong! In your planning, take into account the constant change of plans, and communicate changes early. A sign of a failing project is that it did not get in touch about changes, only to fail at the end. We’ve seen too many reports delayed and delayed again because projects are too afraid to tell us that they didn’t make it. Don’t be one of those projects. This advice is relevant regardless of what your funding source is. Your contact person is there to assist and your project was picked because someone believes in it. Changes are expected, even if the language of the contract suggests otherwise.
Sources of Funding
Think of “funding sources” as allies, not merely as money dispensaries. Even if a foundation cannot provide financial support for your project directly, they might be happy to connect you to someone who can help.
Nadia Eghbal maintains a nice overview of different ways to find financial support in her “Lemonade Stand" document: GitHub - nayafia/lemonade-stand: A handy guide to financial support for open source.
NLnet has a more detailed list of alternative funding sources for FOSS projects: NLnet; Alternative funding sources
Renewable Freedom Foundation maintains a broader list of foundations interested in digital human rights topics: Digital Rights Funding Sources – Renewable Freedom Foundation
ISBN13: 9780735605350 ↩︎