Where Microsoft’s open source policy went wrong

Instead of restricting which open source software can be sold, Microsoft should eliminate ambiguity in its Microsoft Store policy and reaffirm the rights of developers to sell their work.

Neon Open sign
Thinkstock

In 2001, then-Microsoft CEO Steve Ballmer called Linux “a cancer that attaches itself in an intellectual property sense to everything it touches.” This comment was only one part of Microsoft’s anti open source campaign that began with Bill Gates’ 1976 letter, Open Letter to Hobbyists, which took aim at piracy in the hobbyist community.

Over the past decade, Microsoft has changed its tune on the open source community. It has sponsored open source conferences, hired open source developers, and emerged as one of the top contributors to the Linux kernel. Most recently, Microsoft announced, then postponed, a new Microsoft Store policy designed to prevent outside developers from monetizing previously free and open source software. While the policy would have helped curtail fraud, it also would have inadvertently prevented IP owners from profiting off their own work.

After receiving backlash from the open source community, Microsoft delayed enforcement of the policy to clarify its intentions. But whatever the new policy looks like, it must strike the right balance between upholding the freedoms that open source software is built on, while also protecting against piracy and fraud.

Good intentions

Microsoft’s heart is in the right place when it comes to repairing ties with the open source community. Fraud is common on app stores: Of the top 1,000 apps on Apple’s App Store, nearly 2% are scams that have finessed an estimated $48 million from customers. Microsoft’s policy would mitigate a specific type of fraud but would unfortunately also restrict how developers can monetize their open source software.

Setting restrictions on monetization is a delicate matter. Open source software thrives because of its versatility: Users can run, redistribute, and inspect applications without worry. Restrictions on that freedom set a dangerous precedent. Instead, Microsoft’s new policy should promote novel ways for developers to profit from their open source software.

Here are four monetization methods Microsoft could support that would allow open source developers to profit from their creations.

Pay for convenience

Any developer, regardless of experience, can use open source software once it’s up and running. But installing this software can be tedious, which gives developers a monetization opportunity. Many users would pay for installation assistance to save time or money—or better yet, to have the application installed in their systems to begin with.

Some open source creators decide to make their applications available on the app stores for a small fee. Users can manually install the open source versions, saving some bucks in return for having a hassle-free, one-click install. Users pay extra for the added convenience, making it a great way for the developers to profit off their work.

Pay for support

Users in the open source community go out of their way to help one another. That’s admirable. It’s common to see users ask and answer questions about running specific software on community forums. But the timing and accuracy of an answer is out of the asker’s hands, which can cause stress if they’re under a time crunch. For users who need a more definite timeline, open source developers can offer a solution.

Red Hat, one of the first companies to monetize open source software, does exactly that. In addition to selling open source products, Red Hat’s subscription package includes extensive customer support and troubleshooting services. This combination is a big reason IBM acquired Red Hat for $34 billion in 2019. We still don’t know the final text of Microsoft’s new policy, but it seems this monetization case would be allowed.

Pay for management

Many organizations underestimate the effort it takes to manage complex open source projects. IT teams need to have a deep understanding of cloud computing and security best practices as well as programming and data administration to successfully implement them. Instead of hiring specialists to manage open source, companies could outsource these responsibilities to a third-party provider.

For example, my company, Aiven, offers a fully managed cloud data platform that frees developers up to create applications instead of stressing over management. Offerings like these enable organizations to increase their open source usage without having to hire additional IT employees. It’s a common and useful model that Microsoft should want to allow with their new policy.

Adopt open core

An open core (or freemium) strategy is when companies offer a limited version of a product as open source and an add-on version as proprietary software. Open core is controversial, with some critics saying the additional fees mean it can’t fall under the open source umbrella. Regardless, open core enables developers to generate interest for their products while keeping the core of their offering open source. This business model is well known to the app stores with all the freemium games, so I don’t expect the new policy to affect this business model.

Some of these strategies were impossible for developers to deploy under Microsoft’s initial Microsoft Store policy. Instead of acting as a gatekeeper when it comes to which open source software can be sold, Microsoft should eliminate ambiguity in its updated policy and reaffirm the rights of developers to sell their work. A more inclusive approach would help Microsoft continue to mend relationships between its brand and the open source community.

Josep Prat is open source engineering director at Aiven.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.

Copyright © 2022 IDG Communications, Inc.

How to choose a low-code development platform