Having written in previous blog posts about how to create an Android library, how to make it open source and how to distribute your library, we wanted to round off the series with a look at how to finish a project in style.
The original plan had been to have further articles on how to publish it, advertise it and draw up a future roadmap. However, plans change, so instead this is a brought-forward article on how to end the whole thing and, most importantly, how to bring it to an end gracefully. (The original series roadmap can be found at the end of this article so you can see where we were planning going to go).
Why stop now?
The main focus of this article is about how to stop an Open Source project well, rather than why you might want to stop, but I guess it’s a fair question to ask.
In general, there are a plethora of reasons why it might be time to call it a day on your Open Source project (click here for deciding when to end, transfer, or pull out of a project for various reasons and general good advice about winding down projects or transferring ownership).
For us, around about the end of Nov 2016, Google published a blog post called “Keeping it real: Improving reviews and ratings in Google Play” which we wholeheartedly agree with. In fact, it made us question the existence of the RateTheApp library and so in June 2017, we published this notice prominently on the GitHub Project Readme, giving warning to users that we were no longer actively developing it.
It’s easy to stop a project; for example, you can just delete it straight away with no notice, but there are better ways to finish. To see an example of how not to do it, you can read this post about how deleting a project almost broke the Internet!
At the other end of the finishing spectrum, did you know that Internet Explorer 11 is still supported by Microsoft (even though most right-minded people think it should have been put out to pasture years ago). It'll still be going until 2025 - that’s quite a support commitment!
So how do you gracefully end a project? A couple of main points to consider:
- Communicate your intentions clearly and early
This is a matter of trust and protecting the reputation of your brand or company. You still want your customers to trust you, don’t you?
If you aren’t clear, your customers will have to second guess what your plans and motivations are, and they’ll probably assume the worst!
If you don’t communicate early, you won't give your customers enough notice to change what they do (remember, they are probably dependent on you).
To build trust, your customers need to know what you are planning and with enough notice that they can prepare themselves for your changes (or find alternative solutions).
- Allow your customers to carry on using it as-is
Just because you no longer have use of the project, it doesn’t mean it isn’t a vital part of what they do.
Don’t force change upon them. Letting them choose when to move away or adapt to the change means you are less likely to break the thing they do.
For our RateTheApp library, as soon as we realised we weren’t going to be working on it any longer, we posted the notice announcing the project was not being actively developed any longer and why we came to that decision. This gave our customers notice of our intentions without stopping them from using it if they found it helpful.
18 months later we have just archived the project rather than deleting it (see the GitHub screenshots below for archiving a project), so it can still be forked, or starred, just not changed. Our customers can still use it if they want to, we have just moved on from it. Hopefully, we have finished well.
So long and thanks for all the fish!
Many thanks to all of you who have stuck with us from the beginning and who have helped shape RateTheApp and this blog series. Thanks to Google for giving us the insight into why stopping it might be a good thing too!
For reference, I’ve included below our original roadmap for the remainder of this series, so if you are in the process of creating an Open Source library, these might give you some ideas to think about.
Original series roadmap
Rate The App - Blog Part 4: Building trust - the stability of your project & maintenance
- Add new functionality (without breaking things)
- Use GitHub releases - https://help.github.com/articles/creating-releases/
- Importance of release numbering and tagging - http://semver.org/
- Tests provide confidence and stability.
Rate The App - Blog Part 5: Publishing Library
- Publish Demo App to Play Store
- Update README file
Rate The App - Blog Part 6: Advertising library
- Using GitHub Pages to advertise your repository/library
- Display readme on blog
Rate The App - Blog Part 7: The Future
- Work through suggestions here.