In the first part of our conversation, Jaime Bernardo, Lead Software Engineer at Janea Systems, walked us through Microsoft PowerToys - a suite of utilities that enhance the Windows experience for power users. We explored everything from window management tools like FancyZones to productivity boosters like Workspaces, and learned how PowerToys serves as a testing ground for features that may eventually make their way into Windows itself.

But PowerToys isn't just notable for its functionality. It’s also one of the most popular open source projects on GitHub. This got us talking about the broader world of open source software: why Microsoft embraces it, how community contributions work at scale, and what businesses should consider when evaluating open source solutions. Here's the second part of our conversation.

Why Microsoft Embraces Open Source

Hubert: I was a bit surprised when I learned that PowerToys is an open source project, which means anyone in the world can and does volunteer to help develop it – and yet, Microsoft actually hires professional engineering teams, such as the one you led, to work in parallel with those volunteers and push the project forward. What incentivizes Microsoft to do that?

Jaime: One thing I mentioned before is early feedback and contributions, which are extremely valuable. But also, this particular arrangement allows Microsoft to bring more visibility into popular open source projects for Windows by integrating them into PowerToys, and then, if they catch on, similar features might be integrated into the Windows operating system.

Sometimes community members open issues saying "Hey, there's this really cool open source tool that I think would fit right into PowerToys." If the project fits, we might make contact with the developers, and some of these projects end up being integrated, with their authors becoming regular contributors.

For example, Text Extractor is actually based on Joseph Finney's project called Text Grab. He keeps his project going, but he also contributes to PowerToys because that's where the PowerToys version of his tool lives.

Joseph Finney’s Text Grab – the inspiration behind PowerToys’ Text Extractor

Hubert: You said before that PowerToys is one of the biggest open source projects on GitHub. Given the size, how difficult is it to contribute to it?

Jaime: Not that hard, actually. In fact, PowerToys has been one of the most popular projects for first-time contributors for many years running in GitHub's Octoverse state of Open Source yearly reports.

Hubert: Can you give me an example of an easier way to contribute?

Jaime: One thing that comes to mind is Quick Accent. It’s a utility that lets you add accented characters like you do on mobile. If you press a character on a keyboard along with the space or arrow keys, you can choose from available accents. Some people contribute by adding characters that exist in their languages that we don't yet support. It's a small but valuable contribution that helps make PowerToys more globally useful.

Quick Accent tool in Microsoft PowerToys

Managing Community Contributions at Scale

Hubert: As we speak, PowerToys has now over 8 thousand registered commits. With so many contributions, how do you maintain code quality and security?

Jaime: We have a two-layer approach. First, every pull request runs automated tests. Then, a human reviewer builds the code locally, looks at it, and sees if everything's safe – for example, if there is any malicious code in the request.

Some pull requests are evidently problematic and get rejected immediately. Other times, we can clearly see that someone is trying to integrate something valuable into PowerToys but hasn't done it quite right. In that case, we might explain to the contributor what needs to change or even help implement their idea properly as part of the development process.

It's a substantial part of project management, given the volume of contributions, but we try to help people see their vision realized in PowerToys. It's very much a community-friendly project.

Example pull request from PowerToys’ GitHub repository

Hubert: Do you ever get contributions that seem designed just to grow someone's GitHub profile?

Jaime: Occasionally, yes. We see pull requests that just reorder code or rename variables to something the contributor prefers, with no real functional improvement. If a PR has no actual value and feels like it's just for GitHub credibility, it gets rejected. We welcome meaningful contributions rather than cosmetic changes that don’t add much value.

Hubert: How do you ensure the right people are reviewing code, especially when some reviewers might also be volunteers?

Jaime: GitHub projects support hierarchical permissions. For example, a maintainer can assign write access to trusted contributors; or configure rules so that pull requests only get merged after being reviewed by someone with appropriate permissions.

Some projects get even more granular. I've contributed to ones where different folders had different owners, and only the folder’s owner could approve changes to that area.

Even in my role as a dev lead on PowerToys, I can't approve pull requests that touch build instructions for our pipelines. They run on Azure, which makes them key for the infrastructure, so they need approval from Microsoft employees themselves.

Open Source in the Enterprise

Hubert: I hear conflicting views about open source in business. If you were advising a business leader who's curious but cautious about using open source, what would you say?

Jaime: I would say a lot of it is just common sense. Look at how many people use a project, how popular it is, what credentials it has. In that regard, open source isn’t so much different than proprietary software. Smaller, commercial products can be unreliable, too. But open source has one advantage you’ll never going to get with closed-source projects: transparency. in principle, you can look at the code, see if everything's correct, and build it yourself if you're not sure.

It’s the same reason open source gives you more flexibility in terms of customization. If your company has specific needs, your technical team can pick and choose which parts of an open source project to implement, and they can even tailor the code to your own needs. With proprietary solutions, you'd need to request changes from the vendor and wait for their implementation timeline.

Hubert: What about support and reliability concerns?

Jaime: Open source doesn’t preclude support. In fact, an open source project may be simultaneously backed by several organizations that provide professional support, so you're not always limited to community forums. The key difference is choice - you can select which support organization to work with, rather than being locked into the original vendor.

In terms of vulnerabilities, open source code usually has more eyes on it than proprietary software does. Why? Multiple organizations often rely on the same open source project, so one vulnerability would derail entire businesses. This creates a strong incentive to introduce fixes.

Conversely, proprietary software suffers from what’s called "security by obscurity". Without the kind of public scrutiny that open source enjoys, proprietary software can harbor serious vulnerabilities for years. Sometimes the vendor may even be aware of those vulnerabilities, but not prioritize fixes.

Evaluating Open Source Projects

Hubert: Suppose an open source project caught my eye, but I don’t have time to audit the code or delegate it to someone else. What would you recommend paying attention to?

Jaime: Stars and forks will give you a sense of popularity. Apart from that, look at activity levels - are there recent issues, pull requests, active development? You could also search the web for others who've used the project and can vouch for it.

The contributor count is also informative. For example, PowerToys has 572 contributors at the moment, which means that many people have examined and improved the code. That's a strong indication that the project has been thoroughly reviewed.

Hubert: Hubert: What if I’m concerned about using open source for fear of others gaining unauthorized access to my sensitive data?

Jaime: Code transparency and data confidentiality are two separate concerns. “Open” in open source doesn’t refer to data but to code. In fact, best practices in software development stipulate that sensitive information, like user data or cryptographic keys, should never live in the codebase. Instead, your local environment supplies them at runtime, so they’re out of reach of bad actors or unauthorized figures.

If anything, the transparency of open source code makes the data less susceptible to compromise, not more. The community will quickly notice, flag, and fix security errors such as encryption mishandling. Similar vulnerabilities, on the other hand, can persist in proprietary binaries for years.

The important thing to keep in mind is that any properly designed software, whether it’s open or closed, keeps secrets out of source, so you don’t have to worry about your data.

The Dependency Challenge and Broader Ecosystem

Hubert: You have assuaged my concerns about confidentiality, but what about availability? There's a famous XKCD comic about how the operation of an entire, mission-critical infrastructure may literally hinge on a random project maintained by one person. What's your take on that?

"Dependency" by XKCD

Jaime: That's a popular comic for a reason. It highlights a real issue. One of open source's main benefits is that you can re-use the code. This goes back to what I said about flexibility.

On the one hand, that flexibility is great, because you can basically build a complete, patchwork infrastructure by surgically combining various open source projects into something tailored to the core of your business. But on the other hand, doing so may end up creating a wobbly dependency tower that could topple over if a small but crucial open source project happened to disappear.

We saw this a few years ago in the JavaScript world with "left-pad", a simple library with just 11 lines of code that left-padded strings with spaces or zeros. When the author unpublished it from npm, thousands of applications broke overnight for something ostensibly so basic.

There's also a growing trend of malicious actors targeting widely-used open source libraries to install backdoors that get distributed to many dependent projects. That’s why when using open source dependencies you don't maintain, you should lock to specific versions, verify downloads match expected checksums, and review code when possible. Ultimately, like so much else, responsible open source use requires a combination of trust and vigilance - a function of project popularity and community oversight.

Open Source Beyond PowerToys

Hubert: You talked about how open source outmatches closed source in terms of transparency or security, for example. I wonder what about usefulness. Can you think of some open source projects so good they eclipse any proprietary alternatives?

Jaime: Visual Studio Code is a perfect example. It's open source and developed by Microsoft, but in my opinion, it's superior to Visual Studio - the proprietary IDE that Microsoft sells - for code editing tasks.

Visual Studio has better debugging and build tools for Microsoft technology stacks. But when it comes to pure code editing, project navigation, plugins, and working with non-Microsoft languages, VS Code is significantly better. I even use VS Code for editing C# projects that I'll build and debug in Visual Studio because the editing experience is just superior.

Hubert: What other open source tools are part of your daily workflow?

Jaime: More than you might expect! Chrome and Firefox browsers are open source. For text editing, I also use Vim or Notepad++. Git for source control is ubiquitous. Windows Subsystem for Linux lets me use entire Linux distributions and their associated toolchains without leaving the Windows operating system. In fact, Microsoft has even open-sourced their Terminal, so every time I run it in Windows, I’m also relying on open source.

The prevalence of open source is truly remarkable. In all honesty, I might be using tons of open source tools on a daily basis without even realizing their licensing model. That’s how integrated open source has become into modern development workflows.