Getting Unstuck A Sampler of Advice for Open Source Projects by Sumana Harihareswara © 2020 Sumana Harihareswara under the Creative Commons Attribution-ShareAlike 4.0 license (CC BY-SA) Please feel free to share this book, translate it, and reuse it per the license.1 Sumana Harihareswara Changeset Consulting LLC P.O. Box 721160 Jackson Heights, NY 11372 https://changeset.nyc/ +1 (929) 255-4578 Written in emacs and in New York City, 2020. Cover design and layout by Julia Rios Cover photograph by Susanne Stöckli For Leonard, my foundation. And for Aaron Swartz, our lighthouse. Table of Contents • Introduction • Conducting a SWOT analysis • How to start thinking about budgets and money • Teaching and including unskilled volunteers • An outline of the full book • Acknowledgments • About the author • Feedback welcome Introduction Getting Open Source Projects Unstuck (or, in other words: maintaining legacy open source projects. Below is the introduction for the full, forthcoming book.) Who this book is for and what you should get out of it You are about to get an open source project unstuck. Maybe a bunch of work is piling up in the repository and users are getting worried, waiting for a release. Maybe developers have gotten bogged down, trying to finish a big rewrite while maintaining the stable release. Maybe the project's suffering for lack of infrastructure — testing, money, an institutional home. You noticed the problem. So that means it's up to you to fix it. Or you're getting paid to fix it, even though you didn't start this thing. A while ago I blurted out the phrase "dammit-driven leadership." Because sometimes you look around, and you realize something needs doing, and you're the only one who really gets why, so you say, “Dammit, okay, I'll do it, then.” After reading this book, you should be prepared to: 1. Assess a legacy project to decide whether you should get involved. 2. Settle into a legacy project and become a competent and credible contributor. 3. Take charge of a legacy project on a project, people, and financial level. 4. Execute transformative change in a legacy project. 5. Make a legacy project more sustainable, and pass leadership on to someone else. The tech industry glorifies the founders who build “greenfield” projects, meaning they “started from scratch.” But, in my opinion, most of the genuinely valuable work that needs doing is in the “brownfield” — in codebases that already exist. That's particularly true in free and open source software, where, for 30+ years, we've built and publicly shared valuable tools, together. It's a damn shame if those tools go to waste because no one steps up to take care of deferred maintenance. So let's step up. Who this book is NOT for • You've never worked in open source software or contributed to it before. Go read VM Brasseur's book, Forge Your Future with Open Source. • You are starting an entirely new open source project. Go read my advice on starting a new open source project, and then read Karl Fogel's book, Producing Open Source Software. After that, some parts of this book will be useful — sections on meetings, collaboration platforms, money, people management, and so on will be helpful, but you need to read Karl's book first. • You work for an organization that employs all, or nearly all, of the contributors to the open source project. Your system dynamics will be different; you can employ career/job incentives such as hiring, promotion, and termination. You have a budget provided by the org, and the boundaries of the company create a default level of trust and collegiality among contributors. This book gives advice for open source projects where project leaders can’t count on that leverage. Basic assumptions about open source and the tech industries • There is no one tech industry and there is no one open source community. A fruit packing company with an IT department, a UK national government agency's developer team, and a Silicon Valley machine learning startup have different attitudes towards open source investment. A 30-year-old systems programming tool with millions of users has different opportunities and needs compared to a six-year-old library gluing a content management system to a social media platform. • The free software movement and the open source industry are different but intertwined. I often refer to both, combined, as FLOSS (Free/Libre Open Source Software). You do not have to be an ideological free software believer to be a good leader, but you do need to know enough about the free software perspective to avoid accidentally annoying or enraging colleagues, and to protect your project from getting locked into unequal arrangements with commercial users. • Open source contributors, as a population, disproportionately want to code. We have an easy time finding (or being found by) people who want to write features and fix bugs, and integrating these people into our projects. We have a harder time attracting managers, marketers, testers, systems administrators, writers, user experience researchers and designers, customer service experts, event planners, and grant proposal writers, and working well with them and retaining them. Most people who become open source project maintainers did not start out wanting to do maintenance work. They usually wanted to make a cool thing, solve their own needs, or fill a gap that was bothering their peers. They generally had no training, and often have no inclination, regarding long-term product strategy, customer and upstream relationship- building, budgeting and seeking funding, user experience work, and many other necessary disciplines in software leadership. And that’s not a problem, as long as folks with complementary skills can join in and co-lead these projects with them. • Every open source project has a life cycle. Sometimes the best choice for a project is to end it. Many open source projects end through quiet attrition, the founders acknowledging reality years after it ought to be evident (if they ever make a public statement). Far better, for contributors and users, is a planned and announced end-of-life. Giving users a heads-up is respectful and frees them to figure out a new path (including a fork under new management), and choosing to actively end a project frees contributors to move on to projects that can engage with their work and deliver it to users. This is a sampler This book is a first release — a sampler. I'm releasing this sampler, containing three chapters of the book to come plus an outline of the full book, to: • Help gauge the market for the full book. • Share some of what I've learned early. • Get feedback from you — email [email protected] with "Unstuck" in the subject line to tell me what you thought. Conducting a SWOT analysis Problem Read this if your team's running into problems like: Your team has trouble making decisions about what features to implement, what you can deprecate, what platforms/environments to support, how fast the release cadence should be, and related strategic or architectural questions beyond line-level code review and bug- fixing. Your team consistently misses opportunities (such as better tooling/platforms, conference talk slots, grants, or free equipment/travel) because you didn't know they were available, or heard about them too late. Your team gets nastily surprised by new problems over and over, such as a platform vendor ending service, or a competing project adding a killer feature that you don't have. Your team's progress feels frustratingly slow, but no one can pin down why. Reason for the problem The project team doesn't have a shared and current understanding of: • What the project is good for/at, and wants to be/do — fundamentally, why it should exist and keep serving a particular niche, instead of letting competitors serve its users. • Whom you are trying to serve. • What the project is specifically NOT aiming to do/be. • Whom you are specifically NOT trying to serve. • What gets in the way of their users being effective. Those bits of information will help them understand your tool’s positioning (what is it that your tool uniquely does?) and make product differentiation decisions (why should users use it instead of other tools?). The team also doesn't know: • What parts of the current architecture are blocking progress and how urgent it is that they be replaced. • What is happening in the world beyond the project that they'll want to watch out for, to use/leverage or avoid/mitigate. So it's harder for you to prioritize, and to take charge of your own destiny instead of always being reactive. Skills you need to solve the problem I suggest that you do a SWOT analysis, which means taking inventory of your project's • Strengths • Weaknesses • Opportunities • Threats I'll briefly introduce the idea here. You can look around online and find a zillion courses, posts, etc. on how to do a proper or speedy SWOT analysis. So I'll refrain from making yet another redundant one here — I'll focus on how to do one in the context of open source. Note on logistics: In most cases in open source, you should start your work in public and share your work in progress as you go. But this is one of the times that I suggest you do quite a lot of the work in private and make room for some privately-shared sections that would go alongside the public findings. In particular, the "weaknesses" section will probably involve some delicate thoughts on teammates.