就在几个小时前，我和无数中国程序员一样，在震惊中得知了陈皓先生离世的消息
我和陈皓交集不多，但还是决定写点什么。
和大多数人一样，最早知道陈皓是通过他的博客 酷 壳 – CoolShell。至今我的印象笔记里还存着网页剪藏下来的六篇文章（突然觉得印象笔记也没那么不堪了）
虽然很久没看，但 Coolshell 在我印象里就是最有用也最有影响力的中文程序员博客。耗子叔的文笔简练，表达清晰，加上技术过硬，阅读他的文章一直是一种享受。
2020年，和他在推上探讨了一下“天赋”并贴了自己的一篇博文之后，陈皓关注了我
之后我们有过一些零零散散的交流
陈皓的影响力不用过多评价，懂的都懂。现在想来，他真的是一个少见的完全没有黑点，并且所有人都佩服的技术大牛。然而这还不是全部，我看了 Manjusaka 发的推才知道他竟如此热心。想必这并非孤例，甚至可能是一种习惯。如此之人，整个技术圈也再难找出第二个了（当然我觉得 Manjusaka 有潜力）。
感谢 yihong，他以个人英雄主义的方式（通过未公开手段），拷贝了陈皓的全部推文，并上传到 GitHub。信息长久保存的紧迫性也再次凸显：Elon 想删除不活跃的账号，而 coolshell 也总有一天会因为欠费或域名到期而下线。此时，我也不得不再贴一次 《People Die, but Long Live GitHub》，希望大家开始认真思考这个问题。
希望所有人，尤其是程序员同僚们，在关注技术和工作的同时，也千万千万要注意身体，多关注自己的 well-being。写代码，真的没那么重要。
最后，还是以一条推文结束吧
当你影响了他人，别人自会记住你。
R.I.P. 陈皓
打算重新开始写点东西。
持续性（Consistency）
大学的时候，大家喜欢在考前突击复习。由于宿舍熄灯，包括我在内的很多人都选择去学校附近的咖啡馆刷夜。这对短期高强度工作的偏好在我开始工作后依然存在。比如某一天睡不着，我可能会直接起来工作到两三点，然后第二天下午再去上班。
然而最近两年我逐渐意识到，虽然突击可以带来短期的高效，从长期来看，效果却不如保持稳定的节奏，持续输出。那么怎样算是拥有持续性？我很喜欢 Sahil 的这组推文中的例子，虽然他讲的 two-day rule 并不是这里讨论的重点。以工作为例，严格地每天八点起，五点下班，这当然是一种 consistency；但如果你早上十点起，晚上加班，这同样是 consistency。又或者，选择每周加两天班，其它时间正常下班。我觉得关键在于找到一种自己舒服的节奏，可以是以天、周，甚至两周为单位，不要去打破它。
从纯粹个人的经验看，持续性可以为制定计划提供依据，比如让你更好地估计某项任务要花久完成。另一方面，它极大地减少了“低能量时期”的出现。过去，我会不定期地有几天什么都不想干，不要说工作和运动，甚至连游戏都不想打——个人把它称作“低能量时期”。不知道大家是否有这种情况。一旦处于这种状态，我基本只能躺着看手机，别的什么都做不了。一度我甚至怀疑自己是不是有抑郁症。但最近两年，这种情况出现得越来越少。我无法完全肯定（毕竟这不是科学实验），但认为它和持续性的工作状态相关。这方面我不懂所以如果说错请指出，但我猜测生活节奏的起伏（比如某几天突然熬夜）会打破身体里的某种平衡（比如激素分泌、节律、代谢），从而导致异常状态。
睡眠
直接引用以前的推文好了。有很多因素会影响工作和生活的质量，但如果你问我哪一点最重要，我一定会说是睡眠。
马竞球星略伦特3万英镑买床垫：为了比赛，钱花得值！
当初看到这个新闻时只觉得好玩，但真的买了个稍微好点的床垫，我才意识到这一点都不夸张。当然，我买不起那么贵的：）
Complexity of life
之前看到 Jordan Peterson 的一个视频，很有感触（注：不代表同意他的所有观点）。
人们的生活太过复杂，以至于他们宁愿选择死亡。他们通过自杀寻求死亡是为了结束复杂。因为这种复杂一旦失控，就导致痛苦。
The Heat around PyPI "critical" Packages
Recently, PyPI mandates 2FA for critical projects, but got many push backs from developers (1, 2). Many people (assuming open source project maintainers) don't like the idea of being forced to put more work into projects they don't get paid to work on.
Armin Ronacher (creator of Flask, Sentry) discussed this in more detail, suggesting there's a better way like cargo-vet than putting more burden on maintainers. Donald Stufft (Python core dev, pip/PyPI maintainer) on the other hand, believes that maintainers do have certain responsibilities.
While almost all people agree that enforcing 2FA is a sensible move, I think the real problem is still about the responsibility of open source software (OSS) maintainers, or, does it even exist?
The Responsibility of OSS Maintainers
Many OSS maintainers complained on Twitter that they've been seen by users and big companies as "free labor", like the one Daniel Stenberg (creator of curl) posted.
Despite all the posts, it seems like we're entering a dead end: users keep asking, and maintainers keep clarifying. The OSS community has wasted so much time and energy on this, and it makes me wonder whether we're trying to solve the right problem. "How many responsibilities do OSS maintainers have?", it doesn't even feel possible to have a right answer, because projects are so different by themselves.
I think, the question we need to answer is:
For a specific project, how to get its maintainers and users to reach a consensus on the responsibilities of maintainers?
The differences with the original question are:
- Target projects individually, instead of viewing them as a whole.
- Involves both sides, instead of only one.
- Building an understanding is always the foundation towards more actions.
A Possible Solution
Naturally, we think of a similar thing: open-source licenses. It's answering the opposite question: what are OSS users allowed to do? What if, we have something similar for maintainers, and let's just call it "software maintainer commitment", or SMC.
Suppose we have something like this, what will it look like?
- For 90% of the projects, they will remain as is, i.e. no commitment. This means maintainers have absolutely no responsibility.
- For some, they're willing to enable 2FA to provide the least assurance. Some may be willing to ensure compatibility with the latest version of the language it's written in.
For projects maintained by big companies, that's a whole different story. I can imagine big companies have the resources to provide a long list of commitments, and they're willing to do so to attract more users. This is certainly unfair for maintainers working in their free time, but on the other hand, by making the distinction clear that there are different levels of commitment, users will no longer assume that each project can provide the support that they imagine, which is the whole point of SMC.
Though the idea comes from OSS licenses, implementation wise, SMC will be different in many ways:
- There will no longer be pre-defined commitments like MIT, GPL, except "no commitment", which is like WTFPL.
- Commitments need to:
- Be fine-grained: support the attributes that maintainers may need to specify, and allow expansion.
- Be configurable: commitment is often more than just "yes" or "no". For example, one might say I guarantee to fix security issues in x days, and x can be an arbitrary integer greater than 0.
- Allow anti-commitment: since all we want is to bring more clarity, anti-commitment makes total sense. An extreme case would be: as a maintainer, I will not fix any issues, and it's the users' responsibility to do so.
- Allow conditional commitment: Often times, financial support is critical to keeping a project alive. Things like GitHub sponsors and Open Collective have helped many developers and made many projects better maintained. SMC should allow developers to state "if you pay me $500, I will respond to your bug in x days and make it a higher priority."
In short, commitments need to be a lot more flexible than licenses, because maintainers have different needs.
A Beautiful Future and a Bumpy Road
So what can we do with software maintainer commitment (assuming it's widely adopted and recognized)?
- It makes maintainers happier, and users less confused.
- It saves people's time, for both maintainers and users: less questioning, arguing, clarifying, complaining. We're talking about the time people spend on communication, and that's a lot of time.
- It helps users select the projects to depend on.
- It helps identify the risk in your supply chain. Remember this graph?
But how are we going to analyze all these arbitrary commitments, you might ask? Well, that's where machine learning can help.
The future sounds fantastic, but to get there we need to go through a bumpy road, and I'm not even sure we can.
- Unlike a license that is backed by legal precedent, SMC doesn't really "enforce" anything. Stating a high support level doesn't mean a project is actually supported. On the contrary, if somehow it is enforced by law, then maintainers will not use commitment for sure because the risk is too high.
- Most maintainers probably just don't care about having such a thing.
- Creating commitments by themselves is not enough, having them widely recognized and respected is as important. This is really hard and will probably take decades.
With all the difficulties, I never doubt the value of transparency and clarity. Again, it's worth noting that the purpose of software maintainer commitment is not to encourage maintainers to do more things, but to resolve the confusion around responsibility. I can imagine that personal maintainers tend to have mostly anti-commitments, while corporations will have more commitments. This is fine, and if we get there, the world of open source will be a lot better than today.
The World Is Different Now
The world has become very different. In 2011, it's still Why Software Is Eating the World. Today, can you imagine an article like this that does not even mention open source? Open source is not new, but in the past, it was not as critical as it is today that affects almost every aspect of human beings. The scale of users has made OSS beyond just a topic among hackers. The atmosphere also changed with it, there's no "common sense" any more. With the explosive expansion of OSS, the management and ideology of open source is falling behind.
With or without software maintainer commitment, the issue of maintainer responsibility has to be solved. I have faith in human, and we'll get there eventually.
Appendix
James Bennett wrote an article that mentions similar ideas.
