How To Get A Project Unstuck

00:00:05.299 Hi everybody, I'm Sumana Harihareswara, and thank you very much for joining me for this talk at RailsConf on how to get a project unstuck.

00:00:11.639 When an open source project has gotten stuck, how do you get it unstuck, especially if you aren't already its maintainer? My teams have done this with several projects, and today I'll share a few case studies, principles, and gotchas. More than developer time, coordination and leadership are a bottleneck in software sustainability. I hope that you'll come away from this talk with steps that you can take, both in the short and long term, to address this for projects that you care about.

00:00:31.080 Now, there are no slides for today's talk, but there is an outline already posted on my blog in case you want to refer to that. I'll also be posting links on Twitter and other platforms as RailsConf happens in case you need something visual to follow along with, but otherwise, there's no need for slides. If you'd like to put on some wireless headphones and do something else while you listen, that is totally fine with me.

00:00:57.480 Sometimes I think about Frodo from Lord of the Rings. This is not going to be the kind of talk where you have to know a lot about Lord of the Rings to follow along, but Frodo is reasonably well-known for saying that he would take on a quest unsure of how to do it: 'I will take the ring, though I do not know the way.' I always imagine him saying that kind of frustrated, as in, 'I'll take the ring, though I do not know the way.' I call this 'damn it driven leadership'—like, 'damn it, somebody's got to do it.'

00:01:21.659 If you're watching this talk, this might be you. There is an open source project, and it's supposed to be open—anybody can participate—but it seems hard to get it unstuck. You want to participate, not just in improving the code or documentation, but in improving the project. Maybe there's a team member that everybody else is having trouble with, or maybe you need to expedite a release. This is where I come in; I want to help you take on the necessary work.

00:01:54.119 Let me start by telling you a few stories of times I got a project unstuck, after which I'll share some principles, gotchas, and next steps. One time, I got a project unstuck by gathering information and helping people make the decisions they needed to make. I wasn't necessarily the one making most of those decisions. It was a case of unifying the to-do list for a feminist science fiction convention I care about called WisCon. From 2011 onwards, I'd been attending for a few years and had experience as a project manager in both proprietary and open source software.

00:02:54.420 The volunteers who developed a web application to manage WisCon’s submissions and other tasks had a jumble of bug reports and feature requests scattered across various platforms: Basecamp, Google Code—which is an old website that no longer exists—old emails, and physical or virtual Post-its. Over three to four months in 2011, I consolidated and organized those to-dos into a prioritized queue, placing all the code-related issues into Google Code.

00:03:18.180 I kept the team on one page with regular updates via Basecamp and weekly conference calls. Once I stopped volunteering with the project, they knew what everyone was supposed to be doing and what the high-priority tasks were, allowing them to operate more efficiently. A couple of lessons emerged from this experience: First, open all the drawers and look under the couch—find where people stash notes and to-dos, and don't get distracted by 'shoulds.' If you ask people where they should be making notes about issues and backlogs, their answers might not reflect reality.

00:04:27.619 When you have to consolidate platforms, instead of getting ideological, see if you can choose the one that most people currently doing the work want to use. Even if you don’t particularly love Basecamp, if that's what most contributors prefer and it has all the essential features, consolidate there. This process took a few hours a month over several months. It wasn’t a huge time commitment, but it supercharged the team's ability to move forward.

00:05:11.340 Another time, I did something similar by filtering and cohering a priority list. I was involved in a mailing list manager called Mailman, which began development in the 1990s. It had its 2.0 release in 2000, 2.1 in 2002, and was trying to release 3.0, which took seven years by 2015 without any progress. I began contributing as an individual in late 2014 and started helping in 2015.

00:05:45.660 As an individual programmer, I needed the developer instructions to be clear, so I worked on that. To know what bugs to fix, I cleaned out obsolete and non-reproducible bugs in the tracker. It was a lot of cleanup that I undertook just to make my workspace comfortable. A few months later, a group of us met at a Sprint during a conference. We all knew we wanted to get 3.0 out, but everyone had their personal focus, and no one addressed the big picture.

00:07:12.600 So, I grabbed a marker and a big Post-it note and wrote out the blockers to 3.0. Just putting those down and talking about them enabled us to identify which were genuine blockers and which ones were resolved. Over the course of that work week, I continued to help clarify priorities, assist with decision-making, and keep everyone unblocked. By the end of the week, we were just one upstream dependency bug away from releasing 3.0, which came out a few weeks later.

00:08:15.479 The lessons learned here were that sometimes it seems there are no explicit priorities, and if that’s the case, it might be due to differing opinions about what the priorities should be. However, sometimes, it’s simply no one has taken the time to bring the questions up and make them explicit. Whenever someone does clarify the priorities, it opens the door to more precise planning around what to do first, what depends on what, and when users can expect updates.

00:08:49.460 First drafts are essential; they serve as springboards for teammates to make decisions more effectively. You don’t have to be a lead developer to pick up that marker; in fact, it can often be more effective if you're not. If at least one maintainer is not particularly enthusiastic about coding, it can allow others to focus more on the project's overall success instead of just programming.

00:09:23.880 Another way I’ve worked on unsticking projects is by gathering funding. Open source and financial resources is a massive subject, and there's a lot of existing material to help think through this. For example, I may refer you to Benjamin Mako Hill's article from 2005, 'Problems and Strategies in Financing Voluntary Free Software Projects.' This article will be referenced in the outline provided.

00:10:11.399 There are many ways to gather funding, including grants which can offer free money to help fund your open source project. I won’t dive too deeply into grants here, as I shared a separate talk recently at Mozilla Festival that covers that topic. Instead, I want to discuss corporate funding, particularly a case study regarding Autoconf.

00:10:59.520 Autoconf, a tool for creating configure scripts for building and installing software, was stuck. It was initially founded in 1991 but stagnated after the release of 2.69 in 2012, with no progress for several years. In January 2020, after almost eight years without a release, a friend noticed a plea on the Autoconf mailing list for someone who could be paid to make a new release.

00:12:25.920 My friend Zach, who is a contributor to Autoconf, brought this email to my attention, and together, we began a conversation about a paid engagement. We started with a discovery phase, which Keith financed. Later, we generated a big to-do list outlining everything necessary to get Autoconf 2.70 out the door.

00:12:45.300 As we continued communicating, we looked for additional funds. We were able to secure money from Keith, Bloomberg, and the Free Software Foundation's new toolchain fund. Zach and I worked diligently, and Autoconf 2.70 was eventually released. Many people expressed their surprise that it finally happened, and they appreciated that it came at the end of a challenging year.

00:13:49.860 The crucial lessons learned include: look for corporate funding opportunities to help your project get unstuck. Engage with people who have already offered money or assistance. Zach’s existing credibility within the Autoconf project significantly contributed to our success. However, be cautious with fixed-price engagements, especially if there's no continuous integration in place. The preparation for the 2.70 release took almost twice as long as anticipated.

00:15:01.079 To expedite a delayed release using corporate sponsorship, it can work while remaining careful about budgeting time to ensure adequate compensation is achieved. In another case study, like the one I shared earlier about WisCon, sometimes just a bit of nudging can be tremendously effective.

00:15:47.700 I want to share my experience with Pippins, a Python packaging-related tool that hadn't seen a release since November 2018, and there was chatter in early 2020 about removing it from recommended tools due to inactivity. I reached out to a maintainer via IRC—what predated Slack—and discovered he was struggling to concentrate on the release tasks because of distractions.

00:16:57.380 He indicated that what he really needed was someone to check in with him frequently to keep him on task. I volunteered to be that accountability partner. Eventually, through gentle reminders and drafting updates he could improve and send to the mailing list, I was able to help him break through his challenges. He subsequently made two beta releases and eventually put out the next release in May 2020, allowing the Pippin team to move forward.

00:18:03.960 Some key lessons to take away from this experience include: you can accomplish a lot with minimal time investments—my total participation amounted to only about 15 hours over several months. Second, being able to complement what's missing requires a level of trust within the team.

00:18:39.980 You can only do that if you have a good relationship with your colleagues. When people feel comfortable being vulnerable, they can ask for what they need, and they can accept help when it's offered. Trust is crucial for fostering communication within a team and presents opportunities for improving project momentum and productivity.

00:19:18.240 Now, let me share some principles—my working assumptions—as I analyze open source projects and evaluate what it takes to get them unstuck. First, there is no singular tech industry and no single open source community. Various subgroups exist. Some individuals, like grad students, might simply want to create a tool for their research, only to set it aside once they defend their dissertation.

00:20:09.820 There are professionals in industry who collaborate on complex cloud-based products that practically operate solely through complicated APIs with no user-facing interfaces. All these diverse individuals have different motivations, needs, and capabilities. Additionally, there is no singular open source community. Generalizing about the open source community might not yield positive results; it’s prudent to consider specific groups and the conditions necessary for their involvement.

00:21:03.540 Another observation I have is that open source contributors, as a population, disproportionately want to code. This may seem obvious, but when contemplating the software industry as a whole, plenty of non-coding roles exist—marketers, salespeople, testers, administrators, etc. Open source tends to attract individuals primarily focused on coding, leading to a shortage of other necessary skills among contributors.

00:21:48.380 Consequently, if you contribute to open source, it would be beneficial to learn skills beyond coding, such as management, design, writing, and customer support. Another perspective I hold is that skills are fungible, domain knowledge can be learned, and credibility can be earned.

00:23:02.760 There is a tendency in open source to perceive individuals solely based on their existing knowledge of a particular system, but all systems evolve, and individuals can learn anew. Even if no one seems willing to volunteer, you might not have found the right approach to engage prospective volunteers in a rewarding manner.

00:23:42.540 It’s important to understand that skills are adaptable—if you haven't learned something, you can learn it. When I entered projects like Pippins and Autoconf, I wasn’t the founder or primary maintainer, but I was able to develop credibility gradually through my contributions and support. All open source projects experience a lifecycle, and it's essential to contemplate potential endings.

00:24:48.420 A project can succeed in various ways, primarily because individuals who start and contribute to it may have disparate goals. It's crucial to recognize when a project's likelihood of success is low, as determined by the stakeholders involved. At such a point, having a graceful ending is often better than enduring a protracted state of limbo. This perspective prompts reflection when devising strategies to get a project unstuck.

00:25:56.460 Additionally, five key areas often lead legacy projects to become stuck: strategy, team structure, interfaces, workflow, and funding. Analyzing how these factors apply to the examples I shared regarding Mailman, the WisCon application, Autoconf, and Pippins can prove enlightening. Addressing strategic issues primarily involves defining our goals and understanding why the project exists. This can include evaluating how to effectively empower users and the urgency surrounding pressing work.

00:27:55.620 The team aspect concerns the questions and related issues faced by team members. Do we have enough maintainers for essential tasks, and do we have promising contributors available to replace outgoing maintainers in the future? Additionally, it's vital for all involved to understand who has decision-making authority and whether confusion exists around roles and powers.

00:29:01.799 Workflow and digital infrastructure examine the mechanics supporting the project's code base. This includes ensuring efficient testing for all submissions, interlinking discussions with new issues and patches, and managing bottlenecks within communication platforms. Financial resources should also be considered by evaluating whether sufficient funds exist to achieve goals and developing proposals that convert these funds into tangible project progress.

00:30:14.859 To summarize, these five areas—strategy, team, interfaces, workflow, and funding—are pivotal in determining how legacy projects stall. Take a moment to contemplate some projects you care about and consider how these aspects might create obstacles, as well as which ones could be potentially resolved.

00:31:16.260 As contributors interested in helping a project become unstuck, it’s crucial to establish your path toward success. Here’s a sequence I have followed that applies whether you are a volunteer or getting compensated: First, 'settling in' involves carrying out routine tasks that require little trust, allowing you to assess the project and gain credibility with existing contributors and maintainers.

00:32:41.100 Next, 'taking charge' involves stepping into roles that require trust, where the team has already expressed agreement that these actions are needed. This encompasses managing communications, handling issues, and guiding contributors through the development process. The 'change-making' phase involves utilizing gathered consensus to enhance the project by modifying its infrastructure, including social, digital, financial, and legal aspects.

00:34:07.740 Finally, 'passing the baton' refers to successfully transferring leadership to successors and moving on. As you improve the project's infrastructure—social, digital, financial, legal—you enhance its sustainability. Knowing a project is in a good state before you leave is a fulfilling experience.

00:35:37.920 It's essential to follow these steps in order, as progressing haphazardly can lead to unwanted consequences. Beginning by performing ordinary contributor tasks lightens the burden on others, allowing them to focus on development more effectively. Engaging transparently with colleagues is vital for productive conversations about decisions and maintaining emphasis on the project's advancement.

00:37:33.960 Everyone wants to see the project thrive because a project cannot thrive if it becomes bogged down in disputes regarding leadership or authority. The tools and practices discussed are meant to empower any contributor who cares about an open-source software project, which means anyone can step up and drive initiatives forward. As for future endeavors, I would love to see more individuals inspired to contribute to open source in ways that enhance our entire industry.

00:39:02.880 I am currently working on a book. You can download a short excerpt with a few chapters for free at changeset.nyc. I would appreciate your feedback on the talk and on the book. We are now part of an evolving open-source software community, which ought to focus on cultivating new leaders who will contribute to maintaining critical open-source projects across various frameworks and languages.

00:39:49.020 Once you possess these skills, you can contribute to numerous projects in different domains. Let's work together to foster sustainability in the software ecosystem and to learn from one another's experiences in this ongoing endeavor. You can reach me via my social media accounts, at @brainwane. Thank you very much for listening, and I hope you have a pleasant day, evening, or whatever part of your 24-hour cycle it may be.