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.
This blogpost describes the Python development setup that makes the most sense to me (and probably you as well) in 2022 and beyond. By "Development Setup", I mean the local development environment, and not about deploying apps on a server.
The Best Setup, in A Nutshell
- For executables/utility tools (e.g. mypy, black), install with system Python + pipx
- For project development, install different Python versions via pyenv
- For dependency management, use PDM (PDM is installed via pipx)
I'll explain each choice in more details below.
Why Use Both System Python and Pyenv Python?
One unusual thing you probably have noticed is that the setup consists of two ways to install Python: the system Python and Python installed by pyenv. Here, by "system Python", I mean the Python carried with your system, or the Python installed with a system package manager (e.g. apt, brew). Many articles suggested that we should never using system Python, so why still use it? Because we need two independent systems for two different purposes:
- For utility tools, reliability matters the most. You want them to always work when you need them. The less things they depend on, the better. System Python is the best choice, because they have the least dependencies. Also, for utility tools, It doesn't really matter which Python it is running on. Therefore even if system Python is behind the latest version, it is usually fine.
- For Python interpreters used by projects, flexibility is more important. You may need to upgrade them when a patch version fixed a bug, or using a specific Python version because that's what you have on the server. pyenv fits this purpose well.
pipx
pipx needs no introduction, it has become the de-facto way to install Python executables. But imagine if you install pipx with pyenv-installed Python. This creates a dependency like this:
mypy --> pipx --> 3.9.7 (pyenv) --> pyenv --> system Python
As you can see, the 3.9.7 (pyenv) --> pyenv part is unnecessary. It also creates trouble when upgrading Python: you either have to reinstall pipx, or keep Python 3.9.7 forever since pipx and all the tools above relies on it.
PDM
Now comes to the controversial part: PDM. Disclaimer: PDM is my personal choice, and it's totally ok if you chose Poetry, Pipenv, or any other tools. Here are the reasons why I use PDM:
⚠️⚠️ UPDATE 2023.5: I should clarify that, PEP 582 is good for developing libraries; for applications, PDM's virtualenv mode should still be preferred.
PDM helped me get away from virtual environments
I used to have 10+ virtual environments, and I get a headache every time I saw the long list. It essentially makes it impossible to ever upgrade my project Python, because I really don't want to setup virtual environments again for every project.
With PDM, I have no virtual environments. Each project directly depends on the pyenv-installed Python. I'm also free to upgrade patch versions (e.g. from 3.9.7 to 3.9.9), which allow me to always use the latest Python release.
See also You don't really need a virtualenv.
PDM is well maintained
PDM is created and maintained by PyPA member Frost Ming. If you don't know what PyPA members do, let's just say they know the best about Python packaging. Frost Ming also maintains Pipenv.
I used to use Poetry, which is also a nice tool. But sometimes Poetry is buggy, especially when upgrading project Python. What's worse is that no one seems to be dealing with those bugs (example). PDM is the opposite. Issues are usually responded within a day or two, including feature requests.
Benefit from being maintained by a PyPA member, PDM is usually the fastest in adopting new proposals in the Python packaging world, which lets its users stay on high productivity.
Overall, I find PDM better than other tools I've used, and it's constantly getting better (5~6 releases per month). I tweeted about my transition from Poetry to PDM, might be interesting to read.
Caveats
You may still need to install a new system Python when the old version gets deprecated. You can use pipx reinstall-all to reinstall existing tools, which is not so bad.
The setup may or may not work on Windows. If you can confirm which case it is, and/or if there's any issues, let me know, I'm happy to put them in the article.
Summary
In the past few years, Python gained a lot of great improvements in the development/packaging ecosystem, but this also created a mess that even the most experienced developers had a hard time picking tools. Luckily, I've found the silver bullet that works for me, and I hope it would also work for you.
正如大家所知，我最近换了一个组。回顾过去几年，被坑的时候实在不少。从中我意识到了一些事情，故用这篇文章记录一下，也算再给自己的想法做个 snapshot。文章的三部分别讲项目、老板以及组的坑。最后再聊聊换组。
这里的“坑”不单指外界的坑，也包括自己犯过的错误。本文的适用范围还请读者自行判断，毕竟大到公司，小到组和部门，它们的差别都极大。你觉得和你遇到的情况不符，请不要杠，这没意义。虽然这么说，我觉得大部分内容还是通用的。另，有些英文说法没有翻译，但都不难理解。
项目的坑
当需求不是直接来源于用户时一定要谨慎
我转组的原因之一是 2020 年做的大项目失败了。项目实现了规划的功能，架构也清晰合理，但没有达到预期的 impact，而我原本是指望用它来到 L5 的。为什么会这样呢？归根到底，这个项目并非来源于客户的直接需求，而是老板拍脑袋想出来的。我的（前）老板某一次和其它几个老板聊天，发现其它组都有一个工具。他觉得这玩意我们大部门也挺需要的，那就找人做吧。不是说它完全没用，毕竟我们最终还是找到了两个客户，但我们很想推的组没推动，并且未来大概也不会有更多用户。后来我才知道老板先问了我的 TL (Tech Lead)，TL 没有接，然后才找的我。TL 依靠丰富的经验避开了这个坑，但我就没那么好运气了。结论：需求不是直接来源于用户是一个巨大的危险信号。
内部 2c 项目（大概率）好于 2b 项目
这里仅讨论内部工具项目，不适用于面向外部用户的产品。几年下来我有一个很直接的观察，成功的内部工具基本都是 2c，很少有 2b 的。可能有人会好奇，内部工具也有 2b2c 之说吗？有个很简单判断方法：一个工具或系统，如果工程师能自己用起来，那就是 2c；如果需要部门里 >1 人讨论并决定，那就是 2b。举两个例子：一个开箱即用的任务监控面板是 2c 的，而一个需要修改 release 流程才能使用的工具就是 2b 的。当然，我观察到的样本很少，所以结论未必对。但我真心感觉 2b 的东西想推动，要花费几倍于 2c 工具的时间，效果还未必好。总之如果你有的选，请尽量把时间花在 2c 项目上。
警惕那些依赖其它组的项目
OKOK 我明白，世界上就没几个不需要跨部门合作的项目。但合作方式也是多种多样的。假如对方是你的客户，你需要和他们沟通来实现一个需求，又或者大家同属一个大组做同一个产品，这种就没问题。而当对方在你的关键路径上——比如你想做的东西没有对方配合就完不成，且你们又是跨部门，这种就有很大风险。如果你正在参与此类项目，请一定确保：
- 双方（或多方）要 aligned（阿里话的“对齐”），尤其是老板之间。包括对项目的预期、优先级、工期、资源投入，都必须互相知晓并认可，而且要落实到 OKR 层面。不要相信工程师的口头承诺，我被坑过，而且很惨。
- 要有定期例会。
- Escalate（上升）的渠道一定要通畅。当对方没有按期交付或出现各种问题时，你要能通过自己老板向对方施压。这也是为什么双方老板的支持是必需的。
了解组里其它人在做什么
除了上面提到的那个项目，其实我曾有更好的机会升 5。我们组有个项目，本来由两个人分别负责前后端，结果后端哥们儿写一半离职了。后端是用 C++ 实现的，而我当时是组里唯一有 C++ readability 的人，如果申请接手，老板 100% 会同意。然而我当时埋头于自己的任务，完全不关注组里其它人在做什么（即使我一直帮他们 review 代码）。因为不了解，也没有意识到这个项目的潜力。后来这个项目交由前端哥们儿负责，并且成了组里的重点项目。我就这么错失了好机会。说白了这又是“选择大于努力”的例证。
于是我决定，进新组之后至少和每个人 1:1 一次，即使他们的工作看起来和你毫无关联。同时关注各种新提案和设计文档，了解其它人在做什么。除了寻找可能的机会，这也有助于站在更高视角全面理解当前的工作。
不要对项目产生感情
我当初之所以选择换到现在的组，主要是因为（前）老板答应我可以继续之前的工作——一个我很喜欢并认为有很大潜力的项目。时至今日，这个项目完全兑现了潜力，然而我却因此耽误了两年。如果当时抛弃对项目的感情，我完全可以找个更合适的组。转组的事之后会细聊。
老板的坑
之前和 Phil 做过一期节目聊了这个话题，不过我们遇到的情况不尽相同，感兴趣的可以去听一下。我只说我遇到的情况。
不要盲目相信老板
我的三任老板都有过很离谱的判断：
- 第一任老板认为写什么语言都不影响换组（我一开始写 Dart。。。）。然而事实就是换组非常看背景。很多组明面上说可以进去再学，实际上都希望申请者会写特定的语言（等着进去再学的人根本拿不到面试：）。
- 第二任老板极度厌恶 C++ 并热爱 Java。他要求我把一个 C++ 服务用 Java 重写。这明显是个费力不讨好的活，但又不能不干，于是我和老板说服了另一个人去写。结果如我所料，他花了时间却没拿到任何 impact（真对不起他）。
- 现任老板比较短视。他上任后大刀阔斧地砍项目（交给别的组维护），理由是我们要 focus 在几个重点项目上。很多成功或有潜力的项目都上了被砍名单。问题是 EngProd 组的活本来就少，被这么一砍，不少人拿不到足够有 impact 的项目，只能做些小 feature。去年离职了好几个，今年目测还要跑一波。
所以我认为，老板的话要听，但决策一定要自己做（或者说，做自己认可的决策）。这里面有个更本质的原因。自己做决策，即使错了，也可以复盘反思，并取得进步。而让他人做决定，自己将很难进步——对不知道对在哪，错也不知道错在哪。
警惕只想把你当工具人的老板
我换组的另一个原因是发现老板有把我当工具人的倾向。在 Google，好的老板要能平衡组与组员的利益，既保证组的发展，又确保个人能够成长（说白了就是晋升）。前两任老板虽说都给过我坑项目，但至少他们会和你聊个人发展并给出建议。这些我都看在眼里。现老板去年还是工程师，在前老板走后被提拔上来。一开始的感觉是他不太关注我的项目，即不了解也不想去了解。今年 Q1 快结束时，事情开始变糟。如之前所说，老板开始砍项目，并把我调往那个我曾经错过的项目。本以为老板打算让我从现在开始 own 它，然而并不是。老板的意思是让我 Q2 去实现一个比较重要的功能，后续安排再议。从我知道的情况看，这个项目中很有 impact 的一块已经被分给了一个即将到来的 intern——是的你没听错，intern。我问老板：明明这个 feature L3 工程师就能做（简单的 CRUD），并且对他们晋升帮助很大，为什么让我来？老板说你擅长这块，你来做比较快。话说到这份上，继续聊下去已经没太大意义了。
怎么判断老板有没有把你当工具人？我觉得有这么两点：
看老板给不给你做职业规划。好的老板会说：我觉得你想晋升，impact/difficulty/leadership 还不够，做XXX任务可能对你有帮助，或者我们一起想想能做什么。把你当工具人的老板不会给你规划。
看老板对你是否诚实。我曾对现老板说：仅仅加这个功能基本上就是 L3 的活，感觉对我晋升没有帮助。老板说不要紧，只要你做得快，拿 SEE（类比 3.75）是没问题的。在我看来这就是典型的不诚实，或者职场 PUA 话术。你再资深，该花的时间还是得花，收集需求、设计、实现、测试，这其中有的时间是你无法控制的。资深工程师无非是做出来的东西稳定一些，考虑更周全，bug 更少，并不是一定就能做得更快——因为最快的方法永远是糙快猛。
如果是前老板，我觉得他会说：“虽然没法让你到 5，但我们有客户急需这个功能。我们可以规划一下之后的安排，比如让你顺势 own 这个项目，或者找一个更好的项目”。诚实是最重要的。不要骗我们，我们不傻。
当然，现老板也和我聊过晋升。他说如果我想晋升就得自己想一个好项目。于是我想了一个 impact 很大的，写了提案给相关组审阅，他们很满意。然后老板说我们不做这个，要 focus。我：？？？
组的坑
组的坑既是最好聊的又是最不好聊的。相对来说，组的坑比较明确，容易提前识别。但另一方面，组的坑多种多样，且和老板和项目都有关联，难以穷尽。所以这里只说说我知道的那些。
业务/技术/个人兴趣，至少要占一项
有的组业务有前途，有的组技术有挑战，有的组两边都有，有的组两边都没有。两边都没有的基本就是坑，这种组在大公司相当多，比如 Google 的 EngProd。当然，如果某个组做的东西就是你的兴趣所在，那就加入吧，这时候别的都没那么重要了。
Fake infra 和 True infra
EngProd 具体怎么坑，我以后或许会专门写篇文章讲，但最根本的一点在于他们负责的是 fake infra。EngProd 全称 Engineering Productivity（研发效能），现在的 title 虽然是 Software Engineer，但在 2019 年以前是 SETI（software engineer, tools and infrastructure）。有人一看到 "infrastructure" 这个词就被唬住了，以为做的是什么不得了的东西。然而 EngProd 虽不负责业务，做的东西却也跟 infra 不沾边，我称之为 "fake infra"。比如修改一下公司的集成测试框架给某个组用，帮某个组优化 presubmit/postsubmit time，减少 test flakiness，诸如此类的杂活是 EngProd 传统艺能。我理解公司设立这个职位的初衷就是把杂活分出去，让 SWE 们专注于开发。
True infra 和 fake infra 的区别是什么呢？我觉得 true infra 一定是有技术挑战的，且至少要服务于某个大部门（比如 Search/Ads/Cloud），而不是一个或几个组。那些大家耳熟能详的技术都是 true infra，比如 Spanner，F1，Flume，Bigtable 等。有意思的是，做 true infra 的组从来就不属于 EngProd，而 EngProd 也从来不负责 true infra。
不要去 scope 太小和前景莫测的组
记得第一任老板总是强调要了解 big picture，当时不懂，现在才发现说得真对。Scope 指一个组负责的工作或者产品有多大。比如前面说到的 true infra，他们的 scope 就是全公司，而 EngProd 组的 scope 则通常是一个部门（几十到一百人）。面向用户的产品更复杂一些。比如 Gmail 和 YouTube 虽然有几十亿人用，但某个组负责的小功能却未必。这时候你只能依靠经验去判断。很多时候我们看不清，这不要紧，但至少有一些坑是可以避开的，比如 messaging app。
我第一次换组的时候也犯过错误，为了能去搞 AR 花了很多时间学图形学，导致没怎么认真看其它组。现在想起来觉得自己真蠢：在 Google 做 AR 没前途不是明摆着的么？到今天为止都没有一款面向消费者的成功 AR 产品，更不要说在这方面投入不多的 Google 了。而且说白了我也不是真的有兴趣，只是觉得这个技术很酷而已。当时犯的错误，现在要用几倍时间来还。
换组心得
下面来聊聊换组。虽然和上一节相关，我还是决定单独拿出来说。很多公司不像 Google 有这么多换组机会，还可能面临老板不放人的情况。因此我不打算写换组的流程，而是把重点放到“选组”上，尽可能让内容通用一些。
关注具体的工作内容和大方向
只看产品选组还不够，具体的工作内容和大方向也很重要。比如一个明星产品组招人可能是为了是搞测试，而一个内容平台的年度 OKR 可能是加强审查。要了解一个组的方向，最简单的方法是去看它的年度 OKR。如果找不到，一定要和老板问清楚。
我遇到过这么一个组，他们有 hc 所以打算先招几个人，至于做什么等进去再分配。这也是一个危险信号。通常来说，一个职位的职责越明确，项目的风险和掉坑的概率就越小，也能让你做出更有根据的选择。
Impact 是否好兑现
我实在不知道 impact 怎么翻译比较好，“影响力”这个说法其实不准确，所以我就不翻了。Impact 是否好兑现，我们可以通过举例说明（注意，好兑现和“大小”是两码事）：
- 好兑现的：
- 实现一个面向用户的新功能
- 依赖的 API 要 deprecate 了，使用新 API 重构系统
- 优化响应时间
- 给覆盖率很低的项目写单元测试
- 不好兑现的：
- 做一套测试框架
- 重构系统，但是功能不变
- 优化调试或监控工具
好兑现的项目简单明了，只要做完了 impact 就实打实地在那，不需要费劲给人解释。不好兑现的则各有各的问题：
- 做测试框架：做了并不代表有人用，没人用那 impact 就是 0。你得花心思推广。
- 重构系统：你觉得老代码写得太烂了难以维护，所以要重构。问题在于证据呢？这时候你就必须得收集数据，比如证明在老代码下加一个功能平均需要三天，而重构以后只需要一天——假设你能拿到这么理想的数据。实际情况往往是拿不到，或者并没有显著差异。
- 优化调试或监控工具：这里的困难还是在收集数据，你怎么证明改进后比改进前要好？并不是说证明不了，而是需要花心思。
优先选择 impact 好兑现的组。一般来说，做新东西比较好兑现。
和工程师聊天
和老板聊天往往容易浮于表面，或者大饼满天飞。找到组里的工程师，一般他们都会毫无保留地告诉你真实信息。我会问很多尖锐的问题，比如“你觉得组里有哪些缺点”，“晋升速度如何”等，还会详细了解工作的细节。有个工程师直接告诉我，如果你想晋升，就不要来我们组——老板们断然是不会这么说的。如果你觉得在职员工讲话会有顾虑，也可以找刚转出去的员工。实际聊下来我没发现有太大差别，只要是工程师都会如实说明情况。
什么时候该考虑转组？
这个问题没有标准答案。我现在倾向于认为只要满足条件（Google 的要求是待满一年），就可以开始关注新机会了。我们有个系统可以设置 filter，出现满足条件的内部转岗机会会自动给你发邮件。每周看一次邮件其实花不了几分钟，而且看机会并不意味着一定就要走。别看每天都有很多组在招人，实际上单看某一个组，招人的窗口都只占一年中的很小一段，甚至有的组几年都不招。很多机会错过就是错过了。
有种情况我会建议你立马开始看机会：人事变动。不论是老板离职还是组织架构调整，只要是人事变动，多多少少一定会影响工作。影响可能好可能坏，可能多可能少，你无法预测，所以最好未雨绸缪。尤其如果老板给你提供了很多支持，甚至本身就是项目的发起者，当他离职之后你的工作必然受到冲击。事情变坏往往就是一瞬间的事，如果没有准备可能会措手不及。当然这里还是要强调，看机会不等于一定要换组，只是给自己准备一条后路。如果一切照常甚至变好，那完全没有换组的必要。
总结
相信你现在也感受到了我这几年是怎么被坑过来的。我当然希望一切都一帆风顺，但既然事情已经发生，也必须总结一下引以为戒。祝大家职场之路顺利。
