转自：InfoQ - 褚杏娟
开发者“ebol4anthr4x”发布了一篇题为“我的公司已禁止在内部使用 JetBrains IDE”的帖子，引起了网友广泛关注和热议。
公司大部分开发人员（约 1000 人）都使用 JetBrains IDE 进行开发。然而，今天早上公司宣布，所有 JetBrains 产品都将从工作站中移除，每个人都需要改用其他产品。
我们主要使用 Go 和 Python，这意味着我们的唯一选择是 VSCode。如果有人曾经从 JetBrains IDE 转回 VSCode，那么你可能知道这种转变感觉很糟糕。其他几个团队广泛使用 Java，因此他们至少可以选择使用 Eclipse。
官方给出的理由是 JetBrains 与俄罗斯有关系。无论怎么争论，领导层都没有改变这一决定。
其他公司也在这么做吗？我觉得这太荒谬了。为了从 VSCode 中获得类似的功能，许多团队成员都在互联网上下载不知名人员编写的第三方插件，我不难想象这比使用 JetBrains 产品的安全性要差得多。
“我在 2019 年左右的政府合同项目中，因同样的原因禁用了 JetBrains。”有开发者跟帖表示。
有部分网友猜测俄罗斯问题只是幌子，“他们（公司）只是想削减许可成本。”有人直言，“看起来相当愚蠢，我猜他们只是可悲的吝啬鬼。”有网友表示疑惑，“与其他职业相比，软件工程师的薪水相当高。然而，有些公司却试图削减我们使用工具的每一分钱。我真不理解这种心态，如果我为某人的时间付了很多钱，我会希望他们使用能让他们最高效的工具，这样我就能从我的投资中获得最大的回报。”
“假设你在美国，假设他们真的是为了节省成本而这样做，那就开始寻找另一份工作吧，因为一年的许可证成本与典型的开发人员薪水相比微不足道，所以这无关紧要。他们只是想削减预算（可能是为了获得基于费用的奖金），并为此而操之过急。”有开发者表示。
“我确信他们正在对他们用于构建产品的所有开源软件（OSS）进行彻底审核，以确保没有任何俄罗斯人编写的 LoC”。有开发者爆料称，“IBM 也放弃了 JetBrains 产品以降低成本。现在所有开源软件都必须经过评级系统。IntelliJ Community 版本评分很低（只是因为评级过程本身很荒谬），因此被禁用了。”
对于转向使用的 VSCode，大多数开发者给出了“差评”：“我是一名 .NET 开发，也拒绝使用 VScode。我不知道人们（有专业经验的人）怎么忍受这种垃圾的。”还有开发者表示，“作为一名 JetBrains 用户，我真的很遗憾。当你习惯了某个 IDE 的高效性，转变确实很难。我给你的唯一建议是，VSCode 会随着时间的推移而适应，一些同事已经做出了自己的选择。但这确实很困难。你的公司做出了一个糟糕的决定。”
JetBrains 声明了立场，但似乎没啥用
JetBrains 是一家捷克的软件开发公司，公司有 3 位（联合）创始人：Sergey Dmitriev、Eugene Belyaev 和 Valentin Kipiatkov。据公开资料显示，这三位均是俄罗斯人，毕业于圣彼得堡国立大学。2022 年 3 月，俄乌冲突爆发后，现任首席执行官 Maxim Shafirov 第一时间在官网上发布声明称，“谴责俄罗斯政府的攻击行为”，并将无限期暂停在俄罗斯的销售和研发活动，白俄罗斯的销售也无限期暂停。8 月份，JetBrains 提交了俄罗斯法人实体的清算文件。
当年 12 月，除了终止所有销售业务外，JetBrains 在俄罗斯的所有办事处（包括莫斯科、新西伯利亚和圣彼得堡）均已关闭。圣彼得堡新园区的建设工作也已终止。所有研发活动均已逐步停止。
“我们设法将大部分员工从俄罗斯撤出，那些因个人原因无法搬迁的员工，我们不得不与他们分道扬镳。”Shafirov 说道，“将 800 多人及其家人（包括宠物）安置在一起并非易事。幸运的是，我们能够将员工分配到我们在欧洲的办事处，包括我们最大的研发中心阿姆斯特丹、慕尼黑和柏林。我们还在塞浦路斯、塞尔维亚和亚美尼亚开设了新办事处。”
但上述措施，似乎并没有给 JetBrains 带来 100% 保障。
近日，JetBrains 被美国安全部门调查，该公司被认为与最近发生的 SolarWinds 黑客攻击事件有某种联系。FireEye 和 Microsoft 的分析指出，这是涉及 SolarWinds Orion 软件的供应链攻击，而 SolarWinds 是 JetBrains 的客户之一，使用 JetBrains 的 TeamCity 作为持续集成和部署系统。美方调查认为 SolarWinds 攻击事件来源于 TeamCity 中的漏洞。
多家外媒称，这可能是来自俄罗斯情报部门 SVR 的攻击。俄罗斯驻华盛顿大使馆否认了那些报道，称在信息领域进行攻击的行为与俄罗斯的外交政策和国家利益相矛盾。
Shafirov 也发布声明否认参与了攻击事件，“TeamCity 是需要正确配置的复杂产品，如果在此过程中攻击者以某种方式使用了 TeamCity，则很可能是由于配置错误而不是特定漏洞引起的。” Shafirov 当时还表示 SolarWinds 方面尚未与他们取得联系以获取有关违规的任何详细信息，也没有任何政府或安全机构就此事与他们联系过，他也不知道公司正在接受任何调查。
“没办法，谁让 JetBrains 那几个创始人都是俄罗斯人，大本营还在列宁格勒，程序员大部分还是圣彼得堡国立大学的高材生。它家的 Kotlin 语言，参考 Java 以岛命名，取名自圣彼得堡旁边的科特林岛。JetBrains 要继续发展，即使在捷克注册公司也不行，估计得像 Nginx 让美国公司收购了。”有知乎网友评论道。
还有网友称，“我对 JetBrains 的情况不太了解，但在 2022 年之后，俄罗斯的一些科技公司已经将几乎所有的软件工程师及其家人迁移到其他地方，所有费用均由公司承担。据我所知，有两家公司经历了这一过程，分别是最初也是一家俄罗斯公司的 Acronis 和当地 NVIDIA 办事处。在这两种情况下，超过 90% 的员工都接受了搬迁的提议——这些人往往是最亲西方、最反战的，他们害怕被动员等。因此，我怀疑 JetBrains 在这一问题上可能非常相似，所以我认为‘团队的很大一部分仍然驻扎在俄罗斯’的说法是不准确的。”
从 JetBrains 到 Linux：
开源软件的信任危机不会结束
如果说 JetBrains 因为出身问题而备受美方质疑，那么上个月 Linux 驱逐俄罗斯维护者的行为则间接反映了位于美国总部的软件也要接受审查。
10 月 18 日，Linux 内核开发人员 Greg Kroah-Hartman 向 Linux 内核邮件列表发布了一条消息，显示 MAINTAINERS 文件中的少数 Linux 开发人员已被删除，其给出的理由也比较模糊：“某些合规性要求，删除了一些 Linux 开发人员和条目。”“如果提供了足够的文件，他们可以将来再回来。”
Torvalds 以他著名的犀利风格回应了该决定：
好吧，看来到处都是俄罗斯水军。
进行这一改变的原因非常清楚，它不会被撤销，而且使用多个匿名账号试图伪装成普通人的俄罗斯水军手段，也不会改变任何事情。
那些并非恶意的水军账户、真正的无辜旁观者们，请注意：“各种合规要求”不仅仅是美国独有的。
如果你还没有听说过俄罗斯的制裁，你应该找时间看看新闻。我说的“新闻”不是指俄罗斯政府支持的垃圾邮件。
至于给我提交撤回补丁——请动动你所谓的脑子。我是芬兰人。你认为我会支持俄罗斯的侵略吗？显然这不仅仅是缺乏真正的新闻，也是缺乏历史知识。
据悉，那些从维护者名单中被删除的人员曾负责监督各种 Linux 驱动程序，这些驱动程序确保了与 Acer、Cirrus Logic 等供应商硬件的互操作性。尽管这些维护者已被删除，但他们所贡献的驱动程序代码仍然保留在系统中。
10 月 24 日，Linux 长期开发者、EXT4 文件系统维护者 Ted Ts’o 也做出了一些澄清，他明确指出，不同国家的制裁各有差异，具体规则也不尽相同。至少在美国，存在一些豁免情况，这意味着如果补丁和代码审查是在公开论坛中进行的，比如 LKML 邮件列表，那么他就可以接受。
Ted 还强调，“请记住，内核开发者并不制定这些规则，而是美国、欧洲、日本及其他国家的政府制定的。我的个人优先事项是确保自己不违反任何当地的民事或刑事法律，并确保其他 Linux 开发者也能安全地从事工作。”
“如果 Torvalds 确实受到‘监管原因’的限制，那么他需要引用具体的监管规定以及监管机构，以便将异议转达给正确的人。他未能这样做显然对他不利。”有网友评论称。
还有网友发出质疑，“到底是怎么回事，一个国际项目遵循显然是美国的决定？我希望大家能注意到这一点，不要把宝贵的几年时间浪费在可能在某个时候被抛弃的无偿工作上。下次听到抱怨维护人员不够时，请记住这条新闻。”
“为什么要把开源牵扯到政治中去，这些维护者所做的工作造福了整个世界，现在却受到惩罚？”虽然一些开发者对此抱怨，但是政治因素影响开源世界已经是不争的事实了。
参考链接：
https://blog.JetBrains.com/blog/2022/12/06/update-on-JetBrains-statement-on-ukraine/
https://old.reddit.com/r/ExperiencedDevs/comments/1gqj7qa/my_company_has_banned_the_use_of_JetBrains_ides/
https://www.theregister.com/2024/10/23/linus_torvalds_affirms_expulsion_of/
https://lore.kernel.org/lkml/20241024164939.GL3204734@mit.edu/
