How to leave an open source job gracefully

How to deal with leaving an open source project

Leaving an open source project differs from regular job turnover.

How to deal with leaving an open source project
Image by : 

opensource.com

x

Get the newsletter

Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.

In early 2015, I decided to leave my job, a job that I'd been at for just over two years. Nobody among my family and friends was surprised that I was pursuing another position. Making this move was a common thing to do, especially in the technology industry where we tend to change jobs frequently.

The act of leaving the job was a typical one. I told my supervisor that I was leaving and gave two weeks' notice. On my final day, the members of my team took me to lunch at the usual restaurant reserved for one's last day at the company, regardless of whether one was quitting or had been fired. Following that, I had an exit interview with someone from the human resources department, where I signed the usual paperwork stating that I wouldn't try to recruit people who were still working for the company and received my final paycheck.

A few months later, I made an even more difficult decision. The decision was to leave an open source project that I'd helped to start and had been active in running for the past 14 years. I'd been working on the project longer than my last five jobs combined. When I announced that I was leaving the project a lot of people were surprised, mostly because up until that point no one in a leadership position had left the project and no one knew what that meant for the project, especially me. Unlike the previous jobs I'd quit, there was no exit strategy in place and I didn't have a plan for what I would do next.

How and why people leave open source projects

This got me thinking about leaving open source projects in general. The approaches that people take, what happens when someone leaves, and the reasons why people leave. I started talking to people who had left projects and asked them why and how they left. I wanted to know generally how the experience had been. The reasons were as varied as the experiences of leaving. People choose to leave a project for a variety of reasons. Sometimes it's simply changes in life or the lack of time to remain involved in the project. Sometimes if a project is tied to a job, a change in that job had led to them leaving that project. Sometimes they left for unpleasant reasons.

In many of these cases, because many open source projects don't have the equivalent of a human resources department it is unclear who you take a grievance to, especially if your grievance is with another leader or the founder of a project. In many cases, people ended up leaving projects very vocally. Often this kind of action leads to a fork of the original project or a completely new one. When people leave a job, they sign paperwork saying they won't recruit former co-workers for a period of time, as I did, but is this possible or enforceable with open source projects? Volunteers don't sign noncompete or nondisclosure agreements when they join open source projects, and those things go against the very nature of open source.

You're leaving a project. What happens now?

If you've left a project or you've decided to leave a project, now what? If there's a community around the project, are you still part of it? Is anything in your name associated with the project, its Twitter, its work on GitHub, etc.? Assuming you decide for an amicable leave what does the transition process for leaving look like? Is there one in place? Does the project have an exit interview of sorts and why not? Do you give two weeks' notice? Is there any sort of announcement or notification to the community that you've decided to leave? Does the project make the announcement, does the individual, or both? What is and is not appropriate to say?

Documentation and announcements

Most of the people I talked to said there had been no announcement made when they left leadership positions. A few people indicated that they didn't notify projects that they were leaving because they considered their roles to be minor. If you're leaving and thinking that there will be a mass exodus of people following, I'm sorry to say you will likely be disappointed. Your reasons are not everyone's reasons.

If you were a founding member of a project that is funded through your company, what happens if you leave that project or the job? Who owns that project now? In speaking to the leaders of a handful of open source projects, most people said that they don't have a formal process in place for when someone in a prominent position leaves simply because that hadn't happened yet. Others said that they wished they had planned for it after problems arose when members left or were asked to leave.

What can we as project leaders do to make this better? We can ensure that there is a documented process of what prospective contributors can expect when they both join and leave a project. We can make announcements and be transparent when people leave projects. Projects leaders should take note if and when contributors stop contributing and follow up to see why.

3 more tips

Ensure assets are associated with the project and not individuals. Look to see who within the projects has access to important information, such as account logins and passwords.

Evaluate your project for the "bus factor." This means you should figure out how many people would have to be hit by a bus before the project stalls due to lack of knowledgeable or competent personnel. If anything associated with your project has a "bus factor" of one, then you need to re-evaluate the structure.

Ensure there is a governing body. If your project doesn't have any governance, it needs it. Groups like the Software Freedom Conservancy will act as an umbrella organization for your project. If you decide to go the route of having your own organization, with your own board of directors, definitely rotate through them every couple of years to ensure that the organization doesn't end up being stale. Hold elections for board positions that are open to the project's community. Make sure that any and all board meetings are properly documented for future members as well as for the community at large.

Just as the way people join an open source project sets the tone of its future involvement, the way people leave a project sets the tone of the project for those that continue with it.

Gareth will be giving the talk "Leaving an open source project" at OSCON 2017 in Austin, Texas. If you're interested in attending the conference use this discount code when you register, for our readers: PCOS.

Topics

About the author

Gareth J. Greenaway - International man of mystery, SaltStack Developer. Opinions belong to the voices in my head.