Most people would agree that everyone should contribute something back to Open Source at some point in their careers. We have to realize that an ongoing Open Source contribution to a project can't be sustained forever. We might graduate from college, get a new job, need a break to travel, have kids, help raise grandkids, retire and even get bored with a project. While we need to improve open source sustainability, we also need to accept the reality that people continually come and go from open source projects.

Up until recently, I felt that 'burnout' was the only talked about method when people left the Drupal community. Up until DrupalCon, I thought that once I committed to supporting something, like a module, I was obligated indefinitely or at least until I burned-out from supporting it.

In my new year blog post title, Webform, Drupal, and Open Source...Where are we going?, I stated…

...and I don't think I am the only one.

Jeff Eaton's presentation titled "You Matter More Than The Cause" addresses burnout and how it impacts the sustainability of teams and he says…

I think we need to stomp out the concept of developer burnout in Open Source and equate developer burnout to poorly-managed companies and organizations.

One of many valuable lessons I learned at Adam Goodman's Teamwork and Leadership Workshop at DrupalCon Nashville was that it’s okay to plan an exit strategy, it’s even something that can ultimately help the community and potentially prevent burnout.

"Planning an exit strategy" means defining specific limitations around your responsibilities and commitments to complete a task. This helps everyone plan for the succession of duties. Adam's personal example was that before he took on the role of being the Chair of the Drupal Association Board of Directors he wanted the commitment to be for a defined amount time.

Personally, I have decided that every task that I do in the Drupal community should include an exit strategy before I commit. When offering to help get an 'About Drupal' content section in core, I have committed myself to getting the initial content and section built while needing to get more people involved to help iterate and improve the content moving forward.

For Open Source communities to be a healthy ecosystem, we need to acknowledge the life cycle of our projects and people. New people join our community every day while other people regularly leave our community for new challenges. Since our community and ecosystem is built on people's commitment and passion, we need to think about how we grow and sustain our 'tribal' community.

Shannon Vettes’ presentation titled "Growing Our Tribes: Creating Sustainable Micro-Communities in Drupal and how you can help" about DrupalCon Nashville succeeds in defining a tangible approach to improving how our community works together and collaborates. Shannon is applying the concepts behind tribal communities to build more sustainable 'micro-communities' in Drupal and open source. Simply put, Drupal is huge and daunting to everyone involved. No one can understand or contribute to every aspect of Drupal, which is why we need to recognize that different aspects of Drupal like committees, project initiatives, contributed modules & themes can be thought of as micro-communities and tribes.

Shannon's project management perspective is essential to helping us solve the sustainability problems around open source software. I have concluded that technology alone is not going to solve the challenge of ongoing sustainability for open source projects. I feel that content and process is what will make open source projects more sustainable. I have begun to talk about Content First, Technology Second, seeking to add some messaging about the Drupal community into Drupal the software's user experience. For me, Shannon's presentation gets to the heart of what defines a successful open source community, the connections between people and how they collectively work together.

I love that she emphasizes the need to acknowledge what I want to call the three phases of contributing to open source.

• Onboarding: The process of getting involved.

• Contributing: The process of productively contributing.

• Off-boarding: The process of winding down one's involvement.

I feel as a community we have always thought about how people contribute and we are re-addressing onboarding process by improving our evaluator experience, but we are not fully addressing the off-boarding process. And we need to because how we off-board people can have a positive or negative impact on the overall health of our community.

Each one of these phases requires a dedicated blog post, DrupalCon presentation, and maybe even a dedicated core initiative and team. For now, I want to talk about how we say goodbye.

Finding new maintainer or co-maintainer for your project and dealing with unsupported (abandoned) projects are the only pages that I am aware of that begin to address what happens when people leave the community.

I am not sure we need a "How to abandon a project" page on Drupal.org but maybe we need to look at documenting the open source contributors journey from beginning to end and make this part of the user experience on Drupal.org and maybe even in Drupal's (the software) user experience.

Chris Albrecht's presentation title "Managing Your Most Important Resource: You" from DrupalCon Nashville explores Albrecht’s journeys within the Drupal community. He tells his very personal story about getting involved in the Drupal community, experiencing burnout, attending DrupalCons, maintaining a module and even not maintaining a module. He concludes with offering really sound advice on how to adjust one's priorities when working in open source and life.

Before we ask someone to get involved in Drupal, we should talk to them about the overall journey into Drupal and open source software. This journey should be about being human, being part of our community, and highlight members of our tribes & micro-communities - not about fixing bugs and reviewing patches in an issue queue.

Along the way we should tell people..

There is some irony that my last two blogs posts were about saying "Hi" in Drupal (the software) and at my local Drupal NYC meetup and now this blog post is about saying "Goodbye". Saying hi and bye is about communication and if it is done right, with some empathy, we can strengthen and grow our tribes. Goodbyes should be built into the equation, viewed as something that could potentially have to or need to happen along the way, and not something someone does - or doesn’t do - as a result of burnout.