Talks
Taking over Someone Else's Open-Source Projects
Summarized using AI
Taking over Someone Else's Open-Source Projects
by Daniel DoubrovkineIn the talk "Taking over Someone Else's Open-Source Projects" by Daniel Doubrovkine, the speaker discusses the challenges and commitments involved in assuming control of open-source projects originally maintained by others. He shares insights from his personal experiences with popular Ruby projects like Grape and Hashie. The video covers crucial aspects of taking over a project, such as contacting the original maintainers, dealing with the absence of maintainers, and the necessary steps to effectively manage and improve the project. Key points include:
- Importance of Original Maintainers: When taking over a project, the first step is usually to reach out to the original maintainer. However, they may be unresponsive or unable to hand over responsibilities.
- Handling Abandoned Projects: The speaker recounts a situation where an original maintainer disappeared, highlighting the urgency and considerations that arise when there's dependency on an open-source project.
- Initial Actions: If maintainers cannot be contacted or refuse to transfer control, forking the project is a viable option. Asking for GitHub and RubyGems access is essential to ensure proper management and updates of the project.
- Maintaining the Project: Once in control, it is vital to establish project organization, set guidelines for contributions, automate builds, and utilize issue tracking effectively.
- Community Engagement: Building a strong community around the project encourages continued contributions. Recognizing contributors and fostering relationships can enhance collaboration and project health.
- Releasing Updates and Communicating: Regular updates should signal activity, and open communication creates a supportive ecosystem. Inviting feedback and suggestions is crucial for community growth.
- Conclusion: Doubrovkine emphasizes the dynamic between code and community, advocating for active participation in open-source projects to ensure their longevity and relevance.
The speaker encourages maintainer roles to encompass not just code oversight, but also building personal connections within the community. By nurturing relationships and fostering a collective mission, contributors feel valued, leading to sustainable project management and community growth.
00:00:13.360
Hi, who in this audience maintains an open-source project that they didn't start? Seems like there are a lot of hands up. I guess my job here is done. However, I have to mention that I did not create my own slides. I apologize for that. I work for a company focused on art, and while I should be able to draw it well, I end up spending more time writing software than drawing. We do draw on a regular basis, but it’s just not the same.
00:00:23.320
Additionally, I have to give some disclaimers. I tend to exaggerate things in my talks, sometimes using examples of people who either don't exist or who exist in other worlds. These are just meant for humor. So, about ten years ago, I was searching for a silly piece of technology to help with installation sequencing. I found an amazing bootstrapper project that chained installers together. This was an open-source project; it wasn’t hosted on GitHub yet, but there was a highly competent developer behind it. By looking through his history, I figured out that he was Italian. He did a great job maintaining the project.
00:00:45.760
I started by sending some simple bug fixes, which he acknowledged and helped with. My company adopted this project for all its software, across the board. It was a significant development since we had a team of about 50 engineers who began using it heavily. Then one day, he was gone. This occurred in the middle of a release, and I panicked a bit. I suddenly had a problem in my hands. I had a few fixes for the code, but I needed his input to verify if they even made sense and to understand the possible side effects.
00:01:09.960
He had simply disappeared. In a moment of desperation, I thought I’d copy the code, create some local patches, and ship a release. Meanwhile, my 50 engineers had their own issues, each struggling with various installers. I began to question why this had happened. Shouldn’t he have left the project in good hands if he was moving on? I started Googling him, trying to find any contact information, but found nothing. This situation left me feeling abandoned as if my needs were ignored.
00:01:26.240
Sometimes, life takes unexpected turns, and you might not always be in control. It turns out he had some serious issues outside of software development and appeared in the newspaper. I began to understand that life happens, and sometimes maintainers can't sustain their open-source projects. In the meantime, a community of users relies on it, and with the GitHub issues piling up, it raises the question: should we take over? It gets alarming when you utilize something, notice it's broken, and then you create a code fix, only to see a long list of similar pull requests closed, indicating someone else has already addressed the same issue.
00:01:56.040
That was my situation. I truly needed this project, and my entire company depended on it. We were shipping software worth millions of dollars, including projects for the government utilizing taxpayer money. Suddenly, it didn't have a maintainer when we needed it the most. As a manager, I had various responsibilities revolving around guiding my teams; I didn't have time to deal with the complications of the project.
00:02:36.360
It was frustrating as the very reason we used this open-source project was to avoid doing the work. Yet, here I was, confronting a large and complex C++ codebase while managing many engineers dealing with their issues and personal problems on top of it. Nobody wanted to take charge, and we all seemed to look at one another for someone to step up. There was a lot of commentary happening on GitHub, but ultimately, nobody wanted to take on the responsibility of maintaining the project.
00:03:02.960
There was also a lack of response from GitHub itself, as they have plenty of repositories and don't make it a priority to assist. Therefore, someone had to step up, and I decided it would be me. While I felt a bit overwhelmed compared to the size of the problem and how many people were using it, I recognized the necessity of it. This brings me to share some stories about my experience.
00:03:35.440
When taking over any project, the first thing is usually to contact the original maintainer. In this case, I imagined that the person behind the project had simply vanished as if they were part of the mafia. However, the truth was much simpler: they had opened a vineyard and completely disconnected from the internet. I sent several emails explaining how I had been using the project and offered to help maintain it. I also shared my credentials and prior experience to assure them that I was serious and could be trusted to take over.
00:04:13.480
Unfortunately, people are human, and there are myriad reasons someone might not reply, despite being active on social media. I witnessed a recent instance where I tried to take over a promising open-source project. After tweeting and emailing, I found the maintainer alive and well, regularly sharing cat pictures on social media, yet they did not respond. I found this perplexing, yet I realized that humans may lack the confidence to hand over their project, fearing it may not be good enough for public use or simply not caring anymore.
00:05:09.600
If such a situation arises, and the maintainer is unwilling to relinquish their project, all you have left is to fork it, which is absolutely acceptable. Ideally, the best case is when the original owner willingly transfers the project over to new maintainers. For Ruby projects specifically, this includes gaining GitHub write access and the ability to add new maintainers.
00:05:48.720
It’s important to ask for RubyGems access as well. I can’t tell you how many times I’ve taken over a project and realized weeks later that I forgot to request it, leaving me unable to push new gems. To mitigate this, I've started explicitly requesting these two essential permissions right from the start. If the original maintainer is responsive and eager for help, they may just grant you access.
00:06:22.760
In some cases, it can be beneficial to suggest the project be donated to a larger community. For instance, a well-known Java project had its owner, who worked for a major corporation, say their final goodbye by renaming the namespace to the project name, a gesture that was greatly appreciated in that community.
00:06:49.960
Once you have the project, you assume control over it. With this power, you can make all sorts of decisions, most of which will likely align with the community’s needs and desires. Being able to list that you are the maintainer of a widely-used project can certainly be an impressive addition to your resume.
00:07:00.760
However, it’s crucial to understand that now the real work begins. Inheriting a project often means dealing with an array of pull requests, unresolved issues, and a frustrated user base waiting for attention. The first step is to organize the project. Establishing basic guidelines and clear paths for contribution can drastically improve its maintainability.
00:07:45.840
It's paramount to have all essential project information readily accessible, including licenses to avoid confusion about the terms under which the project operates. I usually opt for the MIT license due to its simplicity. Setting up build automation—like integrating Travis CI for continuous builds—can help you streamline the process, allowing contributors to focus on coding rather than other mundane tasks.
00:08:41.920
As you establish these automations, be mindful that you want the project to work smarter, not harder. Utilizing tools like Code Climate, dependency counts, and other useful badges can give a better overview of the project’s health, though I personally prefer not to go overboard with such badges. Yet, having a well-maintained README, with clear information on how to access help, download binaries, and other essential details, can be incredibly helpful.
00:09:30.160
Creating a changelog is also critical, as it allows users and contributors to see what changes have been made over time, promoting transparency. I run my changelogs simply, usually formatted in markdown, where for each new release, I welcome contributions and credit contributors by mentioning their names with links to their profiles. This not only gives them recognition but encourages future contributions.
00:10:30.040
Contributing guidelines are also essential, especially for newcomers. You might want to include specific instructions on how to contribute or fix bugs, explaining things like forking the repository, making changes, updating the changelog, and submitting a pull request. Be sure to set expectations by mentioning that merging changes may take time, as these contributions are valuable to the community.
00:11:25.680
Providing a clear releasing document is another vital task. This should outline the steps necessary for maintaining and releasing the software, as it might not be as straightforward as one would expect. It’s crucial, especially for projects that will undergo substantial changes or upgrades, to document the upgrade process well.
00:12:19.760
Don't neglect the importance of establishing an effective issue tracking system on GitHub. Use labels thoughtfully: for instance, use 'bug' to categorize issues that need attention and ensure that community members feel heard and acknowledged. This fosters engagement and encourages contributors to help resolve issues.
00:13:10.880
Building a community around the project is as important as the code itself. It's essential to actively encourage contributions. Make new contributors aware that their insights are valued and that they are welcome to participate actively. This sense of community encourages collaboration and effectively yields better outcomes for the project.
00:14:18.240
Remember, personal touch matters. When someone contributes or submits a pull request, communicate warmly—express excitement and gratitude. If a person has made a significant contribution, send them a direct message to let them know how much their work is appreciated. This acknowledgment can motivate individuals and help maintain a positive environment.
00:15:10.000
From my experience, uplifting contributors is key to maintaining motivation. The role of maintainer shouldn't only be preserved for code oversight; it should also facilitate personal connections. Encourage them to join in discussions, and seek their opinions on future enhancements, while still driving the work forward.
00:15:49.840
To round off the process of rejuvenating the project, consider releasing updates that reflect not only new features and bug fixes but also signify your active involvement in the community. This, in turn, may encourage others, including those who had previously stepped back, to re-engage with the project.
00:16:50.600
Lastly, in seeking new contributors, extend ownership to individuals who have demonstrated commitment through quality contributions. If you observe someone who has made impactful submissions, don't hesitate. Invite them in; establish them as part of the community, boosting their sense of ownership.
00:17:43.000
In conclusion, initiating conversations about potential changes or new features is part of a healthy ecosystem. Invite feedback, welcome questions, and foster a sense of shared mission across the contributor base. Significant changes occur when everyone feels seen, heard, and valued. Your role is pivotal in nurturing these relationships, consolidating a sense of belonging and teamwork.
00:18:37.520
As a final note to my talk, I encourage each of you to engage in your open-source communities actively. Address concerns directly, and always be the welcoming voice. Emphasize that collaboration is symbiotic—your project grows with its contributors, and with that growth comes mutual respect and encouraging fellowship. Thus, community-building is not just an addition to your role as a maintainer; it is its very essence.
00:19:31.720
We have an abundance of code available on GitHub, but it must be coupled with an equally strong community of contributors. It is this group of people who helps manage and maintain projects, face challenges, and inspire one another, ultimately ensuring longevity and relevance. Therefore, I urge everyone to contribute to the community surrounding your projects.
00:20:42.760
Thank you for your attention.
Explore all talks recorded at GoGaRuCo 2014
+14