36 lines
1.6 KiB
Markdown
36 lines
1.6 KiB
Markdown
---
|
|
title: Dead or done
|
|
date: 2024-06-14
|
|
permalink: daily/2024/06/14/dead-or-done
|
|
tags:
|
|
- software-development
|
|
- open-source
|
|
cta: ~
|
|
snippet: |
|
|
How do you know if a project is dead or feature complete?
|
|
---
|
|
|
|
Yesterday, I wrote about [some things I look for when evaluating open-source projects][0].
|
|
|
|
One thing I said was "When was the most recent commit and release?".
|
|
|
|
If a project hasn't had many recent commits, it could be outdated or no longer supported.
|
|
|
|
Alternatively, it could be considered feature complete and not getting new features, and only getting bug fixes and maintenance updates.
|
|
|
|
I see this a lot with Vim plugins that were written several years ago and are now minimally maintained and updated, but getting no new features.
|
|
|
|
This happens in the Drupal space, too, when people wrote a module for a project which they have since completed, or no longer work with that client or for that company.
|
|
|
|
If there are at least commits for security compatibility, such as new versions of PHP or node, that's a sign the project is in a maintenance phase.
|
|
|
|
If there are no recent commits, the project could be dead and I'd carefully consider if you want to add or use it.
|
|
|
|
Something that could help is if maintainers are explicit about what state their project is in.
|
|
|
|
Add a note to the README.md or CONTRIBUTING.md file saying if the project is feature complete or what the maintenance state is.
|
|
|
|
If the project is no longer maintained, you can also document it and potentially archive the repository too to show that it will no longer be updated and to avoid confusion.
|
|
|
|
[0]: {{site.url}}/daily/2024/06/13/vetting-third-party-open-source-software
|