In a previous article, we discussed why, when developing our open source libraries, we emphasize growing our overall users – not just our contributors. We elaborated on why we focus on everyone who uses our software to solve a problem, as opposed to following the more traditional open source practice of catering specifically to code contributors.
But we cannot stop at defining our focus – we have to put it into practice. In this article, we'll share some practical strategies we have learned in the course of adopting this more user-centric mindset.
We have come to these strategies by regularly interacting with the users who have adopted the SDV ecosystem, and we've iterated them until we found success. (Some of our libraries are already at 1 million downloads!) This has given us confidence in our approach, which we're excited to share below.
1. Find the right channels to reach more users
Our first strategy involves our overall presence as an open source ecosystem.
Shifting our focus to users has allowed us to think more critically about who we are trying to help, and whether we are actually reaching them. For example, we were initially prioritizing checking and responding to questions on GitHub, a platform that makes it easy to reference technical material and scrutinize bugs.
But GitHub caters primarily to contributors – and thus leaves out the rest of the users we'd like to reach. In fact, those users may not have GitHub accounts at all! They are more likely to feel at home when they can ask us questions directly, working with us to improve their understanding. They often don't have the time to dig through technical discussions, or the desire to create an issue on GitHub, especially if their question is more fundamental. (Since “issue creation” has always been defined as a part of the software development lifecycle, users may not feel comfortable asking more basic questions there.)
To find the users we wanted, we decided to expand our presence to other platforms that cater to their needs. We have found Slack to be a great solution – it is welcoming and easy to use, and enables direct communication. Today, our Slack is a fast-growing community of over 800 members, and a new space for us to learn about how people use our software.
2. Users are just as important as contributors
Our attitude towards users matters just as much as their ability to find us.
As the core maintainers for an open source project, we all have a deep passion for software. It is natural for us to want our users to share this passion – and also natural to perceive a lack of initiative if a user hasn't understood certain concepts. But in our drive to recognize the importance of all users, we have learned to understand — and even embrace — that many users have different needs and time pressures than we are used to.
For example, we frequently receive questions about how to upload a CSV file into Python. This is a standard data science procedure, so some might label this question as "lazy." We don't believe that's true. In fact, these users may be picking up Python for the first time because they think our software could solve their problem, which shows a lot of initiative. They are not unqualified to use our library; they might just need a helping hand.
To figure out what will actually help users, we put ourselves in their shoes. This mindset has led to some of our current best practices:
- Empathize with the user's pain points. Working on software openly means that we'll get more feedback more often. Often, an issue identified by a user may already be on our roadmap, is inspiring internal debates, or is on hold until we have more resources. When we're reminded of such an issue, it can be easy to get defensive and engage in a debate – which ultimately wastes everyone's time. Instead, we use the opportunity to build camaraderie. We always try to replicate users' issues, which helps us acknowledge the frustration because we feel it too. No software is perfect!
- Focus on the problem, not the solution. Because our users do not have our domain expertise, they'll sometimes request features that seem difficult to accommodate. When this happens, we remind ourselves that it's not the user's job to understand our system. Rather, it's our duty to dig deeper and find the root of the concern. This helps us design new features in a way that matches our vision and satisfies users.
- Above all else, move them forward. When a user has a request, we aim to provide a timely, focused response so that they can take the next step in their usage journey. If we can't immediately resolve the issue, we provide workarounds that allow their projects to proceed. This is more difficult than it seems. At times, we want to passionately respond with our own long-term vision — but this is not useful to users who just want their project to work.
The illustration below shows a hypothetical example of using these best practices.
These best practices reflect our overall attitude, which elevates users to the same level of importance as open source contributors.
3. Go the extra mile – it only takes a few minutes!
Going above and beyond can mean creating special material for users and learning to speak their language. By now, it has become standard practice for us to disambiguate and translate our technical communications for a more general audience.
Our SDV ecosystem is filled with examples of conveying the same information in multiple ways. Below are some excerpts from our announcement of a new version of SDV (0.16.0) in July 2022.
The SDV open source contributors are familiar with technical concepts like “unify sampling params for reject sampling” or “Add create_custom_constraint factory method”. They're also interested in following along with specific GitHub issues, which link to the code changes.
Meanwhile, user-centric communication focuses on the pain points that we've solved. This is informative for current users and welcoming for new ones. As a result, users coming to our library for the first time can scan through the Slack channel to see what we're working on. Best of all, because we're thinking in these different ways already, it only takes a few minutes to draft these different types of announcements!
Conclusion
Adopting a user-centric mindset has significantly contributed to our open source growth. We started by identifying users and finding the right channels to reach them, which naturally expanded our open source presence. Then we learned to empathize with users and embrace their needs, which has manifested as more productive conversations and relationships. Finally, we always think it's great to go above and beyond – especially if it only takes a few minutes!
Are there any strategies we've missed? Let us know what you think in the comments below!
