uuid: - value: 53d1af45-bb51-4e4a-a2b9-b732bc9dc8ea langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:10+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: 'Dead or done' created: - value: '2024-06-14T00:00:00+00:00' changed: - value: '2025-05-11T09:00:10+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2024/06/14/dead-or-done langcode: en body: - value: |

Yesterday, I wrote about some things I look for when evaluating open-source projects.

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.

format: full_html processed: |

Yesterday, I wrote about some things I look for when evaluating open-source projects.

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.

summary: null field_daily_email_cta: { }