I wanted to get involved in open source. It was important to me to do open‑source work that provides value.
I didn’t want to create my own open‑source project from scratch, because I had already tried that and knew how difficult it is. I was interested solving design problems at the “hard” level, not at the “nightmarish” one.
I wanted to help an open‑source project that would have an impact.
After many months of looking for the perfect open‑source project, while working on Open Source Design 500, I came across Maputnik—a map editor.
There was something intriguing about the maps. I thought I would be happy to learn more about them. I decided to help Maputnik.
Among the so‑called “issues” on GitHub, I didn’t see anything that could serve as good material for a case study in a designer’s portfolio.
The action plan
The action plan was standard:
- Build trust.
- Identify a design problem worth solving.
- Solve the problem.
- Document the event.
1. Building trust
As part of the trust‑building process, I designed and coded solutions to several issues related to the user interface.
I fixed one bug unrelated to the UI to prove to myself and the Maputnik team that I understood how the software code worked.
I tried to solve an issue I couldn’t handle. A good lesson in humility.
Whenever there was a need to test something, I actively tested it. I know the value of a second pair of eyes.
After a dozen weeks of activity, I received an email from GitHub. “Lukas Martinelli added you to the Maputnik team admin.” Lukas is the creator of Maputnik. He co‑opted me into the project administration. I couldn’t imagine better proof of trust.
2. Identifying a design problem worth solving
I reached out to the project maintainer. I asked him, among others, about the history of Maputnik and the directions he plans to take the project in.
The Maputnik team, like many other teams creating software, didn’t have any contact with users. There were no analytics in the application because that would have required a legal entity to process the data. If the user was not tech‑savvy enough to create an account on GitHub, find Maputnik there, and create the so‑called “issue”, there was no chance for them to be heard.
I didn’t manage to negotiate the integration of analytics into the application. I managed to negotiate the conducting of a survey, which will be promoted inside the application.
Good surveys are hard to design. I devoted a lot of time to preparing the Maputnik survey as professionally as possible. I even enlisted the help of the best researcher I know—Bartek Dzudzewicz. I meticulously translated the questions I prepared into English and commissioned their revision to Alyssa, my editor from Canada. I configured the free version of Typeform to the best of my ability. Then I consulted the people working on Maputnik about the design of the survey.
More than 100 people have filled out the survey. 29 have left their email address. I translated the responses and my email exchanges with respondents into issues and comments on GitHub. Maputnik’s maintainer is satisfied with the results. I wrote a post for the Maputnik blog to celebrate the survey’s 100th response.
Finding a large, measurable problem in an open‑source project is more difficult than I expected. I can’t do it in Maputnik, so this survey ends my involvement in the project, and I’m looking for an open‑source initiative where I can find a large, measurable design problem to solve.