Revisiting Old Open Source Projects in 2025
A lot can change in five years. I recently realised I hadn’t opened my GitHub profile in almost three years. Part of the reason was that notifications stopped working properly at some point. I remember one day being flooded with random spam notifications… and then suddenly stopped receiving anything at all, after setup notifications. Not the best experience when you’ve got 20+ projects to maintain.
Moreover, life gets busy, so these things happen. In 2025 I decided it was time to revisit my projects there, one at a time.
The first question I had to ask myself was simple: which projects are worth keeping maintained, and which should be archived?
This article shares some general ideas that helped me to decide. Hopefully they will be useful to you too.
How to decide what to keep
My goal in 2015, 2020 and 2025 remains simple and straightforward: to share solutions and ideas that solve real challenges in the frontend or full-stack development world.
Here are three simple steps that I find useful:
-
Is the project still relevant?
- Does this project solve a problem that developers still have today?
- Can I reasonably expect other projects to benefit from it in 2025 and beyond?
-
Scope and context
- What exactly does the tool do?
- What doesn't it do, and what shouldn't it try to do?
- A clear, focused scope makes it easier to maintain and easier for others to understand.
-
Simplicity and usability
- Keep usage simple: the most common use cases should be easy to understand from the 'README'.
- Provide enough context in the documentation:
- Why does this project exist?
- When should someone use it (or not use it)?
- Try to avoid “clever” APIs, fix-it-all tool, if they make the learning curve steeper for no real benefit.
If a project scores well on relevance, scope, and usability, it is usually a good candidate to keep, polish, and improve rather than archive.
How to maintain it
Once you have decided a project is worth keeping, the next question is: how do you maintain it realistically?
-
Set a realistic timeline
- Decide how often you can look at the project (monthly, quarterly, etc.).
- It doesn't have to be perfect; it just has to be sustainable for you.
-
Be transparent about updates
- Don't let all communication live only in the GitHub repo and the NPM registry.
- Share updates somewhere else too, for example:
- Dev.to posts
- LinkedIn updates
- A short changelog in the README
- This helps people understand whether the project is still active and what's changing.
-
Minimise product-based dependencies
- Aim for zero or minimal third-party product dependencies where it makes sense.
- This reduces the surface area for security issues and version conflicts.
- In 2025, this still feels like a solid approach for JS/TS and Node.js projects, especially for small libraries and tools.
-
Follow software development best practices
Even for small open source tools, a little bit of discipline makes a big difference:- A clear release cycle definition (even if it's “when needed, but documented”).
- Automated tests for the core functionality.
- CI/CD pipelines (e.g. GitHub Actions) for tests and releases.
- Linting and formatting rules to keep contributions consistent.
- Documentation updates with each release so users aren't guessing.
- Semantic Versioning (SemVer) and Git tags for every release so people can rely on versioning.
You don't have to implement everything at once, but having these as a long-term checklist can really help keep the project healthy.
So… is it worth it?
If you're a frontend or full-stack developer wondering:
“Does it still make sense to revive or create open source projects in 2025?”
My answer is still: yes.
It just needs to be more intentional:
- choosing what is worth maintaining,
- keeping the scope / context clear,
- and treating even small libraries with a bit of professional care.
This is the first article in a small series about revisiting old projects and open source maintenance in 2025.
More on that in the next parts.
Top comments (0)