14

Sunsetting an Open Source Project

Open source projects start with good intentions: a problem to solve, an eager and motivated maintainer, and users and contributors flocking to the project and providing feedback. If everything goes right, a vibrant community and a great solution will emerge.

While putting code out under an open source license is a permanent action, having an open source project isn’t. In Chapter 12, Marketing for Open Source – Advocacy and Outreach, we looked at a chart that describes the life cycle of an open source project; Figure 14.1 illustrates that chart:

Figure 14.1 – Life cycle of an open source project

The backend of the life cycle is Sustain…, which sometimes means the project is just maintained over time. In those cases, there is still usage, but it’s overall considered feature-complete, with any changes or additions solely focused on bug fixes and security issues. One example of an open source project in maintenance mode is the Apache Struts web framework. Struts was widely used to build Java web applications, but it has been in maintenance mode since the version 2.5 release in November 2016. While the project no longer adds new features or enhancements to the framework, patches and bug fixes continue to be released to maintain its stability and security, keep the documentation updated, and support the existing user base who continue to use Struts in their applications.

But sometimes, we see the community around a project, as it is in the Sustain… stage and starts waning, going to other solutions that are being actively developed or are better suited for their needs. This has a ripple effect; as users leave, so do contributors, and then maintainers leave the project with no one actively maintaining it over time. This is when a community starts considering the next and final step in an open source project’s life cycle – sunsetting.

Do note that sunsetting isn’t necessarily a bad thing either. In this chapter, we will see that for some sunsetted projects, other similar projects or successor projects allow the code and technology to continue. Open source communities tend to be lacking resources, so bringing project communities together helps grow a stronger project and avoid redundancies.

Sunsetting an open source project means winding down or discontinuing the development and maintenance of a project. This can happen for various reasons, including lack of funding, developer interest, or achieving the project’s goals. Sunsetting a project can be difficult, especially if the project has a significant user base, but it can also be necessary to ensure that resources are used effectively. In this chapter, we will walk through how to sunset a project while touching on these topics:

• How to know when a project is slowing down
• The sunsetting process
• What comes after sunsetting?

Let’s start by investigating the signs that sunsetting is in an open source project’s imminent future.

How to know when a project is slowing down

There is often a nuance between a project hitting maintenance mode versus one truly sunsetting, and it usually connects directly to support for the project. As we’ve learned throughout this book, open source projects are multidimensional and require not only a strong community but a strong use case and strong investment back into the project. Let’s bring back the sustainability cycle from Chapter 10, Commercialization of Open Source, to better illustrate this:

Figure 14.2 – The Projects, Products, Profits cycle of open source sustainability (https://www.linuxfoundation.jp/wp-content/uploads/2017/09/Virtuous-cycle.png)

A continuous cycle like this naturally means each part of the cycle must be working to keep the entire cycle moving. If one part goes off the tracks, the whole cycle grinds to a halt.

This is a great rubric on how to help identify when a project is slowing down and approaching sunset. Let’s look at each of the Projects, Products, and Profits sections and see some examples and things to look for.

Projects – code velocity and community participation slow down

One of the most visible ways to see a project in decline and trending toward sunsetting is the code velocity (meaning the amount and frequency of code contributions over a certain period), and community participation slowing down significantly. If the project’s user and contributor community declines to a point where there are few active participants, sustaining the project’s development and maintenance may become difficult. If the developers who started the project lose interest or move on to other projects, finding new maintainers willing and able to carry on the work can become difficult. If the project has achieved its goals or completed its intended scope, there may no longer be a need to continue its development. For a project in maintenance mode, such as Apache Struts, which we mentioned previously, that might still be sustainable if the workload for maintenance is low, but often, that isn’t the case.

The OpenOffice project is a good example of an open source project that has been sunsetted due to a declining community. OpenOffice was an open source office productivity suite developed by Sun Microsystems in the late 1990s. The suite included applications such as a word processor, spreadsheet program, and presentation software.

OpenOffice was very popular in its early years and was seen as a major competitor to Microsoft Office. However, in the late 2000s and early 2010s, the development of OpenOffice slowed down, and the project faced challenges such as a lack of funding and a decline in developer interest. In 2011, Oracle, which had acquired Sun Microsystems, decided to discontinue the development of OpenOffice and transfer ownership of the project to the Apache Software Foundation. Apache continued to develop and release new versions of OpenOffice for several years, but in 2016, the project was officially sunsetted due to a lack of active development and a declining user base.

For OpenOffice, there were additional factors that came into play. Back in 2010, when Oracle acquired Sun Microsystems, there were concerns about Oracle’s commitment to the open source community. A group of developers created a fork of OpenOffice called LibreOffice that year, where most of the active community development and energy around an open source office productivity suite went to. We discussed forks in Chapter 2, What Makes a Good Open Source Project?, where we saw that when a project fork and the forks don’t merge back into one project, one project tends to survive because of the lack of resources one fork receives compared to the other. With the community’s energy effectively shifted to LibreOffice, OpenOffice was a prime candidate for sunsetting.

The next part of the open source sustainability cycle is Products – let’s look at signs of a project approaching being sunsetted there.

Products – technology space in decline

If you’ve been around the tech industry for many years, like I have, you’ve seen lots of technology trends come and go. Remember Personal Digital Assistants (PDAs), such as the Palm Pilot? These were supplanted by devices combining the PDA and the smartphone into one. One of the earliest and most popular smartphones was the Blackberry, which is now completely extinct thanks to the Apple iPhone and the ecosystem of Android devices. Thousands of open source projects were tied to the Palm Pilot and Blackberry ecosystems. When those ecosystems fell apart as the technology became irrelevant, even the most active open source community could no longer sustain itself.

If the project is based on outdated technology or is no longer compatible with newer platforms or systems, it may be more practical to discontinue the project and start a new one from scratch. The Camino Web Browser (https://caminobrowser.org/) somewhat fell into this category because while it used the same Gecko rendering engine used by Mozilla Firefox, it used the Mac-native Cocoa API for the user interface, which made it seamlessly fit into the Aqua Desktop environment in the early versions of Mac OS X. As the Cocoa APIs used by Camino became discontinued, combined with the fact that the Mozilla Firefox browser became much more native-feeling and performant on Mac OS X than it had been in late 2001 when the project started, the project decided to sunset. Though instead of starting a new one from scratch, the project started working more in the upstream Mozilla Firefox project to continue improving the support of Firefox on Mac OS X.

Here are two additional examples of open source projects sunsetting due to a decline in their technology space:

1. MeeGo: MeeGo was an open source operating system for mobile devices, tablets, and netbooks that was developed by Nokia and Intel. However, with the rise of iOS and Android in the mobile market, interest in MeeGo declined, and the project was eventually sunsetted in 2011.
2. Google Wave: Google Wave was an open source collaboration platform that was designed to bring email, instant messaging, and document collaboration into a single platform. However, despite early excitement, interest in Google Wave declined, and the project was eventually sunsetted in 2012.

The last part of the sustainability cycle for open source projects is Profits - let’s look at how, when the investment and funding dry up, it becomes harder and harder to keep a project going.

Profits – funding and investment dry up

Open source projects often rely on funding from donations or grants to support their development and maintenance. That funding might be pure cash funding, but it could also be funding in terms of developer and engineering resources, marketing support, and hardware and collaboration infrastructure – these types of funding are often more crucial to an open source project’s success. Simply put, if funding dries up, sustaining the project over the long term can become difficult or impossible.

OpenSolaris was a popular project that attracted a large and active community of developers and users. However, after Oracle acquired Sun Microsystems in 2010, the company discontinued OpenSolaris and announced that it would no longer be releasing updates or new versions of the operating system.

The decision to sunset OpenSolaris was controversial, and it led to the formation of several community-driven efforts to continue developing the code base, such as the Illumos and OpenIndiana projects. However, despite these efforts, the OpenSolaris project as it was originally conceived is generally considered to have been sunsetted.

The sunsetting of OpenSolaris highlights some of the challenges that open source projects can face, particularly when they are tied to a particular company or organization that may be subject to an acquisition or other changes in direction. Despite these challenges, however, many open source projects continue to thrive and make important contributions to the development of software and technology.

Often, funding and investment dry up as a result of changing marketing conditions, but sometimes, it’s related to legal issues that arise that make it difficult or impossible to continue developing and distributing the project. An example is CyanogenMod, a popular open source operating system for Android smartphones and tablets offering features and customizations not available in the standard Android operating system. Android enthusiasts and developers widely used it to create custom ROMs for their devices.

However, in 2016, Cyanogen Inc., the company behind CyanogenMod, announced that it was discontinuing the project and would no longer provide updates or support for the software. The decision was reportedly made due to a dispute between the company and its hardware partners and concerns about potential legal issues related to the use of proprietary software and APIs.

Following the shutdown of CyanogenMod, the community of developers and users who supported the project continued to work on a new open source Android operating system called LineageOS, which aims to provide similar features and customizations while remaining fully open source and community-driven. Today, LineageOS is widely used by Android enthusiasts and developers and continues to receive updates and improvements from its community of contributors.

Now that we’ve looked at the signs of a project slowing down and on the path to sunsetting, let’s look at how to sunset a project.

The sunsetting process

Sunsetting an open source project is a difficult decision for a community. Making that decision requires the involvement of all active community participants, from maintainers to end users. In this section, we will look at the steps leading up to sunsetting; then, we will look at the step after the sunset officially happens.

Let’s get started with the first step in sunsetting a project: making sure everyone agrees it’s the right idea to do so.

Aligning on sunsetting in the community

If the project has a community of developers, it’s important to involve them in the decision-making process and to encourage them to take on the responsibility of maintaining the project or forking it to create a new project. This can help ensure that the knowledge and expertise invested in the project are not lost.

Sometimes, a community gets small enough that aligning on sunsetting isn’t hard. Getting the remaining community members together and discussing the state of the project and their interests can resolve things easily. I went through this while president of the OpenSocial Foundation back in 2014; at that time, with just SugarCRM, IBM, and Jive Software as members, they saw that their product directions weren’t aligning with the work happening in the related projects and were able to quickly decide when to sunset the foundation and work (transitioning what was left into standards work in the W3C) made the most sense. That is a smooth sunsetting process… haha.

Not all sunsetting processes are smooth, especially when there might be competing interests or developers finding personal attachment to their work or the project itself. An example of this is the Ubuntu Unity desktop environment, a Graphical User Interface (GUI) developed by Canonical, the company behind the Ubuntu Linux distribution. It was designed to provide a modern and user-friendly desktop environment for Ubuntu users, with features such as a launcher and dash for accessing applications and files.

In 2017, Canonical announced that it was discontinuing Unity and shifting its focus to other areas, such as cloud computing and the Internet of Things. While Canonical pledged to continue providing security updates for Unity for several years, the discontinuation announcement was met with resistance from some members of the Ubuntu community. A group of Unity users and developers formed a community-driven project called Unity8, which aimed to continue developing and improving the Unity desktop environment as an open source project. However, despite the efforts of the Unity8 community, the project has struggled to gain traction and attract new contributors. The project was renamed Lomiri and is trying to regain community momentum as of this writing. This is a great example of the challenges that are faced when the business interests in sunsetting an open source project aren’t considered alongside the community interests and the wider impacts on the community around the project.

Once a project community aligns on sunsetting, the next step is to announce that sunsetting is going to take place. Let’s look at that now.

Announce intent to sunset

When a project is sunsetting, the project maintainers must communicate this decision to the community. This can involve announcing the decision on the project’s website, mailing list, or social media channels. While there are multiple ways to provide notice, two primary considerations should be part of any intent to sunset announcement:

1. Provide ample notice: As soon as the decision to sunset the project has been made, you should provide ample notice to end users. This will give them plenty of time to plan for the transition and find alternatives.
2. Communicate clearly: When communicating with end users, it’s important to be clear and transparent about the reasons for the sunset and what they can expect in the coming months. It can also be good to provide regular updates and answer any questions or concerns from end users; often, a project doesn’t consider all the impacts sunsetting might have on a community, and being able to address those concerns helps make the process smooth.

An example of a project doing a great announcement of its intent to sunset was Firebug, which was an open source web development tool that allowed developers to inspect and edit HTML, CSS, and JavaScript code in real time. Web developers and designers widely used it to debug and optimize web pages.

In 2017, the developers of Firebug announced that they would be discontinuing the project and recommending users switch to the built-in web development tools provided by modern web browsers. Figure 14.3 illustrates them updating their website to announce the project’s sunset:

Figure 14.3 – Firebug home page announcing it’s been sunsetted (https://getfirebug.com/)

The Firebug announcement is good; it’s clear and appreciative of the community’s support and helps direct users to projects and tools that they should consider migrating to. This leads to the next part of the sunsetting process: helping end users transition.

Work with end users on transitioning

Looking at the Firebug project, part of informing the community of the intent to sunset is to provide guidance on how they can continue to use the project or migrate to alternative solutions. Even though a project is sunsetting, that doesn’t preclude users still using it and maintaining it themselves; as we said at the beginning of this chapter, once code is out under an open source license, that is a permanent move. But more often than not, end users will want to move to a different solution.

Here are a few steps that you can take to work with end users during the sunset process:

1. Offer alternatives: As the sunset process progresses, work with end users to identify alternatives that they can use to replace the project. This may involve recommending other open source projects or commercial offerings.
2. Provide migration support: Depending on the complexity of the project, end users may require support with migrating their data and workflows to a new solution. Work with them to provide documentation, tools, and resources to help with this process.

Firebug primarily directed their users to the Firefox Developer Tools, which heavily borrowed from the concepts used in Firebug. Firefox created a wiki page guide to help users with the migration, mostly helping the end users find the features they used in Firebug in the Firefox Developer Tools:

Figure 14.4 – The Migrating from Firebug guide in the Firefox Source Code Tree documentation (https://firefox-source-docs.mozilla.org/devtools-user/migrating_from_firebug/index.html)

Firebug provided a clear path for users to migrate to alternative tools while ensuring that the project’s code and documentation remained accessible to the wider community.

Once a project has been sunsetted, there is work to do when closing shop for the project. We’ll look at this in the next section.

What comes after sunsetting?

Post-sunsetting, the primary responsibility is to make it clear that the project is no longer maintained and ensure the project’s assets have a long-term home. Sometimes, we see projects come out of being sunsetted or parts of the code base being incorporated into future projects or used when legacy applications need to be ported to new platforms in the future. We’ll look at what a project should do in this section.

Mark code repositories and issue trackers as archived

Right after sunsetting a project, it’s crucial to clarify the project’s status. This involves archiving the project’s code and documentation in a public repository so that users and developers can still access it in the future. This can be especially important if the project significantly impacts the open source community.

Here are some best practices for marking code repositories when sunsetting an open source project:

1. Add a notice to the repository’s README file: The README file is often the first thing that users and contributors will see when they visit your project’s code repository. Adding a notice to this README that explains that the project is no longer being actively developed or maintained can help to prevent confusion.
2. Use a “deprecated” or “archived” label: Many code hosting platforms, such as GitHub, allow you to mark repositories with labels that indicate that they are no longer being actively developed. Using labels such as “deprecated” or “archived” can help make it clear that the project is no longer being actively maintained.
3. Add a note to the repository’s description: Adding a note to the repository’s description that explains that the project is no longer being actively developed or maintained can help prevent confusion.
4. Consider redirecting users to alternative solutions: If there are alternative open source projects that users can use instead of your project, consider adding links to those projects in your repository’s README or other documentation. This can help users find alternative solutions that meet their needs.

Note that this doesn’t have to be complicated for a project to do, but as we stated earlier in this chapter, it should be clear. Let’s look at the SceneJS project (https://github.com/xeolabs/scenejs) and how it makes it clear the project has been sunsetted:

Figure 14.5 – The SceneJS README file announcing the project is no longer maintained (https://github.com/xeolabs/scenejs#readme)

Here, you can see that all the key pieces of information were conveyed; that it’s no longer maintained, why it was sunsetted, and where users can go for a similar solution.

In addition, a project should ensure any related tools or services are shut down. Here are some things to consider:

1. If the project had any associated services, such as a website, social media accounts, or discussion forum, make sure to deactivate them or redirect them to an alternative solution.
2. If the project received funding, close down any accounts or arrangements associated with that funding. If funds are left over, consider donating them to one of the projects that was recommended end users migrate to.

After sunsetting, the project having a long-term home is important from both a user support perspective as well as a historical one. Let’s look at that now.

Find a home for asset ownership

Open source projects usually have two types of assets: the code and documentation, and the project’s name and logo (known as the marks). For code and documentation, many of the open source code hosting platforms have archiving programs and policies for open source projects; GitHub has its Archive Program (https://archiveprogram.github.com/), which is a good example here.

For a more comprehensive solution, several organizations can serve as neutral third parties for open source project trademarks, including the Software Freedom Conservancy, the Free Software Foundation, The Linux Foundation, and the Open Source Initiative. It’s crucial that when an open source project sunsets, the trademarks associated with the project can be managed consistently with the project’s goals and values. Organizations such as those just mentioned are well known as stewards of open source projects. Additionally, they can manage the hosting of websites and credentials to code repositories in case the last maintainers cannot be reached.

Transferring the trademarks to a third party ensures that they are not used in ways inconsistent with the project’s open source principles or could harm its reputation or legacy. For example, if the trademarks associated with an open source project were transferred to a for-profit company that did not share the project’s values, the company could use the trademarks in ways that were not in the best interests of the project or its community.

The goal when handling open source project assets after sunsetting should be to ensure that the work is preserved for future use and that users and contributors are informed of the project’s status and any alternative solutions that may be available.

While sunsetting is the last stage in the life cycle of an open source project, that doesn’t mean it’s the end. Projects can come back from being sunsetted; let’s look at how.

Can a project come back from sunsetting?

Yes, an open source project can come back after it has been sunsetted, although it depends on the reasons why the project was discontinued in the first place. If the project was sunsetted due to a lack of funding or developer interest, it might be possible for new funding or developers to come forward and revive the project. In some cases, the project may be forked by other developers or organizations who want to continue its development under a new name or with new features. This can result in a new community forming around the project, with new contributors and users.

Generally, there are two paths to a project coming back from sunsetting:

1. Handing over the project to a new maintainer who can continue to develop and maintain it
2. Forking the project to create a new project that can continue to evolve and meet users’ needs

However, it’s important to note that bringing back a sunsetted project can be challenging, especially if the original project had a large and active user base that has moved on to other solutions. The new project must demonstrate its value and relevance to the community, and it may take time to rebuild momentum and attract new contributors. The Unity8/Lomiri project story discussed earlier in this chapter is a good example of the challenge of bringing back a project from being sunsetted. While a sunsetted open source project can come back, it’s important to carefully consider why the project was discontinued in the first place and have a clear plan for how to address those challenges if the project is revived.

Summary

In general, the decision to sunset an open source project can be a difficult one, and it is important for the project maintainers to communicate the decision clearly and to provide guidance to users on how to migrate to alternative solutions. However, in some cases, sunsetting a project may be necessary to ensure that resources are used effectively and that the project’s legacy is preserved.

Do note that sunsetting an open source project doesn’t equate to the failure of an open source project; when we looked at many of the project examples in this chapter, we saw they all had a significant impact in their primes, but conditions changed, which led to a sunset. And note that even though a project was sunsetted, it doesn’t mean it didn’t impact the future. For example, despite its eventual sunset, OpenOffice was an important open source project that helped promote free and open source software in the office productivity market. The project also inspired the development of several other open source office suites, such as LibreOffice and Calligra.

It’s fitting that we close this book by talking about sunsetting an open source project. But as we covered, putting code out under an open source license is a permanent action; having an open source project isn’t. I hope this chapter showcased that while projects can end, the code and work can continue to live on.