Matthew Rocklin

Non-Technical roles in OSS Software is more than code

Software projects require non-technical work to succeed. This post names and defines that work, using terms borrowed from industry.

This post follows on a previous post The Role of a Maintainer, which is more focused on the day-to-day technical operation of the project. While maintainers serve a critical and necessary role, technical maintenance alone is not sufficient for success.

Here we talk about the following non-technical roles:

  • Product Management
  • Project Management
  • Marketing
  • Sales
  • HR

But we connect these business terms to activities within community open source software.

Product Management

  • What new domains and applications should we target for greatest impact?
  • What features do we need to focus on in order to satisfy those those domains?

A maintainer keeps the project running, but where should that project go? Product management determines the direction of a project on a longer timescale. They work to understand the broader context in which the project exists, and identify opportunities within that context that would make the project more relevant.

Without product management we end up building neat software that may not have as much impact as we would like.

Project Management

  • Are we making steady progress towards our goals?
  • If not, what is blocking us, and how can we address those problems?
  • Do our users agree?

It’s easy for developers to go off-track.

  • We may choose to work on interesting problems rather than important ones
  • We may misunderstand what users need, and so waste time on technically correct, but pragmatically unfruitful paths
  • We may get distracted by life, and so projects may become abandoned

Project managers keeps things moving forward in productive directions. They listen to users and other stakeholders, and keep development focused on important issues. If something unexpected comes up and a developer has to stop work, they try to organize other developers to step in to maintain continuity.

Project management is hard in general, and particularly in OSS. Project managers need to have the technical ability to make good decisions and earn the respect of developers. They also need to have enough personal skills to listen to users and stakeholders.

Project management is particularly hard in OSS because often we don’t have clear employer/employee relationships with development teams. This means that project managers need to find non-monetary ways to convince developers to work on important rather than pleasant tasks. This requires either a lot of creativity or a very understanding development team.

Marketing

  • Who would benefit from our project?
  • How do we speak to them?
  • What do we say to motivate them to take a look?

Many excellent software projects go unused because people don’t know that the project exists. Often we can have more impact by telling people about current functionality than by improving or building new functionality.

Marketing communicates the capabilities of the project to new communities that need that capability, in a language that those communities understand. This communication might be in the form of social media, academic papers, white papers, or conference talks. We use different communication systems based on who we are talking to.

It can be challenging to know which of these methods work best, and so effective marketing is also quantitative. Marketing observes traffic patterns on webpages, sends out surveys, tracks engagement on social media, and learns as much as they can to improve the projects’ outreach.

It’s important to understand that marketing is more than just tweeting out about releases, or maintaining a mailing list. Good marketing continuously works to find new potential user bases, and the right way to engage with them on their level.

Sales

  • How do we match the project’s capabilities to the needs of a particular institution?

As developers, we often think of sales and marketing as trying to trick people into buying software. This is only true if your software is bad, and trickery is necessary. Otherwise, sales and marketing are much more about having conversations with your users, and determining which parts of your software solve which parts of their problems.

Where marketing is broad, sales focuses on a particular institution that has already shown interest.

Good sales is mostly about asking questions and listening well.

  • Why are you interested in this software? What do you hope to get out of it?
  • What are you doing now to solve this problem? Why doesn’t that work for you?
  • What are your pain points?

Once you have a good sense of what their pain points are you can help them to understand how your software might help them if it does, or point them towards other solutions if it doesn’t. You likely know much more about this space than they do, and they can use your expertise in navigating it.

If you’re spending time one-on-one with an institution then probably you want something from them. In traditional business this might be money, but in general this could be many things, including engineering time, co-marketing, or you may just want to support a just cause. Good sales is also about clearly communicating the needs of your project to the institution so that they know how to motivate you to help them in the future. They’re probably looking for continued engagement with you and have some things to offer. You now need to negotiate with them to find the right set of things that you can each do for each other to make this a long term relationship.

Sales is a retail match-making process which is often necessary in order to have impact with larger and slower-moving institutions.

HR

  • How is everyone doing?
  • Are they happy? If not, why not, and what can we do about it?
  • How do we make our current community members as efficient as possible?
  • How do we add new members to our community and where can we focus this effort?
  • How do we build the skills of our current team, and how do we help them move on when that time comes?

Software is built by people and people have needs.

For example it may be that one of your teammates is suffering from repetitive stress injuries or mental health issues, and the most productive action you could take isn’t to fix another bug or review their code, but to send them an ergonomic keyboard, or a map of hiking trails in their area.

Or there may be tension in the community caused by a personality mismatch, and you need to engage in conflict management to keep things smooth.

People’s lives change. They have kids, get new jobs, retire, need vacations, or need help finding new positions. It’s important to be there with them, celebrate and console them, helping logistically in whatever way makes sense.

The status today

There are people in every successful project that serve these roles today. Often single individuals serve many of these roles at once, along with more traditional technical roles. We may use different terms like “outreach” over “sales and marketing” or “emotional work” over “HR”, but the concepts are the same.

I hope that by naming this non-technical work it becomes easier to discuss these roles in our projects, and promote and celebrate these efforts among our peers.

blog comments powered by Disqus