“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
被微软“叉”走：一个开源维护者的心路与技术剖析
开源项目的 MIT 许可证允许分叉，但不允许抹去原始归属——一位独立开发者讲述其项目被大公司复制后的困境与反思。
引言：一场意外的“分叉”事故
三年前，我所在的团队负责为客户维护 Kubernetes 集群。一个反复出现的痛点：当镜像仓库（Image Registry）宕机时，客户环境就会面临大规模停机的风险。传统解决方案是部署有状态镜像（stateful mirror），但客户预算紧张，没有时间和资源去实现这种方案。
一次“黑色星期五”大促期间，我们遭受了大量流量冲击，恰逢 GitHub Container Registry 也宕机了，导致我们无法从该仓库拉取关键镜像，集群扩容受到严重限制。那一刻，我开始认真思考：是否存在一种无需有状态组件、运维成本极低的方案，可以规避这样的扩展瓶颈？
于是，Spegel 诞生了。
Spegel 是什么？
Spegel 是一个开源的 Kubernetes 镜像分发工具，它利用 P2P（点对点）方式在集群内共享容器镜像。每个节点只需从远端拉取一次镜像，后续其他节点可以通过集群内部网络相互传输镜像层，从而减少对中心化镜像仓库的依赖，提高扩展性和鲁棒性。其核心优势是：
- 无状态：无需部署额外状态存储，所有节点对等协作。
- 低运维：自动化处理镜像层分发，无需人工干预。
- 节省带宽：尤其适合大规模集群或网络带宽受限的环境。
整个项目完全由我一个人维护，使用 MIT 许可证发布，代码托管在 GitHub 上。自首个版本发布两年多来，Spegel 累计获得了 1,700+ stars 和 1,440 万次拉取，可以说得到了社区的真诚认可。
微软来了：从期待到沉默
作为一个独立开源维护者，当微软主动联系我，表示希望聊一聊 Spegel 时，我无疑是兴奋的。那次线上会议氛围很好，我感觉前方是一条充满合作、甚至可能让我招募新维护者的康庄大道。
会后，我与一位微软工程师保持着沟通，我帮他们配置 Spegel，解答架构上的疑问。我乐观地认为，这可能是微软基于自身经验对 Spegel 进行贡献的开始。
但时间流逝，微软方面逐渐沉默了。我理解大公司的项目优先级会变化，于是将此事搁置。
KubeCon Paris：真相浮出水面
直到在巴黎 KubeCon 大会上，我参加了一个关于加速镜像分发策略的技术分享。演讲者提到了一种 P2P 共享的方案，描述听起来和 Spegel 如出一辙，我兴致勃勃地准备听听别人的想法。
演讲中，我无比惊讶地看到，他们直接提到了 Spegel，并展示它作为 P2P 镜像分发的解决方案。紧接着，他们介绍了微软的一个新项目——Peerd，一个用于 Kubernetes 集群内容器内容点对点分发的工具。
我立即上网查看 Peerd 的仓库。在 README 的底部，有一行感谢语提到了我和 Spegel。这种“致敬”让我起初以为他们只是从 Spegel 中汲取了灵感，然后自己发展了版本。
但随着深入查看代码，我心中的热情一点点冷下去。
似曾相识的代码与注释
我看到 Peerd 的函数签名和代码注释与 Spegel 极其相似，仿佛是我自己写的。继续挖掘，我发现了直接引用 Spegel 的测试用例，甚至包括引用了我前雇主名称的测试用例（至今仍保留在仓库中）。这些测试用例明显是从 Spegel 中照搬的。
事实上，Peerd 就是 Spegel 的一个分叉版本，由微软维护，但许可证却换成了微软的 MIT 许可证。
MIT 许可证允许任何人对代码进行分叉和修改，且不要求将修改后的代码回馈给原项目。我默认使用 MIT 是因为其简单且宽松。但 MIT 许可证不允许的是：移除原始版权声明，并将代码冒充为他人原创。
我将 Spegel 和 Peerd 中一段添加镜像配置的代码并排对比，连函数注释都一字不差。这在逻辑上无法让人相信是“灵感相似”——而是直接复制。
一个维护者的“大卫与歌利亚”之困
Peerd 的出现给社区带来了困惑：很多新用户不断问我 Spegel 和 Peerd 到底有什么区别。作为维护者，我本应保持客观中立地解答，但这一段历史让我实在难以不带情绪地回应。
更困难的是品牌效应：微软拥有巨大的品牌认知度，Spegel 作为一个小项目，要在这样一个庞然大物旁边争取关注和空间，异常艰难。
我作为开源维护者，投入了大量时间在社区请求、bug 修复和安全补丁上。我原本非常开放地与微软合作，希望能共同将工具打磨得更好，回馈开源社区。但这场经历让我开始怀疑自己的价值——是否还有人需要我继续维护 Spegel？
继续前行与开源生态的隐忧
幸运的是，我最终坚持了下来。Spegel 依然强壮地运行着，但在思考这种“小开发者被大公司摘桃子”的现象时，我更关注的是整个开源社区的处境：
- 像 Hashicorp 那样的许可证变更（从 open source 转向 BUSL）在开源社区引发了连锁反应。
- 整个行业对开源项目的投资正在明显缩减。
当小维护者面对数十亿美元的大企业时，我们有什么办法维持公平？
为了资助 Spegel 的持续开发，我已经开启了 GitHub Sponsors。但这只是杯水车薪。
是否该改变许可证？
这次经历也让我重新考虑 Spegel 的许可证。MIT 似乎是我唯一能扔出去的“石头”——改用更严格的 Copyleft 许可证（如 GPL 或 AGPL）虽然会限制商业公司的无限制使用，但也会伤害普通用户和下游开源项目。这是一把双刃剑，我还在犹豫。
结语
我这个经历并非孤例，也不会是最后一个。但至少我希望通过分享我的故事，能引起更多人对开源维护者权益的关注，也希望大公司能在“分叉”时保持更多的尊重与透明。
正如一位网友在 HN 评论中指出的，微软的行为恰恰体现了为什么“上游优先”（upstream first）的理念如此重要——可惜，不是所有公司都这么想。
原文章节摘录与原文链接：
（本文为对原文的深度改写，补充了技术背景与反思，力求忠实于原文观点和细节，同时为中文读者提供了必要的解释框。）