In my career, I've had the opportunity to work as a maintainer on a few Open Source projects (one of them being DEV).
Since joining DEV, I've started to identify the seam that exists between the roles of "Software Engineer" and "Open Source Maintainer," where both spend a significant amount of time writing code and having technical discussions, the circumstances under which these people work is quite different. Therefore, the skills they need to succeed diverge at a certain point.
I've decided to write down a few of the points I've determined that these two "crafts" diverge from one another. While they are incredibly similar, and both roles can benefit from mastery over all of the skills I mention here, the allocation of effort across those skills is different. Where one might invest most of their energy into honing a set of technical skills, the other might invest in more holistic communication skills.
Like most of the things I say, there are probably a lot of cases in which I'm wrong, so read this article with a hefty helping of salt.
The tools of the craft
As a Software Engineer, one can expect to write new features and fix bugs while also spending some non-trivial amount of each day discussing the work they do. Occasionally, a traditional Software Engineer may also need to interact with the people who use their software.
In my experience Software Engineers need, at a minimum, intense curiosity and an uncommon drive to learn. However, being successful in the role takes a lot more than just a big mental appetite.
Software Engineers need to be skilled communicators, a considerable portion of the job revolves around being capable of contributing to technical conversations. In many cases, the most capable engineers are good at giving and receiving feedback concerning the projects they work on.
On some level, Software Engineers also need to be reasonably competent self-managers. Skills like time-boxing, project estimation, documentation, and prioritization are ubiquitous in the software field. Even when there are dedicated project managers and business analysts, engineers need to be capable of self-regulating, and the best engineers exhibit a certain level of autonomy when working on projects.
The discipline of Software Engineering is hard to encapsulate in a short article. Still, I'd argue that, at a minimum, those of us building software professionally need to have a grasp on these skills.
Open source maintainership
Some Software Engineers are lucky enough to work on Open Source full-time as contributors and maintainers. A few months ago, I became one of those lucky people when I joined the DEV team, but before that, I spent about a year as a maintainer of the Solidus ecommerce platform.
During that year, I learned a lot about what it takes to be a successful Open Source maintainer.
Much like other Software Engineers, an Open Source Maintainer typically spends quite a bit of time writing and reviewing code. Open Source Maintainers probably spend some of their time in meetings and discussions about the work they are doing. They also interact with the people who are using their software.
Generally speaking, there is a ton of cross-over in the responsibilities and day-to-day life of these two technical professions. So much so, that most people probably don't realize the distinct differences in each skillset.
Most people probably believe that an Open Source Maintainer is simply a specialized Software Engineer, sort of like people with the job title "Frontend Architect" or "Site Reliability Engineer." I think that, also, is generally true, but not universally.
From the time I've spent as a maintainer, I've learned that there is a non-technical aspect of maintainership that could arguably be more important than the software engineering skills that usually come into play: communication skills.
Every Software Engineer needs to be able to communicate, but only a few communicate on the level that is required of a quality Open Source Maintainer. If a Software Engineer needs to be a skilled communicator, a Maintainer needs to be a master.
A large portion of the daily responsibilities of maintainers is centered on that individual's ability to communicate with project stakeholders and users. For example, a maintainer might spend hours every day responding to issues, writing documentation, holding open forums, meeting with sponsors or stakeholders, and reviewing code (an ironically human-centric skill).
In fact, this ability to communicate is so important that there is a space in the Open Source world for non-technical maintainers who are simply world-class communicators. They can write approachable documentation, aide in organizing events, participate in marketing efforts, help people find the answers they need, and assist in the creation and moderation of issues.
This, of course, doesn't mean non-technical maintainers alleviate the need for technical maintainers who are masterful communicators. It just means that communication might be just as important (or more important) than technical skills for Maintainers.
Another deviation from the traditional Software Engineer toolkit arises when we start to think about larger Open Source projects. Open Source flourishes when a diverse community comes together to solve a shared problem. However, in a world where there is so much noise on the internet and even a significant variety in similar Open Source projects, it can be a struggle to build a community around a given project.
As a result, I'd argue that a good Maintainer has some grasp on marketing.
Before you scroll to the comments to tell me how Maintainers should be nothing like those evil marketers, understand that I'm using the word marketing to describe a set of tactics used to connect people with the best solution to their problem; nothing malicious, the opposite.
Adoption isn't the kind of problem that most Software Engineers have to solve in their profession. However, Open Source maintainers do have to think about the adoption levels in their project. Healthy projects should have some degree of adoption. That isn't to say a project should have massive adoption and a Hockey-stick growth curve. Instead, diverse communities and new contributors usually improve Open Source projects, so it makes sense that Maintainers worry about the adoption of their projects.
In turn, Maintainers need to know how to connect with people that would benefit from their projects and should have a good idea of how to onboard those people into their communities. The onboarding of new community members is a key factor in building a diversity of knowledge and experience, which should translate into better software, doing this well will result in the retention of those community members and a more "successful" Open Source project (in my opinion).
The caveat being that growth for growth's sake is actually destructive because a project attempting to force growth will ultimately attract those people who are not best served by the project resulting in a derailing of the project's purpose.
Connecting with people that benefit from your project is marketing.
There is another skill that I think encompasses many of the ones I've mentioned here, but I think it is worth calling out by name: community building.
I think community building might be one of the best ways to describe all of the things that a great Open Source Maintainer has to do on top of being technically skillful.
Community building is all those things great projects do: organizing events, building culture, being inclusive, and hearing the thoughts of others. Ultimately, it comes down to providing a platform to communicate with those people who've invested in the project with their time, money, and mind.
Developing the skill of community building is hard. I've only experienced growth in this arena by learning on the job: running meetups, conferences, and seeking out opportunities to interact with communities (e.g., my podcast and the articles I write).
While there are infinitely more skills that can complement these skills, I've found that a solid understanding of these "more human" skills is crucial to becoming a top-shelf Open Source Maintainer.
In a nutshell
I certainly wouldn't say this is a comprehensive guide to the skills that either Software Engineers or Open Source Maintainers need to be successful, but these are things that have stuck out to me over the last year.
Ideally, this article clarifies something for people who are interested in the practice of maintainership, but I'm sure there are some disagreements and questions that will arise from my opinions. I'd love to talk more about that in the comments or a private message, so please share your thoughts on the distinction between Software Engineering and Open Source Maintainership.
There's more...
I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.
You can also follow me on Twitter, where I make silly memes and talk about being a developer.
Top comments (1)
I came to a similar conclusion 20 years ago, when I helped write the rules FreeBSD uses to elect their Core Team. At the time, the existing Core Team was comprised entirely of men who worked on the FreeBSD kernel, and a few who also spent some time in libraries and utilities. Plus Jordan K. Hubbard, who had become the unofficial Voice of FreeBSD mostly by way of stepping up to do so.
In re-writing the rules to elect the Core Team from the body of contributors, I was an ardent supporter of bringing in not just kernel developers, but also contributors from the documentation team, the "ports" team that brings more than 20,000 precompiled applications to FreeBSD, and other contributors like the ops teams that keeps the project infrastructure up and running.
I'm proud of what we managed to accomplish. 20 years and 10 elections later, the process is still working--with some inevitable adjustments. Along the way many open source projects, especially the large ones, have learned that some of the ideas of the 90s about "code talks, everything else walks" aren't sustainable in a large project. Once you've grown beyond a small handful of contributors, you are building a community as much as you are building software. Communities have to protect themselves from people who can't fully join the community, regardless of how much code they can crank out.
Codes of Conduct are important not of themselves, but because we value people more than we value code (or docs, or build scripts for applications, or whatever). That's a point I'm happy with all the time, every day. Technical Merit has it's place, but not above people.
Let me call out a few other names that were critical in moving FreeBSD n this direction: Poul-Henning Kamp started it and gave us a mandate to get it done; Warner Losh and Greg Lehey made the process worth all the fuss and bother. Open Source projects newer than Y2K often end up adopting a variant of the process we went through to govern themselves once they grow past the "handful of volunteers" stage and I'm thankful for all of it.