A red thread in multitudes: What we learned while funding Diversity
In October 2018, the third cohort of the Prototype Fund officially concluded their funding period. With the third round, we put a focus on “Diversity” in a multitude of narratives and meanings and we still marvel at the variety of projects, people and ideas the topic attracted.
Our jury selected 23 projects, covering different aspects of diversity, from both a technical and social perspective. In respect to technology, diversity could mean distributed systems, self-hosting solutions or simply a broader diversity of actors providing technical infrastructure. In social terminology, we define diversity as a variety of backgrounds of people contributing as part of a team, diverse target groups and projects fostering (technological) diversity in communities, industries or societies- or decentralisation.
This blogpost, written by Fiona Krakenbürger, former lead programme manager, provides insights on the things we learned during interviewing and supervising our third funding cohort.
Teamwork: It’s meetwork
Approximately half of the projects of the third cohort have been developed in and by teams, some of which have been newly formed just before becoming grantees. At times team members had to grow into the role of a team lead without prior experience. This initiated both challenges but also a steep learning curve in the teams’ development.
The imponderables of collaboration were just as important to consider as the choice of technical layout. Building the foundations for working together at an early stage enabled the teams to start coding immediately and reduced blockers along the way.
Challenges the teams addressed have been: How are we going to communicate? How often should we synch our tasks and progress? What is a common timeline, what other responsibilities do we have to cater to?
Many projects conveyed that in-person-meetings were incredibly important and effective, let alone for the rubber duck effect. One project was following the pair programming approach for the entire funding period of 6 months, which according to them resulted in better code and a high learning curve for both team members.
A high frequency of meetings and updates were generally presented as a key to success for the projects.
As funders we learned that we need to prime the grantees as soon as possible on the upcoming challenges as a team and that it requires well-crafted toolset and and mode for collaboration before the funding phase starts. Besides money, being able to providing locations for team meetings and teamwork is an important resource, as is advice on modern and successful teamwork techniques.
Top advice: The team of “Diversity Ticket” had a shared daily diary in which each team member documented their work and open issues for the day. It facilitated the exchange of thoughts between the team members and the monitoring of milestones.
Sustainability
The sustainability of funded projects remains a hot topic with the Prototype Fund. How can we establish structures that enable OS projects to continue after the funding period? How can we implement stewardship in the initiation of FOSS projects, given that there is an increasing dependence on this decisions for the endurance of services?
Here are some suggestions on how to approach this goal:
Write the Docs
Yes, your code is open. But is it accessible? There is a difference between code that is simply released to the public and code that is fit for redeployment. Therefore, good documentation is paramount and should be an important part of every OS project. Include proper documentation in your project management plan!
The beginning is the end is the beginning
Both projects and funders should have the endpoint of the funding period in mind when sketching out a roadmap for the project. Where will you stand one month, three months and six months after the conclusion of active funding? How do you ensure that users have an up-to-date and deployable product over the course of time? Will you look for further funding resources? Consider that the time between writing a proposal and receiving the first grant can easily take up to a year. How will you bridge this time? Include these questions into your project planning at an early stage, ideally before you even start. The end of a funding phase, however, is definitely too late to be asking these questions for the first time.
Community Relationship Goals
At the core of a sustainable open source project lies a healthy, active and resilient community. A community can be a consisting of a number of contributors or a group of people that have a mutual sense of belonging to a framework, a language or a software project, either by developing, maintaining or using it.
Whether there exists a stable community around a project or not will be an important factor of any project’s long term impact and sustainability. Hence it makes sense to consider ways of building and fostering a community at an early stage of development.
Potential contributors can be found by serendipity in the mentioned above respective communities surrounding technologies, languages or topics or they might have to be explicitly invited to partake.
I just recently visited and appreciated the “Open Source Diversity” meetup, where dev teams pitched their projects and thus met potential contributors. One of the funded projects of cohort 3, “drip”, was presenting, networked with and onboarded contributors.
Other ways to find and build a community are regular update blogposts or organizing user testing events, asking for feedback. Most important, a community needs to be acknowledged and involved.
Planning is everything – the plan alone means nothing
Now that we have talked about planning processes so much – what do they actually entail? Of course maps and layouts in any capacity are of utter importance, but what is even more important is reiterating them on a regular basis.
In other words: Make plans, make them early, try to consider as much as you can, but be aware of the unknown unknowns. Even the most experienced developers come across unforeseen obstacles and they learn about new abberatios of technologies they are using, which will force them to twist their original plans.
Stay agile and realistic, adapt your plans to your actual progress. Be bold in setting your goals, but also don’t hesitate to adjust these goals if necessary.
Many projects reported that they have been underestimating the time ressources it takes to write clean and reliable code. Implementing new features often had to be neglected for the sake of revisiting and refactoring existing code. While building something new is always more thrilling than improving existing code or DevOps, we still suggest our projects to plan with time for “the horrible redundant boring work of improving your code”, as Ben from EyeSkills put it.
TLDR; Providing highly motivated developers with financial support for six months is a great undertaking and might solve the issue of providing continous financial support for a given amount of time- but responsible funding entails so much more than this. After several rounds of PTF we understand better what they need and how we can amplify our support. We would like to express our gratitude to all projects that openly shared and continue to share their learnings and challenges with us.
