Over the years, I’ve used a number of open source libraries in many different domains and languages. During that time, I’ve observed a couple of emerging patterns that have devolved some of these libraries into oblivion: _feature proliferation_ and _stagnation_.
Feature proliferation can lead to software bloat while having features that almost no one uses. Conversely, stagnation can lead to installation and integration issues where your users either abandon or recreate your library.
It’s Okay to Stop Adding Features
It is very tempting to contrive new features in order to give the appearance that your project is still “active.” You need only go to a GitHub project page to see how long ago someone committed.
Lack of activity can be a smell that indicates that a project has been abandoned. However, if you aren’t letting your library stagnate you’ll probably find yourself periodically updating the library—even if they are just minor updates or bug fixes.
You should have a particularly strong opinion about the intent of your library and how it is implemented. Don’t be afraid to disagree with feature requests, close pull requests, or reject patches.
If the feature request does not align with the values or intent of your library, don’t be afraid to say, “No.” Additionally, if someone submits a feature but the implementation is poor or not your standards, you should feel empowered to reject it.
Single Responsibility Principle
Your library should be very good at the need or problem your library addresses. It should not try to appease everyone or address needs that are outside of its core competency. Create a new library if a new need arises (it could, gasp, use your other library!). It’ll keep your library uncomplicated, and its identity will stay intact.
Don’t Be Afraid of Being Dumped
There may come a time where your library is abandoned in favor of another library (and not because you let it stagnate). That other library might encourage or allow for patterns that you disagree with. Don’t adopt anti-patterns for the sake of keeping users that want to do bad things.
There may also come a time where another library solves the same need or problem in a better way than your library does. It is okay to move on and encourage your users to adopt the new library.
Ensure Your Library Works and Integrates Well with Modern Platforms
The death knell for any library is when it no longer works on whatever platform it was originally intended for. Whether it was built to work on a particular operating system or framework (Rails, for instance), if the library no longer compiles or functions as it was intended to, you’ll probably find your library replaced or abandoned.
Additionally, it’s important to integrate and adopt modern platform features. For instance, a new version of a language may have added new features and standard libraries that your library can utilize.
Objective-C recently added support for object subscripting, which means that if your library had a feature like
[myLibrary getObject:@"The Key"] you could enhance the library by adding support for subscripting (
Fix Your Broken Windows
Users tend to not trust libraries that are full of deprecation or compiler warnings. This gives the appearance that your library doesn’t work as advertised and that it isn’t maintained. Because your library is free, users have to be careful and deliberate when choosing third party libraries or risk having to maintain or patch the library themselves.
Get Help if You Need It
Many of us work in many different domains and languages (this especially true for Atomic Object), and it might be difficult to find time to maintain your library. Find people that you trust — who think like you, write code like you, and will defend your library from harm :-) — and allow them to help you maintain the library when you are too busy or disconnected from the particular domain or language it was created in.