When it comes to launching an open source project, free information abounds online, on topics ranging from picking the right license to building a community. But what about when an organization needs to shutter or move away from an unneeded project? There are many complexities to handling this situation correctly, and many companies with successful open source programs plan for the end of a project even before launching one. Now, The Linux Foundation has published a free online guide for the enterprise examining the various considerations: Winding Down an Open Source Project.
“By shutting down a project gracefully or by transitioning it to others who can continue the work, your enterprise can responsibly oversee the life cycle of the effort,” the guide notes. “In this way, you can also set proper expectations for users, ensure that long-term project code dependencies are supported, and preserve your company’s reputation within the open source community as a responsible participant.”
The free guide includes sound advice on the following topics:
- Life cycle planning for your open source project
- What does a dead open source project look like?
- Why plan for the end of a project, before you even launch it?
- Deciding when to end or pull out of a project
- How to end an open source project
You’ll also find direct advice from open source experts in the guide. Contributors include: Guy Martin, Director of Open at Autodesk, Autodesk; David A. Wheeler of Core Infrastructure Initiative (CII); Jared Smith, Open Source Community Manager, Capital One; Christine Abernathy, Open Source Developer Advocate, Facebook; and Chris Aniszczyk, COO of Cloud Native Computing Foundation.
“When you’re starting your project, you’re trying to get people to trust you and allay their fears about joining the project and using your code,” David Wheeler notes, in the guide. “Later, if you say, ‘Hey, this project’s going to go away soon,’ that is not going to help with trust. Instead, you should say you’re going to do your best to make it work out if it will ever be ended, and that you promise not to just drop users. Tell them you’ll let them know what is happening at each step. Give them time to transition, and work on ways to help with the transition. That can be very helpful.”
“It doesn’t happen all the time, but in the past with one of our projects we moved it over to a different company,” Abernathy noted, in discussing Facebook’s practices. “We don’t have any hard and fast rules about doing this. Typically, we’ll just move it to a different organization. When it comes to moving within groups, we sort of shop around internally and find out whether it is still being used by someone. With our open source projects, we strive toward internal adoption. So, it might be used by an entirely different team. If they are willing to maintain it, then we move it to a different team, and that’s very easy. That just means changing a label somewhere where it says who’s the owner.”
Are you interested in more good advice? Check out the free online guide today. Additionally, The Linux Foundation and The TODO Group (Talk Openly Develop Openly) have published an entire collection of enterprise guides to assist in developing open source programs and understanding how best to work with open source tools. The guides are available for free, and they cover everything from How to Create an Open Source Program to Starting an Open Source Project.
Latest posts by Sam Dean (see all)
- More Tips for Managing a Fast-Growing Open Source Project - March 23, 2018
- Lessons Learned from Growing an Open Source Project Too Fast - March 15, 2018
- Adrian Cockcroft on the Convergence of Cloud Native Computing and AWS - February 26, 2018