Superbloom

Photograph of a table with a piece of checked paper and a beaded wristband with the initials P T F. Above the wristband is the word ANALOG in blue overlaid by the word DIGITAL in blue.

They have an idea. They have programming skills. And now they have 182 days to create a prototype. This is the Prototype Fund, a German government program to support open-source projects. Superbloom has been providing support for the teams on “everything but code” since 2018 – from UX design to fundraising and everything in between. This blog post is for Prototype Fund teams, and really, it’s for anyone hoping to do a lot on a development project in a short time. Here’s how you make the most of 182 days!

We’ve written this blog post for Prototype Fund teams, or really for anyone who’s working on an early-stage tech project. We’ve assumed you have expertise in the technical nuts and bolts. What we can help you with is… well, everything else. We’re experts in many different areas adjacent to civic, open-source, and nonprofit tech, and we specialize in providing you with just enough expertise to get you going in the right direction.

Here’s our perspective on how each project needs to focus its efforts and create a good flow. It’s a non-exhaustive list, and our intention is to create talking points for teams, and ideas for coaching sessions with us where we can dig into some of these topics more. Here we go!

Usability testing

Identify and resolve usability issues early! You’re the wrong person to find the usability hiccups with your project – everything makes sense to you, after all – but minor issues can cause major problems, making it harder for others to find, download, or use your project. Getting feedback is easy and often even fun, and becomes easier the more you do it. 

  1. Test opportunistically and often: Testing is part of a process, not a last step. In fact, if you wait to test until the end, we guarantee you will wish you’d done it earlier. We like to store results on a digital whiteboard, such as Miro or Excalidraw so you can cluster similar feedback from different tests, even if they’re weeks or months apart. 
  2. Start with your friends: Some people worry about finding testers who are an exact demographic match for the target user group, or about reaching the correct sample group size. These are valid concerns, but they should not stop you from testing! A small “hey, could you try to make a meeting on this app” with a friend beats testing too late in your process. 
  3. Testing without code: You can test even if you do not have any running code. You can use paper prototypes, boxes-and-lines mockups, or code that just shows UI with no real data behind it. 
  4. Testing with code: Once you do have code, aim to reach a point where you run all relevant parts of the software together instead of just single bits. It helps with both testing code and usability since you always have a running version of your software. 

Suggested reading and resources:

Branding and identity

At first glance, “brand” might sound like something a nonprofit or civic tech project needs to prioritize. The word “branding” carries the connotation of advertising, selling, and competing in the marketplace, which may not match your project or goals. But at its core, branding is about making clear who you are (and who you aren’t), something every project can use. Even a no-frills, minimalist approach to a consistent look and feel goes a long way to help others recognize, understand, and be able to talk about your work. 

  1. Focus on consistency, not uniqueness. It’s hard, and becoming harder, to come up with groundbreaking brand elements that nobody has used before. Of course, you don’t want people to confuse you with other projects, and straight up copying others leaves you open to legal threats. But if a tea house in Yorkshire has the same name as your ad-blocking browser extension, nobody is realistically going to be confused. The same goes for colors, illustrations, and typography. 

  2. Test brand elements in context: It’s far easier to judge whether a name, logo, or other building block is working well when you mock it up in the exact place you’re going to use it. Practice saying “you should check out [name] on GitHub.” Write a “lorem ipsum” website and tweak the colors and images before you try writing a real blog post. Photoshop your logo onto a picture of a laptop to see how it works as a sticker.

  3. Rely on libraries and helper tools: Especially if you’re not confident with visual communication, take advantage of the many libraries and tools out there that can help you create a professional, consistent look and feel quickly. 

  4. It’s not just how you look, it’s how you speak: Branding and identity aren’t only about the parts you see (such as the visuals, name, and tagline). Branding and identity are also about how you speak to your users and community (also called “voice”), what you stand for, and your values. For example, if you’re trying to make a complex and intimidating process accessible to beginners, your voice should be friendly, approachable, and encouraging. If you’re writing a more advanced library or API, your voice should probably be knowledgeable, clear, and collegial

  5. The smallest bits are the most challenging: Creating a logo and deciding on a name are actually some of the hardest parts of creating a branding and identity. These building blocks need to do a lot of work in a small space, so a lot of work is needed from concept to finished design. Don’t be afraid to ask for help (for example, from us).

Suggested resources:

Technical infrastructure and code

We’ve put together a short list of some of our top tips for early ideas and tech prototypes for technical builds.

  1. Work on creating a running version early on: An early version is also great for obtaining early feedback from users via user testing! Most importantly, make sure different parts of your system will work together, even if they just pass hard-coded mock data. A simple method to plan and collaborate on running software is the tracer bullet method described in The Pragmatic Programmer and Ship It!.
  2. Avoid building from scratch: Make use of existing open source software and tools instead of building everything from scratch.
  3. Avoid elaborate development methods or complex tools if possible: These were often designed and developed for work for big companies, and we find it’s best to keep it simple.
  4. Use tools that you and your team are already familiar with, even those others may see as boring: For example, e-mail, chat groups and office programs are not cool, but often do the job well. Java, Python, JSON, and Object Oriented Programming are not particularly exciting, but have plenty of documentation and best practices. It is important to be able to collaborate and work efficiently and this works best if you build on knowledge and skills you already have.

Suggested reading: 

Organization and management

Being organized is a sure way to set yourself up for success in short turnaround projects. We’ve made a list of recommendations:

  1. Communication: Rules, tickets/issues and meetings may seem useless - and this is certainly sometimes the case - but very often they help a team to work better. A lot of organizing is about communicating in a way that people have a shared understanding of what they need to do now and what they want to achieve next. What may seem like mere bureaucracy can help with that. 
  2. Todo list: There are many organization and project management methods. The basic version is a shared, prioritized list. Important things are listed at the top, and project teams pick things from the top. There are many free todo list apps and project management tools such as Notion, Monday etc.
  3. Make tasks clear and actionable: Vague tasks such as “Make software more usable” or “Clean up code” are never completed on a todo list. Move tasks like this to another place eg “Values” or “General ideas to consider”. Tasks should be self contained and it should be easy to decide if and when they are to be actioned.
  4. Winning: To feel like you’re winning, at the end of each working day, make a list of the three things you want to achieve/complete the following day (big or small), and do those three things before you do anything else the following work day. 
  5. Be specific: If you find yourself making lists of lots of issues, try to find a format that you can repeat. We like: “User story/what should happen/what happens now/notes”. This helps to remember information that is important later. “Fix FooBarManager: Crash condition” might make sense now, but in a few days’ time, you may not remember what those notes were for.
  6. Standups: Have a regular (ideally daily) project team standup meeting where you briefly say what you did, what you want to do and what you need help with. No discussions or explanations; just a quick update for all. After the standup you can collaboratively decide what you want to hear more about, or what you want to discuss together.

Fundraising and sustainability

Thinking and planning for a fundraising and sustainability strategy in OSS often begins with a series of decisions:

  • How much do you and your users/maintainers want to diversify funding streams? 
  • What does sustainability really mean to your OSS project and your users? 
  • What values does our OSS uphold when it comes to financial sustainability and fundraising matters, and how might we govern difficult decisions?
  • Should we search out grants, corporate sponsorships, membership fees, tenders, individual donations, or similar?
  • Are we putting all our eggs in one basket, or should we explore a few different options to stay secure?
  • Should we be a non-profit, foundation, or something else that fits our funding goals?
  • Besides money, what else do we need, for example: maintainers, infrastructure, hardware or volunteers to keep things running smoothly?
  • Are we ready to pivot or tweak our strategy if our/the situation changes?

Considering these questions as discussion points is a good place to start, followed by finding out what other stakeholders think, and what they need will help you better define a strategy. 

Now you have your list, we’ve put together our top seven fundraising and sustainability tips:

  1. Legal and compliance considerations: Make sure your OSS project is set-up to legally accept funds, whether as a non-profit, foundation, or another type of entity. Be aware of any tax issues, licensing concerns, or legal rules that could affect your fundraising and sustainability plans. Don’t forget that the legal structure you choose for your company will affect the kinds of funding you can go after in the future. Not every company type can accept all kinds of funding, so think carefully about how your setup matches with potential grants, donations, or investments.
  2. Networking and follow-up: Maintain relationships with the people and funders you meet. Stay in touch via emails, professional networks, or however works best. Don’t just take their business card and leave it at that. Keep them in the loop about your project’s progress and any cool new updates. By regularly reaching out and making them feel like part of your community, you’re more likely to keep them engaged and supportive.
  3. Value proposition for funders: Your value proposition/vision may take time to become clear to you, but once it does, it will be a powerful tool in securing funding. A solid value proposition connects your project’s goals with what funders care about, helping them see why they should support you. It also keeps your fundraising efforts aligned with your company’s values and long-term vision.
  4. Diverse funding sources and risk mitigation: Look into different funding sources to avoid relying too much on just one eg individual donations, corporate sponsorships, grants, tenders, or selling services. It’s also a good idea to have a backup plan in case funding streams dry up or the economy takes a downward turn.
  5. In-kind contributions and non-financial support: Remember to encourage and recognize non-financial support such as hardware e.g. donated server space or volunteer developer hours. These kinds of contributions are super important for keeping your OSS project going and should be part of your strategy. A rainy day fund is also important for good financial health.
  6. Diversification of funding streams: Consider all the different ways of diversifying your funding streams such as one-time vs. recurring donations, or revenue from related services or products and membership fees. Each type of funding plays a key role in keeping your project sustainable.
  7. Create a sustainability plan/roadmap: Having a roadmap of what you would like to be funded, and the approximate labor or infrastructure costs to support that is key. Make these fundraising goals public in your OSS codebase as this can make it easier for funders to assess and find projects to fund. Also, consider what beyond financial funding would be needed in order to keep the project operational in various scenarios. For example, if your project would need 2-3 maintainers with specific programming skills in order to assess and merge pull requests, your sustainability plan would outline who is needed and how.

Community building

Community building is a broad and far-reaching topic, and summarizing how to build a community is often over-generalized. Here are are how-to’s:

  1. Understand what your community expects of you and what you expect in return: As the OSS project and the maintainers of the OSS project, being clear, honest, and communicative about these expectations is always beneficial. Understanding your community’s expectations can be done by utilizing GitHub’s discussions/issues, forums, chat services and email feedback.
  2. Ask yourself why you need a community?: Yes, community is important for sustainability, but community building and engagement is a lot of work for a small project team. And sometimes the time isn’t right. Evaluate whether building and engaging with a community is right for you.
  3. Build documentation and processes: Once expectations have been communicated and set, you can begin to build documentation and processes that meet and expand on these expectations. For example, ensure your readme document is clear, informative and descriptive beyond the installation or functions of your OSS project work. Making sure you have a readme in Human Readable Code ensures that people of all skill levels, entry points and interests can participate. Human Readable Code, as referenced in the linked article is a great practice across issues, pull requests and the code base itself.
  4. Create contributing documents: Moving on to create dedicated contributing documents per function contribution (e.g. design-contributing.md, documentation-contributing.md etc.) sends a clear signal to your community that you value contributions beyond code. These are actions that subtly promote inclusion and diversity in your OSS Project.
  5. Create a roadmap: Write a short guide for you and your team to set up your community. Include your aims: who is your community, where will you find them, how will you engage with them, what are you offering them, how often will you engage with them, what you are hoping to gain from them etc.
  6. Making your community self-supporting: Once you’ve begun to grow community participation, you can consider what it means to have the community support, promote and grow itself, so that it becomes a self-supporting function of the OSS project. This is a long-term goal – it’s unlikely you will accomplish this in your first 182 days.

Networking?

Networking may not seem like a priority, or very important, and tends to be downplayed as something rather unserious or not valued. It’s also about making new connections, such as:

  • Superbloom coaches who themselves might be well-connected to the open source or civic tech world.
  • The Prototype Fund team, who through their work in the last few years have met a lot of different people and are well-connected (and might have pointers about other ways to support a project financially).
  • People with similar interests who may be interested in supporting your work financially or contributing.

There are a lot of myths surrounding networking. You don’t have to be an “extrovert” to network and it doesn’t just happen at events. It also doesn’t have to be exhausting! Connecting with fellow projects informally for inspiration and camaraderie often happens online as well as offline. If you do want to attend events:

  1. Be present: Be present in the spaces (physical or otherwise) you enjoy and want to be involved in will allow people to remember you and remember your work. 
  2. Present your ideas: Present your ideas and work at relevant conferences as this allows you to learn about people working on similar topics/projects. 
  3. Be visible: Be part of relevant physical and digital space, which will help people think of you as part of a particular community. These can also act as “multipliers” by sharing your work, or connecting you to similar people (“hey, you’re working on X, you should meet Y who is working on Z, as there is some overlap”).

There’s lots of overlap between networking and usability testing (see above); networking is full of opportunities to seek and receive feedback throughout the whole development process. If nothing else, connecting with others can be a powerful motivator to be told that what you’re working on is exactly what someone else needs, wants to see, or always hoped would be developed. You’re on the right track!

What next?

We hope you enjoyed reading our perspective about how to make the most of 182 days to work on your prototype! There’s a lot to keep track of, but there are many people out there - including us - in the open source and nonprofit tech community excited, and able to help and support you.

If you’d like more customized advice, we’d love to talk to you. If you’re a Prototype Fund team, good news – this is already covered for you. Get in touch!: [email protected].

Credits

Blog post contributors: Rocío Armillas Tiseyra, Tori Boeck, Victory Brown, Jan Dittrich, Eriol Fox, Laura Gaetano, Nicola Pratt, Saptak Sengupta, Molly Wilson.

With thanks to the Prototype Fund, a Berlin based program of the Open Knowledge Foundation Deutschland dedicated to supporting public interest tech.