编程与软件工程dusted.codes
我们能信任微软对待开源的方式吗？
Can we trust Microsoft with open source?
2021 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章探讨微软在拥抱开源多年后是否值得信任：作者回顾微软收购 GitHub、力推 VSCode 等举措，并质疑其开源承诺背后是否仍藏着商业考量。评论区则围绕微软的历史（EEE 策略）、Hot Reload 事件中开源工具被降级、以及推动开发者依赖云端专有工作流的长期战略展开讨论。
为什么经久不衰：微软如今主导着 GitHub、VSCode 等关键开源基础设施，其真实意图与商业动机至今仍是开发者社区的核心争议，这篇文章提供了审视这一问题的经典视角。
HN 评论精选
VSCode 的便捷体验可能让开发者不知不觉依赖专有工作流，正是 EEE 策略的理想开局。
我对微软通过 GitHub 和 VSCode 在开源界拥有过大影响力持警惕态度，尤其是考虑到他们的历史。最近我试用 TypeScript 时，在论坛上问如何处理没有类型定义的原生 JS 依赖，得到的回答是“你用 VSCode 吗？它会自动帮你找到社区维护的类型包”。VSCode 这种“点一下按钮就解决问题”的 UX，让开发者在不知不觉中依赖上专有工作流。如果有人想搞 EEE 策略，这会是个不错的起点。
skohan查看英文原文
I'm generally weary of MS having too much influence over open source with Github and VSCode, particularly due to their history. My creep alarm went off a bit when I recently started a project to test the waters with TypeScript. I was asking on a forum how to deal with native JS dependencies without types, and he answer I got was "Are you using VSCode? It will just find the community maintained type packages for you". It seems to me that VSCode's "just click the button to solve my problem" style of UX makes it very easy for developers to become reliant on proprietary workflows without even realizing it. If one were to pursue an EEE strategy, this would not be a bad way to start.
微软的真正目标是把开发者迁移到云端开发环境，从而顺理成章地推销自家云服务。
我认为微软的长期计划是让大多数开发者使用云端编码环境——鉴于软件栈日益复杂、本地开发环境越来越难搭建，这并非不可能。一旦实现，他们就能通过把自家云服务无缝集成到开发工作流中，占据销售云服务的绝佳位置。所以收购 GitHub、大力投入 VSCode、优待自家软件栈，从商业角度完全说得通，但对自由软件恐怕不是好事。
ThePhysicist查看英文原文
I think Microsofts' long-term plan is to get most developers to use cloud-based coding environments, which is not unlikely given that software stacks become more complex to the point where setting up a local development environment is really hard. Once they achieve that they're in a very good position to sell their own cloud services by making the integration into the development workflow really smooth. So their acquisition of Github and the large effort invested in VSCode as well as privileging their own software stack over competing solutions makes perfect sense, business wise. It probably won't be good for free software though.
Hot Reload 从开源的 dotnet watch 中被撤回、变为 VS 2022 专属，坐实了微软对开源开发者的轻慢。
微软承诺支持 dotnet watch 一段时间后突然反悔，这无疑加深了人们本已认为微软不在乎开源开发者的负面印象。微软官方的说法是：为了聚焦最有价值的场景，从 .NET 6 GA 开始，热重载功能将只通过 Visual Studio 2022 提供。也就是说，他们先在开源工具里做了这个功能，又把它收回去变成付费产品的专属特性。
capableweb查看英文原文
Microsoft promising `dotnet watch` for a while and then dropping that certainly doesn't help with the already pretty damaged view of Microsoft not caring about open source developers. Here is the gist of the situation from Microsoft's point of view: > Throughout the last year we’ve been working to enable the best possible Hot Reload experience in Visual Studio 2022 and .NET 6. Part of our goal was to also explore making this feature available to customers through a variety of mechanisms such as bringing the full power of Hot Reload to as many .NET and C++ developers as possible when running through Visual Studio 2022 debugger, supporting Hot Reload when running .NET 6 apps without the debugger, and the very basic Hot Reload support we added to the .NET SDK tools through dotnet watch. > As we reflect on what was accomplished, and what is still in front of us, the backlog continues to grow. This includes many high value scenarios that will benefit the broadest number of developers, including focus areas such as .NET MAUI, Blazor, adding support more types of edits, more optimized experience when working with XAML apps, and much more. > With these considerations, we’ve decided that starting with the upcoming .NET 6 GA release, we will enable Hot Reload functionality only through Visual Studio 2022 so we can focus on providing the best experiences to the most users. We’ll also continue to pursue adding Hot Reload to Visual Studio for Mac in a future release. So, first they wanted "bringing the full power of Hot Reload to as many .NET and C++ developers as possible" but now they shifted to "focus on providing the best experiences to the most users". Best part of this whole thing is the pull request which was opened (https://github.com/dotnet/sdk/pull/22217) but " locked and limited conversation to collaborators" straight after opening it as Microsoft anticipated the backlash but still went ahead with the change. Seems they still have a lot to learn before they can indeed be trusted.
微软内部存在矛盾：既想树立开源友好形象，又在暗中压制威胁自家商业产品的开源项目。
微软内部正在发生一场拉锯战：一方面想以“热爱开源的新微软”形象示人，另一方面又想阻挠 .NET SDK 这类可能威胁自家商业产品的 OSS 进展。多年来微软靠 Windows、Office 赚钱，本可以近乎免费地送出开发工具以维持生态繁荣，如今却在意 VS 和 VSCode 谁更受欢迎，实在奇怪。部门间的内耗也很低效——如果我是高层，我会让这些人把精力放在做出最好的产品上，而不是因为员工给 VS 写 C# 扩展就训斥他。
captainmuon查看英文原文
> The big issue here is that Microsoft has an internal struggle going on at the moment. On one hand they want to be seen as a new version of Microsoft who loves Open Source, but on the other hand they want to actively block advances in OSS projects like the .NET SDK which could undermine their own commercial offerings. For years, the narrative has been that MS doesn't want to give away their tools for free because they don't want to undermine the commerical offerings of their ecosystem. There used to be a ton of companies making development tools, components, and so on. Microsoft mostly made money with Windows, Office, and so on, so they could give away their own tools almost for free (but preferred not to in order to keep the vibrant ecosystem running). It is really odd that anybody at MS cares about whether VS or VS code or an external tool is more popular. Also this whole infighting between departments seems to be contaproductive. If I were top level management, I would tell people to get their shit together. If instead of working together to make the best products possible, a manager tells off an employee for working on the C# extenstion for VS (because it hurts his personal goals) I would at the very least reprimand the manager. That VS code has poor .NET support, or for another example that MS graphical toolkits have so much churn and they don't use them themselves, are really embarrasing mistakes. I'm sure people have been fired for lesser problems...
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选