互联网与文化keivan.io
AppGet 之死
The Day AppGet Died
2020 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
AppGet 作者 Keivan Beigi 复盘了自己项目“死去”的经过：微软曾就这款开源的 Windows 包管理器与他接触、洽谈收购或加入微软，最终却发布了自家的 WinGet，而他既没得到职位，也没得到任何署名。文章按时间线记述了他与微软方面沟通、等待、最终被搁置的过程，以及他事后的反思。
为什么经久不衰：它是关于独立开发者面对大公司时权力不对等的经典警示案例——被“借鉴”本身或许无可厚非，但漫长的吊着与零署名才是真正刺痛人之处，多年后读来仍然切中要害。
HN 评论精选
作者澄清：不介意开源代码被用，介意的是核心机制被无署名照搬。
作者本人：代码被复制不是问题，我完全清楚开源意味着什么，也一点不后悔。被无署名拿走的是这个项目的基础，是它实际运作的方式——如果我是会申请专利的那种人，这才是该去申请专利的东西（顺便说，我不后悔没申请任何专利）。我也不是指包管理器的通用概念，那被做过上百次了：Homebrew、Chocolatey、Scoop、ninite 等各有各的做法。但 WinGet 的运作方式跟 AppGet 几乎一模一样。想知道微软 WinGet 怎么工作的？去读我两年前写的那篇讲 AppGet 如何工作的文章。我甚至不为被抄袭生气，那反而验证了我的想法；让我不满的是完全没有给出署名。
kayone查看英文原文
Author here, Because it's sure to come up here is a comment I wrote on Reddit that clarifies somethings, I haven't updated the original article since I'm not sure what the etiquette for updating a highly shared article is. ------ Code being copied isn't an issue. I knew full well what it meant to release something opensource and I don't regret it one bit. What was copied with no credit is the foundation of the project. How it actually works. If I were the patenting type, this would be the thing you would patent. ps. I don't regret not patenting anything. And I don't mean the general concept of package/app managers, they have been done a hundred times. If you look at similar projects across OSes, Homebrew, Chocolaty, Scoop, ninite etc; you'll see they all do it in their own way. However, WinGet works pretty much identical to the way AppGet works. Do you want to know how Microsoft WinGet works? go read the article (https://keivan.io/appget-what-chocolatey-wasnt/) I wrote 2 years ago about how AppGet works. I'm not even upset they copied me. To me, that's a validation of how sound my idea was. What upsets me is how no credit was given.
前微软员工：大公司谈判必须有律师和 IP 保护，否则内部只会算“照抄 vs 雇人”的账。
Keivan 显然被坑了。在微软工作过、见识过那里的官僚作风后，我唯一的建议是：面对微软这种体量的公司，除非你早早请律师介入，否则根本没法跟他们谈条件。以他们的资源，直接拿走你的东西实在太有诱惑力。文中提到 Keivan 在加入微软前试图就技术未来的演进设定一些条件——在微软内部，肯定有长长的邮件线程把与他的谈判逐条转发给法务、已经在评估自研工作量的开发、产品经理等几十号人。不管他们嘴上说什么，内部都在权衡：要不要干脆照抄？要不要雇他，这对责任风险是更好还是更糟？这东西的 IP 保护有多强，我们能“借用”多少？值不值得为一个不受控的 aqui-hire 惹麻烦？公司大到这个程度，除非你有高薪律师或扎实的 IP 保护，否则不能指望他们透明、善意地谈判。跟 MSFT、GOOG 这种资源近乎无限的大厂打交道时，先找到一个法律上站得住的上手位，并假定他们一直在算坑你的成本收益。
ijidak查看英文原文
Keivan obviously got screwed. Having worked at Microsoft, and seeing the nature of the bureaucracy, the only advice I would give for next time is... Just realize you can't set terms with a large company like MSFT unless you get lawyers involved early. Stealing from you outright is simply too tempting, given their resources. I noticed there were some conditions Keivan tried to set regarding the future evolution of the technology before joining MSFT. In a large company like MSFT, there were bound to be large internal email threads relaying a play-by-play of negotiations with Keivan to: inside legal counsel, developers who already gave t-shirt sizes for building the tech in-house, product managers, and dozens of others. No matter what they tell you, they're internally weighing - Should we just rip him off? - Should we hire him? Would that be better or worse for liability? - How IP protected is this? How much can we "borrow"? - Is it worth the hassle of dealing with an aqui-hire we can't control? Would that expose us to even more IP risk, or less? Once companies reach this size, they simply can't be trusted to handle a negotiation transparently and in good faith, unless you have well paid lawyers fighting for you, or well established IP protection. I guess what I'm saying is... When dealing with any large tech company with near infinite resources -- like MSFT, GOOG, etc --, find a legally defensible upper hand, and assume they are weighing the cost-benefit of screwing you. (Sadly, this is exactly why lawyers make so much money.)
抄袭本身尚可理解，真正不可接受的是长期吊着人、利用年轻人的期待。
说实话，被启发、把想法都抄走、决定自己做而不是雇 Keivan，这件事本身不算坏。真正让我血压升高的是那种吊着人的做法。读完这种事我会想：换作我会怎么做？也许让他们先预付我所有的差旅费，不见钱就不开会；也按次对会议和谈话收费，鉴于这故事里他们的名声。他们想占用我的时间，那就得先证明有多认真。不付钱，就不开会，不给虚假希望。但他们清楚年轻极客会因为“微软的人注意到我了”而兴奋，像好莱坞式的成功故事那样多走一英里。谁知道呢，二十年前的我可能也会失控。这种赤裸裸的剥削让我无比恼火。
WesolyKubeczek查看英文原文
I dunno, getting inspired and copying all the ideas, deciding that they can do a good enough job internally instead of hiring Keivan doesn’t sound like a bad thing in and of itself. It’s the stringing along that makes my blood boil. After reading things like this, I’m thinking, what I’d do differently? Maybe have them reimburse all my travel upfront. No money, no meetings. Also, bill all the meetings and conversations. Up front, given their reputation from this story. They want to spend my time, better show how serious they are. No money, no meetings, no false hopes. But they know young geeks can be excited that someone at THE Microsoft noticed them, like in the Hollywood success stories, and walk an extra mile. Who knows, I could have lost my shit 20 years ago. This straight up exploitation irks me to no end. Reminds me of rock stars bedding teenage fangirls and similar shit, maybe this is why.
后续事实：微软后来在 GitHub 上赞助了作者，算是一种迟来的补偿。
值得一提的是，微软目前正在 GitHub 上赞助 AppGet 的作者（据 archive.org 的记录，始于 2021-04-16 到 2021-05-19 之间）。
jka查看英文原文
Note that Microsoft currently sponsors the author of AppGet on GitHub. (that began some time between 2021-04-16 and 2021-05-19 according to archive.org) [1] - https://web.archive.org/web/20210416144938/https://github.com/kayone [2] - https://web.archive.org/web/20210519125607/https://github.com/kayone
历次讨论
同类还值得读
如今电脑上几乎所有操作在感知上都比 1983 年更慢（2017）
Almost everything on computers is perceptually slower than it was in 1983 (2017)
2017 年的推文串认为，尽管计算机硬件比 1983 年快得多，日常操作的感知速度却常常更慢：启动、界面响应和网络应用被层层抽象、动画、后台检查与网络依赖拖累。
互联网与文化上首页 5 次 · 2017–2020twitter.com网站肥胖危机
The Website Obesity Crisis
Maciej Cegłowski（idlewords）的经典演讲文稿《网站肥胖症危机》，批评现代网页越来越臃肿：动辄数 MB 的 JavaScript、追踪脚本和广告，把本可以轻…
互联网与文化上首页 5 次 · 2016–2021idlewords.com编辑精选亚马逊那本标价 23,698,655.93 美元的苍蝇书
Amazon’s $23,698,655.93 book about flies
博文讲的是亚马逊上一本关于果蝇的二手书被标到 23,698,655.93 美元。
互联网与文化上首页 5 次 · 2011–2022michaeleisen.org浏览器 User-Agent 字符串的历史
History of the browser user-agent string (2008)
2008 年的经典文章用戏谑的“创世纪”口吻，讲述浏览器 User-Agent 字符串如何从简单的标识演变成层层叠加的伪装：浏览器为了绕过按 UA 分发的网站检测，纷纷把自己伪装…
互联网与文化上首页 5 次 · 2012–2022webaim.org编辑精选最后的问题——艾萨克·阿西莫夫
The Last Question - Isaac Asimov
阿西莫夫最著名的短篇科幻小说《最后的问题》的在线全文。
互联网与文化上首页 5 次 · 2009–2019multivax.com编辑精选