当你在GitHub这样的开源仓库中漫游时，总会偶然发现一些标题类似上述问题的未解决事项。它们可能静静地存在，无人问津，偶尔会有维护者留下的评论和一串“我来帮忙！”的回复，但这些承诺往往从未兑现。而极少数情况下，你会看到一个已关闭的问题，似乎有了圆满的结局。
这些问题总让我着迷，因为它们揭示了开源项目维护的深层含义，继任问题，以及用户、贡献者和维护者之间的期望落差。最近，我也在考虑如何提前预防这类问题，主动提出自己的问题答案。
创建此类问题的原因
作为开源软件的生产者和使用者，我能理解人们想知道项目是否被放弃的需求。知道有人在背后支持，有问题能寻求帮助，哪怕回应机会不为零，这让人安心。而且，如果维护者对软件仍有兴趣，他们可能会修复兼容性问题或重大bug。
然而，背后常常隐藏着误解：认为维护的开源项目意味着某种权利，即期待你的问题、bug报告和功能请求能得到某种程度的关注。这种观念源于许多活跃的开源项目，志愿者们慷慨地回答问题、修复bug，甚至实现并非他们个人需求的功能。如果你有过这样的用户体验，自然会期待所有开源项目都能如此。
然而，这种情况实属罕见。大多数情况下，所谓的“维护”与正式声明的“弃用”在实际操作上并无太大区别。贡献者（通常是单人）可能没有足够的时间或意愿及时有效地回应你的问题。即使维护者声称仍在“维护”，遇到问题时，你仍需要自己动手解决。
思考与行动
考虑到这一点，我一直在思考如何提前解决问题，为我发布的项目给出明确的答案。我创建的项目很少有活跃的社区，甚至可能从未收到过外部的Pull Request或问题。最后的更新日期可能已经很久以前。
从大多数标准来看，我的大部分仓库看起来都像是“被弃用”的。但对我来说，它们并不感觉被弃用。我仍在使用这些代码，有时每天都会用到，如果有问题，我会自己修复。任何需要我开发功能的人可以使用代码，且基本可以确信它能满足README中的描述。
我正在考虑在我的所有仓库中创建一个名为“项目还在维护吗？”的议题，将其固定在问题列表中，并附上我正在构思的“开源维护者宣言”。
宣言大致如下：
项目还在维护吗？
是的，也许，实际上可能不是。确切地说，这取决于你对“维护”的定义。
我为自己的便利编写了这个软件，以解决我遇到的问题。虽然我可以保留它，但我选择公开发布，遵循开放许可，希望它对他人有用，但不保证任何服务。
感谢他人的慷慨，你使用、修改和重新分发这个项目几乎无需付出任何代价，尽情享受吧！
好吧，那维护呢？
从某种意义上说，这个软件始终在“维护”。我会处理烦人的bug，升级依赖以防出现问题，添加我需要的新特性。如果正在进行任何持续的开发，那是因为我自愿这么做。
然而，如果你认为“维护”包括回答问题、修复bug、升级或新功能，你可能会有些失望。那些是“支持”范畴，如果你想获得支持，可能需要签订支持合同，支付费用，我才会帮你解决你需要解决的问题。
这不公平！
如果你觉得好受些，你有权：
- 根据适用的许可证条款，使用、研
