Add daily email for 2024-06-14

Dead or done

run.local

@@ -77,7 +77,7 @@ function publish {
   generate
 
   rsync --archive --verbose --compress --update --delete \
-    output_prod/ ssh.oliverdavies.uk:/srv/oliverdavies.uk-sculpin
+    output_prod/ ssh.oliverdavies.uk:/srv/www.oliverdavies.uk
 
   git stash pop
 }

source/_daily_emails/2024-06-14.md

@@ -0,0 +1,33 @@
+---
+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.