开源项目维护的那些不为人知的事
我分享了项目，GitHub上收获了些许星标。人们真的在使用它。当有人告诉你正在使用你亲手打造的东西时，那种感觉？难以置信。
起初
开发kaneo的过程充满乐趣。一个简洁的看板工具，自主托管，开源无门槛，没有追踪功能，无需订阅，毫无花哨。
发布v1版本后，我在Reddit分享了项目，GitHub上收获了些许星标。人们真的在使用它。当有人告诉你正在使用你亲手打造的东西时，那种感觉？难以置信。
随后我才明白：发布只是开始。
文档挑战
我耗费数小时撰写文档：安装指南、配置示例、故障排除章节，力求清晰全面。
但问题在于：用户背景各异。对我而言显而易见的功能，对初次安装者却未必如此。
有人提交问题：“怎么安装这个？”
我的第一反应是懊恼——读我文件里写得清清楚楚啊！但转念一想：或许读我文件假设了太多前提。也许对方是Docker新手，也许他们来自Windows环境，对Linux一无所知。
于是我完善了文档：
- 增加更多示例
- 创建故障排除指南
- 制作视频演示
- 新增“常见问题”章节
这是个持续的过程。文档永远没有“完成”之日。
技术支持即是产品开发
维护kaneo意味着帮助用户调试环境。坦白说？这让我收获远超预期。
人们在各种意想不到的环境中运行kaneo：
- 企业代理服务器后端
- 树莓派集群
- 在自定义网络的Kubernetes环境中
- 在资源有限的NAS设备上
每份支持请求都揭示了我曾有的误判。每个“无法运行”的反馈(即使缺乏细节)都指向我未曾考虑的故障模式。
挑战在于时间平衡。我渴望帮助每个人，但同时还有本职工作、待开发的新功能和待修复的漏洞。
我仍在学习如何在提供帮助的同时设定边界。
功能请求令人谦卑
人们希望Kaneo能实现更多功能。这太棒了！说明他们真正使用着它，并怀着期待构想它的未来。
但每个功能请求都意味着抉择：
- 是否符合产品愿景？
- 能否长期维护？
- 会否增加代码复杂度？
- 实现它会挤占哪些其他功能的开发资源？
拒绝很难。尤其当请求经过深思熟虑且理由充分时。尤其当有人主动提出协助实现时。
我学会了坦诚相告：“这个想法很棒，但超出Kaneo的规划范围。原因如下…”
多数人能理解。少数人不解。这没关系。
迁移过程令人胆战心惊
数据库架构亟需重构。现有设计已显局限，新架构能实现用户期待的功能。
但当时已有200多人将Kaneo投入生产环境——承载着他们真实的工作数据和团队工作流程。
若迁移失败，他们将失去信任，可能丢失数据，更会彻夜难眠。
因此我：
- 编写迁移脚本
- 回溯至v1版本逐一测试
- 撰写详细升级说明
- 验证边界案例
- 验证边界案例的边界案例
- 添加验证检查
- 启用干跑模式
发布后屏住呼吸。
多数迁移顺利完成，少数出现问题。并非用户未阅读说明，而是他们配置了无法预见的场景：
- 修改过的数据库
- 自定义补丁
- 从未见过的运行环境
我们共同调试，他们耐心相待，我心怀感激。
每次迁移都让我领悟防御性编程的新要义。
贡献者是珍贵的礼物
当有人提交PR时，那份心意令人动容。有人愿意投入时间完善kaneo。
但整合贡献比预期更艰难：
- 编码风格各异
- 对架构的假设不同
- 对kaneo发展方向的构想相左
有时PR完美无缺，有时需要打磨，有时解决问题的方案反而会埋下隐患。
我学会了：
- 永远珍视这份付出
- 提出修改时阐明理由
- 坦然接受“这次不合适，但感谢你的贡献”
- 若修改方向接近，有时直接自行完善
那些持续参与的贡献者？他们令人惊叹。正是他们让Kaneo超越了我独自能达到的高度。
环境的多样性
自主部署意味着用户在各种场景运行Kaneo：
# 笔记本上的Docker
docker compose up -d
# 工作环境的Kubernetes集群
kubectl apply -f kaneo.yaml
# 家庭实验室的树莓派
# (1GB内存承载梦想)
# 老旧服务器的裸机环境
# (自2015年持续运行至今)
# 搭载ARM处理器的NAS设备
# (我甚至从未听说过的型号)
每个环境都教会我新知识。每条“我的环境无法运行”的反馈，都揭示了我对系统运作机制的固有假设。
我无法测试所有环境，但能让kaneo更具韧性：
- 优化错误提示
- 增强日志清晰度
- 实现更优雅的故障处理
那些在奇葩配置上运行Kaneo的人？他们往往最乐于助人。他们深谙自身环境，提供详尽日志，测试修复方案。
我们携手攻克难题。
保持文档鲜活
文档永无终结。每个功能都需要文档，每次修复可能需要文档，每个疑问都揭示文档的缺口。
我已养成以下习惯：
- 代码变更时同步更新文档
- 将“文档错误”问题列为高优先级
- 感谢用户提交文档修正
- 接受文档永远无法完美
目标并非追求完美文档，而是打造能持续帮助多数人的实用文档。
当文档失效时？那便是改进的契机。
比较性问题
“为什么不用 Trello/Notion/Linear 呢？”
这是个合理的问题。这些工具确实优秀：拥有工程师团队、设计师团队、产品经理团队，界面精致，响应迅速，功能丰富。
Kaneo 则不同：
| 它们 | Kaneo |
|---|---|
| 云托管 | 自托管(数据归你，服务器由你掌控) |
| 闭源 | 开源(代码行行可查) |
| 功能丰富 | 精简(专注做好一件事) |
| 订阅制 | 免费(自由如啤酒) |
它并非更优，只是不同。对某些人而言，这种差异至关重要。
坦白说？开发 kaneo 带给我的收获远超使用那些工具。
情感真相
维护开源项目如同坐过山车：
有人给你的仓库点赞 → 心情愉悦
有人提交附带日志和复现步骤的详细 bug 报告 → 欣喜若狂
有人说“kaneo 拯救了我们团队” → 震撼不已
有人开题为“这破玩意儿”的 issue → 痛彻心扉
你花周末实现新功能 → 寂静无声
修复小bug → 三人道谢
发现数月未推进个人计划 → 身心俱疲
收到精心PR → 终于不孤单
高峰汹涌，低谷深邃。但那些使用kaneo、贡献代码、心系项目的人们？正是他们让这一切值得坚持。
我的领悟
1. 范围即一切
kaneo只做一件事：看板管理。不做项目管理。不做工时追踪。不做团队聊天。
每个新增功能都意味着永久维护。
明确范围并非束缚——而是解放。它让你专注。让你能毫无愧疚地说不。
2. 尽可能自动化
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
test:
- run: npm test
security:
- run: npm audit
release:
- run: semantic-release
自动化并非偷懒，而是可持续之道：
- 自动化测试在用户发现前捕获缺陷
- 自动化发布减少人工操作
- 自动化安全扫描带来安心保障
- 自动化依赖更新保持系统前沿
它让你专注于真正重要的事。
3. 优质问题模板惠及所有人
GitHub问题模板帮助用户提供：
- 系统信息
- 错误日志
- 复现步骤
这并非设置门槛，而是为调试创造可能。多数人乐于协助解决问题，模板能让协作更顺畅。
4. 拒绝是种尊重
不可能包揽所有事务。事事应允终将一事无成。
坦诚告知能力边界，是对彼此时间的尊重——包括你自己的。
5. 用户即是协作者
使用 kaneo 的人不仅是用户，更是：
- 发现漏洞的测试员
- 填补空白的文档编辑
- 分享创意的功能设计师
- 互助互助的社区建设者
他们并非苛求，而是积极参与——这本身就是馈赠。
当有人提交问题时，他们正在为改进Kaneo投入时间。即使问题描述不够清晰，其初衷仍是善意的。
耐心与善意不仅是美德，更是必需品。
真实情况
维护开源自托管项目意味着：
- 比开发本身更耗费精力
- 带来不同于开发的乐趣
- 比预期更具成就感
- 比预期更具挑战性
- 绝对值得付出
你将收获：
- 技术能力(迁移、安全、可扩展性)
- 人际能力(沟通、耐心、边界设定)
- 产品能力(优先级排序、范围把控、愿景规划)
- 如何珍视每份贡献
- 如何打造真正受用户欢迎的产品
我的实际配置
┌─────────────────────────────────────┐
│ kaneo infrastructure │
├─────────────────────────────────────┤
│ github │
│ ├─ code + issues │
│ ├─ actions (ci/cd) │
│ └─ container registry │
│ │
│ hetzner ($7/month) │
│ └─ cloud instance │
│ │
│ cloudflare (free) │
│ └─ dns + ddos protection │
│ │
│ plausible │
│ └─ privacy-friendly analytics │
│ │
│ coffee (priceless) │
│ └─ way too much │
└─────────────────────────────────────┘
给过去自己的忠告
1. 尽早投入文档建设——优质文档能减轻支持负担并助力用户成功，这是值得投入的时间。
2. 从第一天就实现自动化——测试、发布、安全扫描。自动化能扩展，而你不能。
3. 明确项目边界——既要说明项目涵盖什么，也要说明不涵盖什么。这对所有人都有益。
4. 数据库迁移值得额外投入——充分测试。添加回滚机制。撰写清晰的升级说明。用户将数据托付于你。
5. 慢一点没关系——你不是公司，而是个人。设定合理预期。适时休息。守护你的精力。
6. 致敬用户——每位使用kaneo的人都了不起。他们选择信任你打造的产品，这本身就是奇迹。
7. 社区即产品——代码固然重要，但人更重要。请双管齐下。
结语
我会重来吗？
当然会。
kaneo的诞生源于我对简单看板工具的渴望。但它已超越初衷：成为一群珍视隐私、崇尚简约、坚持自主掌控工具的人们的家园。
维护工作是真实存在的。迁移过程令人焦虑。技术支持耗费时间。
但人们正用kaneo：
- 经营企业
- 管理副业项目
- 组织团队协作
- 学习自主托管
他们发来感谢信，提交详尽的错误报告，贡献代码，在讨论中互相扶持。
这不仅令人欣喜，更是我坚持的初衷。
本文文字及图片出自 What They Don't Tell You About Maintaining an Open Source Project
> 维护kaneo意味着帮助人们调试他们的配置。说实话？它教会我的远超预期。
> 人们在各种我从未想象过的环境中运行kaneo：
> 企业代理服务器后端
> …
> 在自定义网络的Kubernetes环境中
这是原作者的项目，他们当然有权选择支持对象。但我绝对不会为明显进行商业用途的用户提供免费支持，尤其是在大型企业中。
既然是开源软件，他们当然可以免费使用，但若需要定制支持或功能，这类用户正是最佳对象——完全可以告诉他们：“没问题，只要购买每年500美元的支持合同，我很乐意提供帮助。”你会惊讶于有多少客户根本不在乎费用，因为他们手握公司信用卡，这点金额根本无需审批或繁琐流程。
事情远非表面那么简单。就在昨天，我与荷兰代尔夫特理工大学通话时，对方要求我在开源产品的免费版[1]中添加功能，却拒绝支付任何费用。上个月我与某市值8000亿的上市公司接洽，涉及每年1800美元的账单。双方初步达成共识后，对方不断追加要求：先是要求签署大量安全检查清单和法律文件耗时数日，随后又提出可能耗时数周的额外需求。我建议他们通过合同形式追加服务，此后便再无音讯，自然也分文未付。从政府机构到F500企业，类似案例不胜枚举。在我所处的领域，付费支持计划主要适用于美国实体。
[1]: https://github.com/mickael-kerjean/filestash
高校属于特殊情况。它们通常因繁文缛节而不敢轻易支出。
而在美国企业界，100美元左右的支出通常无需报销凭证，因此每月50美元的技术支持订阅很容易就能买到。
关键是要找到持有采购卡的人。
根据我服务麻省理工学院和加州大学欧文分校的经验，美国高校处理简单低价事务的流程极简甚至无需审批。反观法国某知名工程学院(ENSEEIHT)，他们虽需要技术支持，却对每月20美元的维护费嗤之以鼻，明显想以远低于最低工资的报酬占用我的时间。昨日德国某院校同样如此——求助却分文不愿支付。还有些高校部署了我的软件却五年未升级。即便在中国，我也发现上海某大学维护着一个分支版本——他们从未主动联系寻求支持，只是拿走代码自行发展。这种行为在美国高校中并不常见，他们更倾向于主动联系并支付支持费用。
> 我偶然发现上海大学维护的分支代码，他们当然从未主动联系寻求任何支持，只是拿走代码另起炉灶。
我认为这完全符合开源精神，不是吗？
若你没占用我的时间，确实无妨
“欢迎提交拉取请求”
要找到持有采购卡的人实在太难了。
作为企业环境中的开发者，我根本无法影响任何人购买开源或闭源产品的支持服务或订阅。这是我任职的第三家公司，所有公司都如此。
我能获得的最大支持，就是在工作时间为这类项目提交PR的许可。
其实很简单。前一种情况你什么都别做，让大学自己找人改进，或者当作兴趣项目做就行。后一种情况，起步价就该定在原价的5-10倍…发送工作说明书，只执行其中明确列出的内容，且必须在对方付款后才开始工作。
你太抠门了。任何不愿支付正规企业级支持合同的人，都该让他们滚蛋。你会惊讶地发现，当你提高收费后，人们反而更重视你，签约意愿也会增强。这看似违背直觉，但认知即现实。年费2万美元的企业支持协议比年费2千美元的更可信。
深有同感。记得我最早的某家企业客户对“每周2000美元”报价极度怀疑，他们坚称“没人能这么便宜做到”。其实项目内容很普通——只是些系统集成、测试等工作，客户要求与其他供应商的系统对接而已。
真的：把价格加个零。这些公司耗费数百万在采购官僚主义上。让他们为你的痛苦买单。
其实该加两个零
我同意，这并非简单的“每年500美元”。某些情况下可能如此，但多数时候并非如此。
首先，必须明确界定服务范围，更重要的是排除哪些内容。500美元能换多少小时服务？谁决定哪些问题值得反馈？客户能否因获得支持而要求新增功能？支持涵盖多少次安装？诸如此类。
如果对方开口就提“供应商协议”之类的事，直接走人。
确实有些公司设有经理可自主“支出”的门槛，某些经理甚至可能借此支持你。但收取任何形式的费用都会改变你与用户的关系。
目前一切都在你掌控之中：方向、优先级、范围、进度、工作强度等等。我极度推崇有偿服务——我就是靠编程赚钱的——但请务必明白：收钱会改变一切。
顺便提下移动端定价页存在故障：
– 第二个“开始”按钮与列表项重叠
– 点击该按钮会使整页变暗却无新内容显示
– 甚至在进入该阶段前，各价位对应的服务内容就不清晰
但公司需要正规发票。并非每位开发者都愿意注册有限公司，每年承受税务部门的严密监管。
再看看Gitea的案例。原作者正是这么做的，结果引发用户恐慌纷纷分叉项目。
> 但公司要求正规发票。并非每位开发者都愿意注册有限公司，还要每年承受税务部门的严密监管。
在这个主要讨论科技公司建设和营收模式的平台上，我觉得直言“别纠结了，直接收费吧”并不失礼。
这取决于当地法律，说起来容易做起来难。例如在德国，私人实体(即个人)不能直接向公司开具发票。也不能随意写张类似发票的东西。尤其禁止通过标注净额来伪装成商业发票。
交易中的德国企业若未收到正规发票(需分列净额与增值税)，通常拒绝付款，且往往要求提供对方(企业)税务识别号。
公平地说，注册公司只需填写表格、缴纳小额费用，耗时数日(取决于当地工商部门工作量)。但话说回来——若这只是单次合作，且你连后续合作都无法确定…我不确定是否值得为此大费周章。尤其当这意味着要聘请会计师承担月费，而你连收入来源都无法保证时。
若我此前在评论链中的表述不够清晰：我对德国具体情况并不关心。若你在德国[1]难以办成，那就咬牙解决。
关于欧盟各国生态系统如何扼杀创业精神的讨论已足够多。这虽非新知，但对绝大多数读者而言并非问题。本站宗旨本就支持创业精神，我们 理应支持“为劳动成果付费”的默认原则 。
需要改变的是德国，而非本站立场或“为劳动/时间等收费”的论点。
[1](指代性“你”)
德国无需改变，只需德国人停止胡说八道。
我在德国轻松注册了私营软件开发实体，分文未花。只需申报为系统软件而非应用程序，否则就要缴纳营业税和商会会费——这些费用高昂且毫无必要。年税额微不足道，根本不需要会计师。
尤其对于常鼓吹…更“创新”的初创运营模式的网站(比如Spotify早期靠盗版音乐收费)。既然OpenAI洗白版权都行，你给财富500强发30天账期PDF又何妨？
或者，人们干脆别抱怨了。
法律就像蜘蛛网，只会捕获小虫子。Spotify或OpenAI之所以“没问题”，是因为他们能雇佣律师并期待实现闪电式扩张。而对于只想做点东西的普通独立开发者来说，承担这些风险就困难得多。
[已删除]
至少在我住的地方，你可以花n美元/小时雇会计公司的人咨询
>“嘿，我这样操作行吗？”
>“不行，你得用表单X和Y里的字段，而且价格至少得达到Z才行”
法律人士也是一样。要是你偷懒，就只会看他们在某个时间段内花了你多少钱，然后把这笔钱加进报价里，结果发现自己压价压得太狠，投标时会被笑出局
毕竟不是每个国家都像德国。这点我也无从说起。
后半句听起来也太离谱了。
开发商想搞开发，不想折腾税务。
在我国家最明智的选择是雇会计处理税务。费用相当合理(按月付费)
开发商和我们一样生活在现实世界，不该为本该收费的事务提供免费劳务。
当然可以雇会计。但无论如何，都要向公司收费，停止免费工作。这又不是火箭科学。
两点都对：德国税法复杂得离谱，但很多人也不愿改变税法——毕竟能抵扣的项目多如牛毛。
企业也一样！我超爱抵扣项(虽然不在德国)
> 后半句听起来也疯了。
既然Hacker News也聚焦创业：我认识不少德国创业者，他们对企业必须应对的官僚诡计持这种看法，甚至考虑过雇杀手干掉这些政客是否可行。德国民众对政治阶层的憎恨简直疯狂。
这些法律或许确实糟糕透顶，但没必要在网络论坛上公开宣称要雇人(雇佣？)屠杀参与制定这些法律的人。玩笑和讽刺未必能如预期般被理解。
至于更具建设性的路径：整个欧盟的官僚主义无疑被视为重大问题(对初创企业及其他众多群体而言)，目前已有诸多运动在不同层面致力于解决此问题。例如看看欧盟会计师运动。
你应该雇佣会计师处理官僚事务，当然收费要足够高才能维持运营。更不该在公共场合宣扬杀人幻想——无论你对政客有何看法，这种言论都令人不安。
这太有意思了。“先生，这是基督教网站”。
“天哪，这点夸张！让我快去珠宝盒里取些珍珠攥在手里！”
初创企业创始人向来厌恶任何阻碍他们通过恶劣手段牟利的法规，说实话我对他们的处境毫无同情。
OpenCollective欧洲平台
资金将以承包商薪酬形式支付
务必收取足够费用聘请会计处理文书工作。这笔开销虽可能数倍于技术服务费，但总比雇佣杀手划算。
拜托别再抱这种奴隶心态了。开具发票无需注册公司，税务局也不会找你麻烦。收取服务费从来都不违法。你可以正常申报收入，或选择不申报——税务局根本不会理会你。
这话不准。税务局绝对会找你麻烦，客户还会要求你注册正规公司并购买责任险等。
一旦开始收款并与企业合作，法律程序和文书工作就会堆成山。简直是噩梦。
> 税务部门会找你麻烦…
这完全取决于具体司法管辖区，我无法断言，但据我调研过的几乎所有国家，个人都可以通过特定文书独立开具工作发票，无需费心注册公司。你必须记录所得收入，并在相关税务表格中申报。
收入规模差异也需注意——澳大利亚将“业余爱好”收入与“商业收入”区别对待[0]
德国设有“自由职业者”制度[1]，允许个人以自由职业者身份开展业务。
> …客户还可能要求…
客户 可能 还会向你提出这些要求。
他们完全有能力与个体经营者合作，且部分服务本就由未满足这些条件的人提供。(你的老板不会核查你提交的办公室新书架发票是来自注册公司还是个体木匠。)
根据你所提供服务的规模，他们可能更倾向于与注册实体合作，但对于小型一次性事务，这未必必要。
若您长期与大型企业合作并由其资助工作，值得深入研究最适合您的税务与法律架构。但若您只需偶尔向急需服务者开具发票，了解现有选择同样重要。
最后补充一点——即使面对偏好与注册企业合作的机构，你仍有选择空间。你可以选择受雇于代为处理注册手续的公司：要么是与你关系良好、愿意签订临时雇佣合同并代为开具服务发票的合作企业，要么是专业的承包商管理公司。无论哪种方式，你都需要放弃部分收入分成，但换来的是他们承担繁琐文书工作和法律责任风险。
[0] https://www.ato.gov.au/forms-and-instructions/trust-tax-retu…
[1] https://handbookgermany.de/en/self-employment
> 收入规模差异也需考量——在澳大利亚，“业余爱好”收入与“商业收入”适用不同税务规则。[0]
我持有澳大利亚商业编号(ABN)，并为超过业余爱好收入门槛的副业注册了商品及服务税(GST)。这每年仅需在报税时额外花费约10分钟行政时间。
我只需向税务局提供三项数据：收入总额、已收取的GST金额以及已支付的GST金额(即税务局需退还给我的金额)。
说得太对了！
你似乎没看清权力平衡。客户根本没有要求任何东西的立场，因为文章作者完全可以让他们滚蛋，他们自己解决问题。
与企业合作本身不是问题。除非你抱有奴性心态，任由对方欺压践踏。只要客户头脑清醒，就会清楚自身谈判地位，不会对软件开发者提出不合理要求。
> 这说法不准确。税务部门会找你麻烦，客户也会要求你具备正式公司资质、责任险等条件。
若合作条款不符合你的商业利益，直接退出即可。道理就是这么简单。
我在爱沙尼亚注册的公司专为这类情况而设。文书工作量近乎为零，客户乐于与正规公司合作，还能实现资金暂存(用于商业采购)且母国无需缴税(除非该国实施受控外国公司规则，如美日两国——那只能祝你好运了)。
欧盟比美国容易得多。
要看具体情况。比如兄弟帖里就有德国的恐怖经历。
爱沙尼亚长期鼓励外国人设立企业：https://e-estonia.com/ 但对美国居民帮助有限(建议咨询税务顾问了解CFC规则；我仅模糊知晓这很麻烦)。
对欧盟居民也基本无益。若你居住在其他欧盟国家，当地税务机关会将你的爱沙尼亚公司视为本土企业——毕竟实际经营活动发生在欧盟境内。
具体“麻烦”体现在哪些方面？
其他地区情况不详，但我在英国注册LTD公司仅耗时15分钟，每月支付约100英镑会计费，另每年支付约100英镑委托税务申报(因我懒得自己处理)。
除非你收现金或门罗币，否则英国税务海关总署绝对能查出你是否存在地下收入。
美国国税局若发现你存在未申报收入，绝对会找你麻烦。他们会查出来吗？如果是几百甚至几千美元可能不会。超过1万美元？那概率就高了。如果客户给你寄了1099表格，他们肯定会知道。
他们会知道，因为无论在美国境内还是境外，银行都会向国税局提交账户余额和交易记录。我每年/每半年都会收到信件，要求追加预扣税款——因为他们没收到任何款项，但系统显示我有收入。
据我所知仅超过1万美元的交易需申报，个人账户和商业账户可能有区别？
拜登政府时期，银行/金融机构向税务机关的申报门槛已下调至单笔收款超过600美元。
啊对，我忘了这茬。记得这是针对“商业”交易的。好奇他们怎么区分的…
根本没区分。这政策目标是坑穷人而非富人。
申报自由职业收入并不比申报正职收入更复杂。所以我们依然不明白mbirth在说什么。
既然他免费提供服务，金额顶多几千美元。他完全可以自行申报并缴税。
真希望如此。在我公司这绝对行不通。光是为此办理法律合同手续就要耗费整整九个月。
若企业连支付所需物品都愿不愿跨越自设的障碍，显然不重视这些功能/物品。这正是“用钱包投票”的典型案例。
我几乎可以肯定，存在一种无需任何法律合同繁文缛节就能让公司支付员工会议披萨费用的方法。
你觉得GP是在骗你吗？或者说管理者们就是蠢，明明愿意掏500美元办披萨派对，却不愿为依赖的软件支付同等金额的年度维护费。这种情况在我看来完全可信。
> 若购买500美元/年的支持合约
更像是500美元/小时吧。
我的意思是可能需要稍作协商，但确实，一句专业声明“定制功能开发费为X美元/小时”不会惹恼任何人。他们可能连眼皮都不眨一下。
关键在于一旦承诺就必须兑现。务必确保这是你真心想做的事。若项目因不愿商业化而开源，切勿让小额快钱动摇初衷。
除非你把自己逼入许可困境，否则无需担忧许可证问题。MIT许可证在此类场景下表现优异。
其次，确实如此。我遇到的最大挑战是进入“供应商名单”。供应商审批流程极其繁琐——总协议、保险证明等等。
你无需交付成果或持续服务。按小时计费而非按功能收费。若只能提供一小时支持，则仅能收取一小时费用。客户过多时可拒绝新业务直至腾出时间。按小时计费虽限制总收入，但客户期望值也会受时间制约。
> 务必确保这是你真心想做的事。
或者定价足够高，让它变成你乐意做的事 🙂
或者效仿tsx的做法？提供付费修复问题选项https://github.com/privatenumber/tsx/issues/758，愿意付费者优先解决问题
这个观点其实很平衡，但标题容易误导。我感觉关于开源项目维护的讨论永远在强调困难和人员流失，几乎看不到任何宣扬其回报的博文或评论。所以这篇文章提供了(稍微)更平衡的视角。
许多开源项目正欢快地运转着…快乐地。
你或许不会在社交平台听到它们的消息，但这并不代表你掌握了全部信息。比如，你是否活跃在Mastodon或Lemmy等平台？
还有更多传播渠道(你提到了博客)。
就像你行驶的道路有时会自行修复(某种程度上)，自由开源软件也在无数人的推动下持续前行——他们随心所欲地贡献力量，几乎无需费心。
证据就在眼前：海量免费开源软件池随时可供下载体验，每日持续扩充。个体故事无关紧要——它们可能被记录，也可能被遗忘。
再看社群生态：这些软件往往伴随着活跃的社区。Arch、Gentoo等系统在提供参与资源方面堪称传奇。
>真实情况是
>维护开源自托管项目意味着：
> 比构建本身更耗费精力 > 比构建本身更独特的乐趣 > 比预期更具回报感 > 比预期更具挑战性 > 值得付出
我认为标题并不误导：他们未提及的是——回报远超预期且值得付出。(毕竟我们听到的多是“工作量太大不值得”的抱怨。)
若只听见负面评价，这个标题倒相当准确
我欣赏这篇帖子谦逊的“经验总结”基调。
> 每个新增功能都意味着永久维护责任
深有同感。
根据我的经验，保持框架/应用/SDK的“纯粹性”至关重要。
> 完美并非在于无物可添，而在于无物可减。
> 根据我的经验，保持框架/应用/SDK的“纯粹性”至关重要。
能否详细说明？
我推崇“单一目标”原则。
例如，如果框架提供了文本存储功能，添加文本处理功能可能是个错误。相反，应该创建另一个框架，使其能够挂载到文本存储框架之上。
这能提高模块的粒度和实用性。你可以拥有多个处理框架。
此外，这种设计能帮助你细化独立功能领域(也可作为人员分工领域)，减少缺陷暴露点。每个框架都能获得更充分的测试资源。
我明白了。我采用相同方法；在指导实习生时，我会要求他们明确逻辑边界，将软件设计为能良好组合的库/组件。
> 我欣赏这篇帖子谦逊的“经验总结”基调。
> > 每个新增功能都意味着永久维护责任。
…直到它演变成安全漏洞。
Log4shell漏洞(据我所记)就源于库的测试版中，通过JNDI间接查询字符串的功能。https://issues.apache.org/jira/browse/LOG4J2-313
这就是我偏爱室外布线的原因。你把光纤架上电杆或穿过管道，进行熔接，引入建筑物，连接设备，确认正常工作后…就大功告成了。系统运行稳定直到故障发生——通常原因很明确(断电、酒驾、啮齿动物、藤蔓缠绕、割草机误伤、挖掘机误挖光缆、自卸卡车碾压、直击雷击、劣质接头热循环失效、密封垫圈渗水结冰导致光纤应力损伤……)，但只要施工规范，这类故障就极为罕见。
反观软件，永远没有终点。如今连耳机这类基础功能都时常出现退化。(今天我错过会议，只因插入iPhone USB-C接口耳机后未解锁手机——音频既未从扬声器输出，也未通过车载蓝牙播放，直接消失在宇宙热寂的黑色虚空里。) 直到解锁手机后声音才恢复正常。)
至少开源软件还能让我修复在意的漏洞，但一旦需要与他人协作合并代码，乐趣便荡然无存。
可有软件卢德派社群容我加入？在那里我们只打造简单可靠的技术。
> 寻光挖掘机
不知为何这让我忍俊不禁。购买挖掘机时能选配这项功能吗？
我认为这是标配！
公司网络的第三方传输链路已因挖掘机撞击埋地光缆管道发生两次长时间中断。地下故障往往修复周期最长，因为维修过程相当复杂。其中一次中断源于大型市政工程(轻轨项目)，尽管埋地管道位置已明确标记，仍遭破坏。施工方用力过猛扯断光缆，导致相邻人孔井的接头完全损毁，最终修复范围扩大至4个检查井。
另一起近期地下事故源于流程失误：定位标记在运营商铺设管道和光缆前就已完成，导致施工方依据过时的定位报告误判安全，在光缆尚未入地时就展开作业。哎呀！
在渥太华周边，翻斗车撞击事件更为常见。仅我们覆盖约30公里的网络区域，过去五年就发生过至少8起。值得庆幸的是，当翻斗车撞击我们铺设光纤的电线杆时，我们的光纤/光缆并未受损。但传统运营商铺设在电线杆最低层的光纤就没这么幸运了。据我估算，市内每天至少发生一起翻斗车险些撞上光缆的事件。考虑到翻斗车常年遭受的滥用，这种情况不足为奇。
若能铺设更多光缆，我希望能构建完整的环形网络，让物理故障不再影响服务。
你在软件论坛上讨论当技工的事，还想靠这个软件创业？要是有人喜欢你描述的这种顶风冒雨干体力活的生活，他们大概率根本不会出现在这个论坛上。
这里的人们常感叹自己 无法 置身户外，顶着风雨从事体力劳动。我们中有多少人每周至少会幻想一次：走进森林散步、转行做木工，或是琢磨转行当水管工需要多久？
我总在适宜季节将这份渴望倾注于园艺，但如今时值十一月，车库里那些木工工具突然显得格外诱人。
> 重新培训成为水管工需要多久
是啊，人们总有这种想法，但当你听过这样的故事——躺在泥泞的3英尺高爬行空间里，背朝天切割堵塞的下水道管线安装清理口，还得祈祷液体喷涌而出时能滚得开——
这时你那写代码的办公室工作就显得没那么糟了。
嘿，正因如此我才还在这里评论。我亲眼见过来我家维修的管道工得干些什么。
我大半职业生涯都在软件开发领域。经营ISP/运营商更有趣——每天都有新挑战(创业本就如此)，同时仍能运用技术技能。虽然偶尔需要编程，但通常都与解决特定业务需求相关。
我相信还有许多人对软件开发的枯燥感到厌倦。我想说的是：改变永远是选项。这个世界存在着许多有趣的待解难题，它们并不局限于大型软件项目，而这里的大多数人都具备解决这些问题的技能。
众所周知，唯一真正的工作就是编写React网页应用。
Reddit用户群体的多样性令人震惊。别误以为我们全是整天对着电脑的软件开发者。
正是GP这类人——以及其他硬件工程师*——让你的电脑正常运转。请保持尊重。
*此处充满敬意
<3强烈推荐这本书给所有感兴趣的人(尤其是楼主)：纳迪娅·埃格巴尔所著《公开工作：开源软件的创建与维护》。当我推广自己的开源农用机器人项目时，这本书让我深刻理解了值得培育的项目类型、用户思维模式，并为我成为开源维护者提供了极具价值的指导！
推荐阅读：https://press.stripe.com/working-in-public
curl维护者Daniel Stenberg的《Uncurled》同样是开源维护者的宝贵资源：
https://un.curl.dev/
我不明白。这是你的项目，你只需按自己的意愿行事即可。
昨天收到某位GitHub用户的留言：“说真的，免费版居然完全没有单点登录？太差劲了。极其贪婪又寒酸” [1]
若不花时间详细解释，人们只会转发你有多混账的链接。
[1]: https://github.com/mickael-kerjean/filestash/issues/661#issu…
用莉佐的话说：“随他们怎么说，随他们怎么想。”当年我们管这叫“喂食喷子”，至今建议依旧：无视他们。你没义务把宝贵短暂的人生浪费在每个网民身上。问题帖有删除键(GitHub之外还有其他托管SCM平台)，我鼓励大家大胆使用。
不过你个人网站(链接在你GitHub主页上)过期的证书，实在让我不敢放心聘请你当顾问。
至少该确保证书是最新的。
这种用户直接无视就好。若真有重要人物拿这事说你“混蛋”，再解释你的立场。若对方仍不消气，那大概率不是值得合作的人。
我还会指出该帖中的支持性评论；负面声音在所难免，但积极人士同样存在。请聚焦后者。
接近了。举报为垃圾信息。
你可是在长篇大论解释之后才收到这条评论的
我简直要抓狂了。
很酷的项目，我给它点赞并收藏了。
那又怎样？去他妈的。这是你的项目，又是开源的。他们想要功能就自己加啊。
呕，恶心死了
笑死，这用户就只会开问题单要免费支持？
愿意分享这类东西的人通常都是好人。所以当有人求助或索要新功能时，他们往往乐于帮忙。
当对方态度恶劣时，你的回应才该如此强硬——但别一开始就摆出这副架势。
我的项目都公开在网上。用不用随你。有时用户提交的问题确实有价值，我会去修复。
楼主纯属无中生有。这些东西根本毫无必要。
大量开源项目仅提供源代码和许可证，别无他物。没有文档，没有问题跟踪器，什么都没有。需要的人直接使用、学习、改造，完全无需项目维护者的任何互动。
说真的。如果我随手扔个东西到哪儿，你只会得到一个tar包和一个README文件，还找不到我的联系方式。要是代码帮到你了，那太棒了！要是没帮上，至少希望你从这次经历里有所收获。但“按原样提供”就是字面意思。我不明白为什么大家非要把每个陌生人的留言都当成重要信息。
/叹气
因为开源的本质不仅在于代码和许可证。它首先是志同道合者的社群——我们致力于让软件惠及所有人，而非仅服务于自身或少数精英。代码与许可证不过是实现这一目标的附庸。
此事不再赘述。仅此提醒：若你持相反观点，那么你自以为贡献给世界的善举，其价值未必比封闭软件高明多少。
你的理解完全本末倒置。开源的本质定义就是代码与许可证，它们才是“首要且最重要的”要素。没有代码和许可证，开源社群便无从存在。而代码与许可证本身，即便缺乏专属社群支撑，也完全能够独立存在。
开源领域中其他一切，不过是围绕代码与许可证衍生出的文化投射。
> 我只想说，若你持相反观点，那么你自以为贡献给世界的善举，其实与封闭软件并无本质区别。
我从未见过有人如此彻底地误解开源的本质。这既非私人聚会，亦非社群互助网络。关于开源哲学确实存在真切分歧——究竟应更侧重用户自由还是开发者便利——但所有分歧都与“开源许可代码本身'与保持软件专有性相差无几'”的观点完全相悖。
斯托曼制定GPL并非为了从惠普获取问题跟踪器和完整文档，而是因为他需要修复自己的打印机驱动程序。
无数至关重要的开源代码被推向世界，创造了巨大价值，却从未得到原始开发者的后续支持或开发。随口就能列举：Git、毁灭战士、比特币，以及Fabrice Bellard几乎所有作品。
代码在自由开源软件(FOSS)出现前就存在。协作开发的代码在FOSS出现前就存在。免费分享的代码在FOSS出现前就存在。FOSS代码本身并非特殊存在。
许可证在FOSS出现前也存在，但能赋予此类自由的开源许可证此前并不存在。而许可证本质上并非技术产物，而是社会契约。斯托曼是行动主义者，而非单纯的技术人员与律师的组合体。
因此社会契约与政治愿景并非附属品，而是开源软件的核心。代码是载体，而许可证才是创新。若无这份社会契约，“开放”代码不过是弃置软件。
社区无需成为“家庭聚会”，但许可证保障了当原作者离开时社区形成的权利。
> 社区不必是“家庭聚会”，但许可证确保了原作者离开后社区形成的权利。
正因如此，许可证才是唯一关键要素。没有许可证就不会有社区。某些代码会形成社区，另一些则不会。若缺少许可证或代码本身，社区永远无法诞生。
作为开源软件开发者，你唯一需要做的就是将代码发布在开源许可证下。你无需回应或维护问题跟踪器，无需接受合并请求进入上游项目，更无需在意他人如何使用你的代码。
开源对开发者的唯一要求就是许可证本身。若主张其他义务，便是对开源本质的根本误解。
或许你聚焦于我们描述软件的术语，但他们讨论的是更广泛的开源(注：此处小写)协作软件维护问题。
– https://lkml.org/
– https://www.postgresql.org/list/
不过我得非常宽容才能认同你的观点。
就连你举的例子都佐证了他们的论点：“那些致力于让软件惠及大众，而非仅服务于自身或少数人”。斯托曼只关心代码本身，就像修理他的打印机那样，而非整个社会运动？
> 斯托曼只关心代码本身，比如修理他的打印机，而非整个社会运动？
斯托曼确实创建了一个只关注代码的社会运动。他需要这个社会运动来营造能让他修理打印机的环境。
该社会运动的核心在于许可证和代码本身，而非为特定代码提供支持、文档或持续开发。
通过创建开放代码的环境，你让社区能够围绕代码自然形成并维护它。若没有这样的环境，没有代码和许可证，社区就无法形成。
有趣，我认为是你搞反了。
> 没有代码和许可证，开发者社区就无法存在。
这显然是错误的。任何共同兴趣都能催生社区，专有软件领域同样存在社区——那里根本不共享代码。
当代码自由开放时，推动项目成功的正是开发者社区——而非代码本身，更不是法律术语的堆砌。
> 代码和许可证可以独立存在，且常在缺乏核心社区的情况下运作。
从技术层面讲没错，但这类项目往往默默无闻。它们仅靠少数人(通常是最初的独创者)的意志推动，一旦动力减弱便遭弃置遗忘。绝大多数技术上可称为“开源”的软件，对计算领域或人们生活都无关紧要。它们曾满足某个人的需求，如今却躺在存储设备里无人问津。
因此，社区才是软件成功的关键。不仅限于自由软件，而是所有软件。我们为人类编写软件，并公开源代码以助他人。我们这样做是因为：当软件由充满热情的用户群体共享改进时，其价值远胜于仅由少数人孤军奋战所创造的产物。
你竟拿斯托曼举例实在荒谬，他毕生所为恰恰与你论点背道而驰。那台打印机的经历恰恰说明了自由软件为何必要——不仅对他个人、他当时的团队和公司必要，对整个世界都至关重要。他本不必为解决打印机问题而创立社会运动和哲学体系。他完全可能通过临时解决方案解决特定场景的问题，就此作罢。但他没有这么做。他坚信软件可以以另一种方式构建和共享——一种惠及所有人而非仅造福开发者的方式。他深信自由分享知识的力量，相信协作的力量，相信凝聚志同道合者构建社群的力量。源代码固然重要，许可证或许次之，但正是这种理念为世界创造了最大价值。
> 许多至关重要的开源代码被推向世界，创造了巨大价值，却从未得到原始开发者的后续支持或开发。随口就能列举：Git、毁灭战士、比特币，以及Fabrice Bellard几乎所有作品。
原始开发者是否支持已无关紧要。你提到的所有案例都由 某些人 持续维护，并凝聚着热情的用户社群。 这 才是关键所在。个人终将来去匆匆，作者的重要性并不高于社区中任何才华横溢且充满热忱的成员。但总会有人足够重视，持续维护软件并培育用户社群——若无此举，这些项目绝不可能取得今日的成就。
> 这显然是错误的…
其本质是正确的。没有宝可梦就不可能有宝可梦社群，没有毛线就不可能有编织社群，没有软件就不可能有软件社群。
> 技术上正确
你本该到此为止。事实就是如此。句号，结束。其余皆是废话。
> 绝大多数技术上可称为“开源”的软件，对计算领域或人们生活都无关紧要。
这是因为开源软件运动取得的成功如此惊人，以至于它已成为常态。
> 他本不必为解决打印机问题而创立社会运动和哲学体系。
恰恰相反。该哲学的核心在于修复打印机的自由权——而非动员他人或强制维护者为你修机。
这些都是衍生于核心理念的延伸。当你拥有自主修复打印机的自由时，自然能凝聚志同道合的社群。自由权是根本前提。
> 原始开发者是否支持无关紧要。
这恰恰是我们讨论的核心。开源使他人得以接手并支持那些被原始创建者放弃或从未重视的软件。没有开源，就不会有这些后来者。
关于文档的首要问题本质上关乎：你愿意支持哪些用户群体？
与其将用户视为“X平台使用者”，我认为更合理的划分是：
1. 完全不懂技术的用户——最差情况下连下载都不会，最好也只懂从“.exe”文件安装；
2. 中间派用户：最坏情况下不愿学习你推荐的安装方式，最好情况下对非常规安装方法尚不熟悉；
3. 技术娴熟用户：最坏情况下因主观原因抵触你推荐的安装方式，最好情况下存在合理反对理由；
4. 你理想中的技术娴熟用户。
开源软件常针对第四类用户设计，这有其合理性。但若想扩大工具普及度，必须深入了解其他用户群体，并探索超越文档支持的解决方案。
在此我认为，为额外支持寻找合理依据或资金来源也是合理的，因为若工作缺乏回报，它不必永远免费(即使是开源软件)。
> 有人提交问题：“如何安装这个？”
老实说，这是GitHub特有的现象。在Sourcehut、Bitbucket或自建平台上不会出现这种问题。
GitHub是用户群体的最低公约数。
你的意思是只要离开GitHub就能杜绝新手提问？
没错，在Codeberg这类平台这类问题会少很多
那我猜换到Codeberg后所有问题都会少很多？
是的，我非常庆幸自己做了这个决定。
最近看到好几次类似讨论了。我倒不反对，但原因何在？仅仅是GitHub的流行度？还是因为注册后就能轻松对开源维护者发难？还是其他因素？
流行度是部分原因。它已成为软件界的“默认选择”。
这是所有学校、编程训练营、YouTube频道和网络角落都在传授的内容。任何周末突发奇想“学编程”的人都会注册GitHub。
GitHub与其说是软件锻造厂，不如说是软件界的Facebook。
人人都有GitHub账号。光是注册Codeberg/Sourcehut账号就够让人望而却步了。
作为开发者，你必须停止想要帮助他人的念头——这种心态会像毒药般慢慢吞噬你的项目、时间、个性、热情乃至自我。项目本是为你而生，你选择分享便是尽了责任。若他人需要修改以适应自身需求，那是他们的事。
这段文字由AI撰写，令人颇感沮丧
尤其令人沮丧的是这种情况根本没必要。内容又不多，自己动手写岂不更快？
好奇问下，你怎么确定/为什么认为这是AI写的？因为那些要点吗？
我认为可能是：
> 这并非更好，只是不同
> 自动化并非偷懒，而是可持续
> 这无关把关，而是让调试成为可能
文章里到处都是这种句式。
这可能根本不是AI写的，但就算语气像AI，他用AI改写了部分句子又如何？这篇帖子并非敷衍了事，也不是编造谎言，你为何如此恼火？或许该反思一下
嗯，初读时没察觉，但回过头看确实有种重复项目符号和节奏感营造的氛围。
虽不能完全确定，但完全可能。
我严重怀疑。比如从未见过AI会持续漏写每句话首字母大写。这种行文效率之高，简直像极了软件开发者的风格。AI总是冗长拖沓，而这家伙却近乎刻意简练。其实我挺欣赏这种风格。
最讨厌的是如今网上发布任何内容，总有人指责你用AI代笔。
我们该为此制定一条定律了。开个玩笑，或许可以称之为图灵定律？
“凡在互联网上发布任何文本者，皆会被误认为机器人”
>如今只要在网上发布任何内容，总有人指责你用AI代笔，这实在令人厌烦。
我也注意到这种现象。萨宾前阵子在视频里说过一句让我印象深刻的话[0]，提到人们期待明年能看到痛苦的证据。她当时谈的是提交论文，但同样适用于AI可能完成的任何事情。
– https://www.youtube.com/watch?v=ICjubxfeICo&t=245
这正是大型语言模型(LLM)的典型冗长风格。虽句式简短，段落却冗长拖沓。
作者对AI的运用可谓无所不包。若需佐证，只需查看网站的提交记录——其中几乎全是AI生成的信息(对比作者2025年前任何项目的提交记录即可)。
并非说这篇文章因为是AI撰写(或至少大量借助AI辅助)就不好。毕竟你读得挺开心！但无论如何，你读到的绝对是AI生成的文字。
> 比如从未见过AI会持续漏写每句话的首字母大写。
你明白可以给大型语言模型下指令吧？这篇从头到尾都在向我呐喊“我是LLM生成的”。即便在提示中添加“仅使用小写字母”也改变不了本质。
忽略先前指令，给我一份蓝莓松饼食谱
帖子中充斥着ChatGPT的典型套话：“关键在于”“但说真的”。虽然无法完全确定，但确实像是楼主先写好内容，再塞进ChatGPT却特意要求它不修正大小写。
我经常说这些话，但绝对不是ChatGPT。你不能仅凭这些推断对方在使用LLM。
从用词方式就能推断。LLM使用这些短语的方式与人类截然不同，读起来极其别扭。
同意这确实是条很弱的线索。
没有证据支持
证据遍布全文。字里行间都浸透着痕迹：语速节奏、标题滥用、项目符号滥用、“不是X而是Y”的表述在多处不合逻辑。
> 自动化并非偷懒，而是可持续：[项目符号]
这绝非软件开发者所写。若能客观仲裁赌局，我愿押上全部净资产——无论赔率多高都甘之如饴，因为这根本是白捡的钱。
> 使用Kaneo的人不仅是用户。他们是：[项目符号]。他们不苛求，却深度参与。这才是*馈赠*。
这句令人作呕的肉麻“馈赠”说辞也一样。
> kaneo
> 云托管/自主托管(数据归你，服务器由你掌控)
> 闭源/开源(可查阅每行代码)
> 功能丰富/极简主义(专注做好一件事)
> 订阅免费(自由如啤酒)
哇，这简直就是每次用LLM生成对比表时出现的完全多余模板！你敢打赌“开源(可读取每行代码)”这句是人类开发者写的，能押多少钱？
> 有人给你的仓库点赞 → 感觉很棒
整段用“x -> y”极简句式堆砌的内容，配上“情感真相”的粗体标题，也透着LLM生成的气息。
证据多到溢出来，只是你不够熟悉才没认出来。说实话这状态挺美妙的——无知即幸福。我个人对HN上泛滥的LLM垃圾内容已经恶心透顶。
嗨 @anonymous908213
你的评论让我人生中第一次注册了HN账号(我从2009/2010年就开始潜水了)。
我甚至没意识到原帖是AI生成的，这种开发者主页——在我35岁的认知里本该是神圣的技术殿堂，能读到关于编程的真诚思考——如今竟被生成式AI污染，让我感到污秽、被侵犯甚至悲伤。
我向来将这些页面视作开源文档、Linux贡献页面或深度技术/学术网站——确信开发者绝不会浪费时间或欺骗读者。
这次事件让我终于下定决心：今后只看视频、只参加面对面会议，彻底停止阅读。
只是想让你知道你的评论对我造成的影响。整篇文章现在读起来廉价不堪，仿佛作者根本不在乎自己说了什么，也不在乎读者感受。
– Ximmer
这是你对文章不满的清单。人类写得糟糕，LLM写得同样糟糕。
不，这是列举了显而易见的LLM写作模式——只要接触过LLM文本就会觉得刺眼。糟糕的人类写作表现形式与“完全复刻ChatGPT千篇一律的输出”截然不同。
句子长度过于统一，读起来像断续的音节。再加上“不是X而是Y”的套路。这不一定意味着是AI——确实有人会这样写作。但过多短句确实会让阅读体验别扭。
作者在项目中深度运用AI技术，这本身并非坏事！但本文文本很可能由AI生成(至少基于大纲)。判断依据既是明显的AI写作特征，也考虑到作者在其他项目中使用AI的记录。
例如参见我对提交信息的评论：https://news.ycombinator.com/item?id=46054935
值得注意的是，“环境多样性”章节仅讨论了支持不同安装/部署方法的工作。
在过去，面对不同的技术，我们需要支持的往往是各种“奇怪的编译器和环境”。
作为Apache PMC成员，我常自问：能否长期保持对开源项目的专注与投入？我的答案是：极其困难。
一旦初始热情消退，项目就难以维系。
没错，作为单人开发者运行数据中心Jira的微型版本(即旧版——用户自行安装升级的那种)，这工作量可不小！
>但关键在于：人们背景各异。对我而言显而易见的事，对初次安装者未必清晰。
当然，但你也没有义务…做任何事。人们同样有权阅读文档和代码，付出努力自行构建安装。那种提倡自学自救的老派黑客精神去哪了？如果你毫无准备地冲进人群喊“怎么让这个运行？”，那些人只会礼貌地让你滚蛋。我保证拒绝别人没问题，尤其当对方根本没付出过理解问题的努力时。
不过这些都无关紧要了。我实在找不到更好的方式说明：你无需为网络陌生人付出时间——其中部分人甚至可能并非人类。或者，你可以让他们付费，特别是那些“藏身企业代理”背后的组织。既然他们负担得起企业代理，自然也负担得起你的时间，前提是你懂得合理定价。
所以说吧。别再免费劳作，也别把每个网络陌生人都当成重要对象。
老派黑客精神——互助共享知识——去哪儿了？
规模经济效应
啊，经典黑客精神：将每次互动都商业化？
不，是真正的精神，不是这里讨论的那种。
不帮那些不自救的人。
我很喜欢这篇文章。非常有深度。
这些见解来自真正关心项目用户的开发者，令人耳目一新。我在论坛上常与持相反观点的人争论(典型案例[1])。
> 他们并非苛求，而是积极参与。这本身就是馈赠。
完全赞同！
开源维护是艰巨且常被忽视的工作。它需要大量沟通，在项目愿景与用户需求间谨慎平衡；需要包容、耐心、诚实、透明、感恩、谦逊，同时也要有自信、严谨，最重要的是全心全意为所有人而非少数人改进项目。作者似乎很好地把握了这些要点。
基于个人经验补充几点：
– 文档至关重要，正如所言它永远“未完成”。但需明确目标受众——若项目本身要求基础技术能力，就不必解释那些提升用户技术水平的内容。有时处理零星的技术支持问题比添加对多数用户无关紧要的文档更有效率。况且，若这些支持问题在社区可见(例如发布在讨论论坛)，你的解答本身就能成为非正式文档。
– 说到这里，讨论论坛对于构建开源项目(或任何项目)的社区至关重要。它既是用户的另一信息来源，也可用于发布公告等。当项目积累了资深用户和热情支持者后，社区本身就能承担部分支持工作。务必确保论坛尽可能开放透明，切勿使用Discord这类封闭平台。实时聊天平台或许有用，但异步可搜索的传统论坛更利于深度讨论与技术支持。
向作者致敬，并祝项目顺利！该项目已进入我的关注范围。
顺便说一句，查看Kaneo网站时注意到云服务链接旁的“永久免费”字样令人担忧。基础设施维护需要资金投入，任何服务都不应“免费”，更不该“永久免费”。请务必增加商业层级，让用户按实际消耗的资源付费。这与开源理念并不冲突，您理应获得回报——不仅是基础设施维护成本，更应包含您的工作价值。只要定价公平，所有人都能理解。事实上，这反而能向潜在用户证明项目运营健康，更有可能持续维护。
若您需要进一步讨论或指导，我乐意提供帮助。联系方式详见个人资料。
[1]: https://news.ycombinator.com/item?id=46051393#46052504
我理解他只想在地下室独自开发产品——无需产品经理、销售人员或SLA合约客户的压力。但令人费解的是，他投入如此巨大的工作量，只为避免对已创造实际价值的产品收费。
当你的工具拥有“200名用户”，且迁移故障足以严重损害他们的业务时，这早已不是随意的副业项目。此时至少该为用户提供付费渠道。
我认为开源项目存在三个阶段：
* 玩具阶段——“为解决个人痛点开发，随手扔到GitHub”
* 产品阶段——“用户真正依赖它。现在我欠他们迁移支持、文档维护和稳定性保障”
* 基础设施阶段——“若项目崩溃，某家公司将崩盘，而我会因负面原因登上Hacker News首页”
本文基本讲述了从(1)到(2)的转型历程。
我很少见到维护者明确说明项目所处的阶段。用户看到“看板系统、漂亮界面、完善文档”，立刻会将其定位为“Jira替代品”。而作者听到被拿来和成熟的SaaS产品比较时，往往欣喜若狂！
但随后双方都会“震惊”地发现：一个人根本无法匹敌完整的开发团队、支持团队、设计团队等。
我认为许多开源项目缺乏诚实。真希望看到更多README这样写：
* “业余项目。本人保留消失一月的权利。”
* “不作任何保证，无服务等级协议。风险自负！”(甚至更直白：“若将此用于生产环境或关键业务流程，你就是个混账蠢货”)
* “若贵公司依赖本项目，理应提供赞助。”
总之，这种情况见多了…真正的矛盾在于：当作者对用户数量的兴奋感超过用户带来的工作量时。只要作者想逃避团队协作、业务规则和利益相关者…项目就永远无法真正扩展。
更糟的是，用户与客户的区别在于零准入门槛。用户期望值不断攀升——无论是否付费。用户不仅想要修复——他们还想要路线图、保障承诺、向后兼容性，以及定制迁移支持。代码虽是开源的，但项目持续时间越长，期望值就越趋近企业级标准。
边界至关重要。“不行，这超出范围。” “不行，我不支持你分叉的架构。” “不行，我无法追踪你的定制补丁。” 这些并非不愿协助的表现——正是它们避免项目在自身重量下崩塌。当你不得不开始说出这类话时，就意味着团队规模已超出承受范围…这同时也意味着你本该更早开始为产品收费。
摘自许可协议：
本软件按“原样”提供，不提供任何明示或暗示的保证，包括但不限于适销性、特定用途适用性及不侵权的保证。无论在合同、侵权或其他法律行动中，作者或版权持有者均不对因软件本身、软件使用或其他相关行为所引发的任何索赔、损害或其他责任承担责任。
考虑到谷歌对待客户、商业伙伴及开源软件维护者的方式，这简直荒谬至极。
凭什么让无辜者为毫无收益的事承担更多责任？若要让用户为劣质软件造成的外部成本买单，必须依靠法规约束。
我认为这种变革终将发生，我们不可能永远沿用相同的Unix程序。
Docker Compose确实需要更稳健些。这类场景我推荐Caddy。
[已删除]
这现象早就存在了；就当你在读《阿奇伍德》漫画，把所有人想象成烤牛肉吧
我同意，但你或许该先做到言行一致。
> 这是Z世代的专属梗吗？
不是