How Microsoft Killed AppGet

How Microsoft Killed AppGet

Last week, Microsoft released a package manager WinGet during announcements at the conference Build 2020. Many saw this as further evidence of Microsoft's alignment with the Open Source movement. But not Canadian developer Keivan Beigi, the author of the free package manager AppGet. He is now struggling to understand what happened in the past 12 months while he was in contact with Microsoft representatives.

In any case, Keivan is ending the development of AppGet. Client and server services are immediately entering maintenance mode until August 1, 2020, after which they will be permanently shut down.

In his blog, the author provides a timeline of events. It all started a year ago (July 3, 2019), when he received this letter from Andrew, the head of the development group at Microsoft:

Keivan,

I manage the Windows App Model development team and, in particular, the application deployment team. Just wanted to send you a short note to thank you for creating appget — it's a great addition to the Windows ecosystem that makes life for Windows developers much easier. We will probably be in Vancouver in the coming weeks to meet with other companies, but if you have time, we would love to meet with you and your team to get feedback on how we can make your life easier in developing appget.

Keivan was thrilled: his hobby project caught Microsoft's attention! He replied to the email — and two months later, after some correspondence, he attended a meeting at Microsoft’s office in Vancouver. Andrew was present at the meeting along with another development manager from the same product group. Keivan says he had a great time — they discussed the ideas behind AppGet, what is not going well in current package managers in Windows and what he plans for future versions of AppGet. The developer got the impression that Microsoft wanted to help the project: they asked what they could do for him. He mentioned that it would be nice to receive some credits for Azure, some documentation on the new MSIX package format, and it would be good to fix issues with individual download links.

A week later, Andrew sent a new email, effectively inviting Andrew to work at Microsoft: "We want to make some significant changes to the distribution of software on Windows, and there's a great opportunity to help shape how Windows and the application distribution system in Azure/Microsoft 365 will look. With this in mind, have you considered spending more time dedicated to appget, potentially at Microsoft?" he wrote.

Keyvan hesitated initially — he didn't want to go to Microsoft to work on the Windows Store, MSI engine, and other systems for application deployment. But they assured him that he would solely work on AppGet. After about a month of lengthy email exchanges, they concluded that the agreement would resemble an acqui-hire — Microsoft hiring the developer along with his program, and they would decide whether to rename it or let it become Microsoft AppGet.

Keyvan writes that throughout the entire process, he wasn't quite sure what his role at Microsoft would be. What would his responsibilities entail? Who would he report to? Who would report to him? He tried to clarify some of these answers during these slow negotiations, but never received a clear response.

After a few more months of very slow email negotiations, he was told that the hiring process through BizDev would take a long time. An alternative to expedite the process would be to simply hire him with a 'bonus,' after which he would start working on porting the codebase. He had no objections, so they scheduled several meetings/interviews in Redmond.

The process commenced. On December 5, 2019, Keyvan flew to Seattle — to Microsoft’s headquarters — and spent the whole day there, interviewing with various people and negotiating with Andrew. In the evening, he took a taxi to the airport — and returned to Vancouver.

He was told to wait for a call from HR. But then, for six months, Keyvan heard nothing from Microsoft. Until mid-May 2020, when an old acquaintance of Andrew announced the release of the WinGet program the next day:

Hi, Keyvan, I hope you and your family are doing well — it seems British Columbia is handling COVID better than the US.

I am very sorry that the Project Manager position did not work out. I wanted to take the time to express how much we appreciate your contributions and ideas. We have developed a package manager for Windows, and the first preview will be live tomorrow at Build 2020. We will also mention appget in our blog, as we believe there is room for various package managers on Windows. Our package manager is also based on GitHub, but obviously with our own implementation and so on. It will also be open source, so we will certainly welcome any contributions from you.

Kayvan was not too surprised. By that time, it was already clear that he would not be invited to work at Microsoft, which did not upset him because he doubted he wanted to work for such a large company.

But the real surprise awaited him the next day when he saw GitHub repository: "When I showed the repository to my wife, the first thing she said was: 'They named it WinGet? Are you serious??' I didn't even have to explain to her how the core mechanics, terminology, format, and manifest structure, even the folder structure of the package repository, are inspired by AppGet."

"Am I upset that Microsoft, a company worth $1.4 trillion, finally mustered the courage to release a worthy package manager for its flagship product? No, they should have done this many years ago. They shouldn't have ruined the Windows Store as badly as they did," Kayvan writes. "In reality, no matter how hard I tried to promote AppGet, it would never grow as rapidly as Microsoft's solution. I created AppGet not to get rich, become famous, or get a job at Microsoft. I created AppGet because I felt that we, Windows users, deserve a decent application management experience as well. What concerns me is how exactly all this was done. Slow and terrible communication. In the end, total radio silence. But most of all, this announcement hit me hard. AppGet, which is objectively the source of most ideas for WinGet, was mentioned only as just another package manager that just happens to exist in this world.. At the same time, other package managers that have little in common with WinGet have been mentioned and explained much more thoroughly.

Keyvan Beygi is not upset. He says that there is no bad without good. At least WinGet is built on a solid foundation and has the potential for success. And Windows users may finally get a decent package manager. For him, this experience has been valuable: 'Live a century, learn a century.'

He explains that copying code is not a problem; that is the essence of Open Source. He does not mean copying the general concept of package/application managers. But if you look at similar projects on OS X, Homebrew, Chocolaty, Scoop, Ninite, etc., they all have their peculiarities. However, WinGet works almost the same as AppGet: 'Want to know how Microsoft WinGet works? Go read the article I wrote two years ago about how AppGet works', he writes.

Keyvan is only disappointed that his work is not mentioned anywhere.

For reference. 'Embrace, extend and extinguish' is a phrase that, as established by the U.S. Department of Justice,, was used at Microsoft to describe the strategy of embedding itself in the software industry that uses widely accepted standards. The strategy involved extending these standards and leveraging those differences to gain an advantage over competitors.

In the case of AppGet, one cannot say that this strategy was applied in its pure form, but some elements can be considered. Advocates of free software view it as an ethically unacceptable way of acting and are still wary of Microsoft's initiative to integrate a subsystem for Linux into the Windows operating system (Windows Subsystem for Linux);). They say that Microsoft, in essence, has not changed and will never change.

How Microsoft Killed AppGet


Source: habr.com

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster