Windows’ 12.8% poll result measures an audience, not an exodus
According to Windows Latest, Gergely Orosz, who writes The Pragmatic Engineer, asked his audience on X which operating system they use to build software. Roughly 4,000 responses put macOS at 61.6%, Linux at 24.2%, and Windows at 12.8%. The publication also reports a separate LinkedIn poll with around 6,000 votes, producing approximately 66% for macOS, 20% for Linux, and 12% for Windows.
Those are striking results within that audience. Windows finished well behind both alternatives on two platforms, rather than merely losing a close contest with macOS. But Windows Latest also reports that Orosz described his audience as a “bubble,” consisting largely of people working at startups and large technology companies. The poll totals and that audience description remain dependent on Windows Latest’s reporting here; the available corroborating coverage does not independently establish the original voting records.
There are three boundaries to keep around the result.
First, a question about which operating system someone uses does not necessarily establish which one they prefer. Employer-issued hardware, project requirements and existing workflows could all influence an answer. The reported results do not separate those explanations, so calling the Windows figure a pure preference measurement goes further than the question supports.
Second, the two polls cannot safely be combined into a survey of 10,000 distinct developers. People following the same writer on X and LinkedIn might participate in both. Similar percentages provide an interesting parallel, but they do not remove the shared recruitment bias or establish that every vote represents a different person.
Third, a low share is not evidence of a decline. To establish that developers are “still rejecting” Windows in a measurable, ongoing sense would require comparable earlier results or questions about switching and rejection. These polls, as reported, provide neither. They show an audience in which Windows usage is relatively low, without establishing when that pattern emerged or whether Microsoft’s recent changes affected it.
Stack Overflow supplies context, not a competing election result
The 2025 Stack Overflow Developer Survey offers a broader comparison, although it also has important sampling limits. Stack Overflow’s methodology states that its published results used 49,009 responses from 177 countries, collected between May 29 and June 23, 2025.
That breadth is useful, but it does not make the survey a random sample of everyone who writes software. Stack Overflow says it recruited respondents primarily through its own channels, including onsite messages, newsletters, blog posts, advertising and social posts. Its methodology explicitly acknowledges that highly engaged Stack Overflow users were more likely to encounter the invitation.
According to Windows Latest’s reading of the survey, approximately 49.5% of professional developers selected Windows and 32.9% selected macOS. The publication also describes the operating-system question as allowing multiple selections, unlike Orosz’s single-choice poll. Those particular percentages are attributed to Windows Latest rather than independently verified against the operating-system results here.
Even accepting those figures, subtracting 12.8% from 49.5% would produce a meaningless estimate of Windows’ losses. The questionnaires, audiences and collection periods differ. A multiple-selection answer can also record more than one operating system in a developer’s working life, whereas a single-choice poll forces that experience into one category.
The useful comparison is therefore about the limits of generalization. A globally recruited developer-community survey and a technology newsletter’s social following can yield very different answers without either result being fraudulent or mathematically wrong. Neither should be stretched into a census.
This also explains why a general desktop web-traffic chart cannot settle the argument. The relevant question is what developers use to build software; a chart of operating systems generating website visits measures a different activity. Adding another large percentage does not help unless its population and measurement match the claim being tested.
Windows 11’s developer changes address workflow friction
Microsoft’s developer push is a separate, substantive story. Windows Latest reports that its 2026 initiatives include Coreutils for Windows, Windows Developer Configurations, WSL improvements and Linux-container tooling. It describes Coreutils as a Rust-based implementation of familiar GNU command-line utilities running natively on Windows, and Developer Configurations as a WinGet-powered route to installing a development environment.
Independent reporting supports the broader direction, though not every implementation or availability claim. In June, The New Stack described a developer-optimized Windows 11 experience that retunes more than 30 settings and turns off widgets, notifications and in-product recommendations. That is a concrete attempt to reduce desktop interruptions, rather than simply attach a developer label to an unchanged configuration.
These changes address different points of friction. Familiar command-line utilities concern how developers perform everyday tasks. Automated configuration concerns how they prepare a machine. A quieter desktop concerns what interrupts them after setup. Linux support concerns which workloads they can run while keeping Windows as the host operating system.
Grouping those improvements together helps explain Microsoft’s strategy, but it does not make them interchangeable. A developer who wants fewer notifications has a different problem from one who needs a Linux toolchain. Installing familiar utilities does not, by itself, prove that an entire existing development workflow will behave identically.
Availability also needs more care than the phrase “Microsoft rebuilt Windows” suggests. Windows Latest’s account combines shipped tooling, experiments and newer platform claims. Its description alone does not establish that every Windows 11 installation has every component, or that all the container and AI-agent capabilities are generally available. Readers should not treat the feature list as a universal Windows 11 compatibility guarantee.
Most importantly, none of the reported poll questions establishes whether respondents tried these changes. Without that connection, the results cannot measure their effectiveness. A low Windows share after an announcement is not equivalent to a controlled before-and-after evaluation.
WSL makes the host operating system only part of the decision
The Windows Subsystem for Linux, or WSL, complicates a simple Windows-versus-Linux scorecard. Windows Latest describes WSL as Microsoft’s way of giving developers Linux access without requiring them to abandon Windows. A developer can therefore use Windows as the desktop while relying on a Linux environment for substantial parts of the work.
A single operating-system choice does not describe that arrangement particularly well. Without instructions about how to classify it, a respondent might focus on the machine’s host operating system or on the environment where the build tools run. The reported poll does not resolve that ambiguity.
There is also a practical boundary inside the workflow. Windows Latest reports Microsoft’s warning that running Linux build tools against project files stored on the Windows filesystem introduces input/output overhead. That makes file placement relevant to a WSL evaluation: “uses Linux tools” does not fully specify how those tools access a project. No performance measurement in this reporting establishes the size of that overhead for a particular repository.
For an IT department, the implication is straightforward: an operating-system inventory cannot fully describe a developer environment. Knowing that a laptop runs Windows does not reveal whether its development work is Windows-native, Linux-based through WSL, or a mixture. Conversely, knowing that a team needs Linux tools does not alone establish that it must replace its Windows desktops.
This creates a plausible success case that the poll cannot test. Microsoft’s improvements could make existing Windows users more productive without persuading large numbers of Mac or Linux users to switch. That is an inference about how to evaluate the strategy, not a claim that such gains have already been measured.
Choose a Windows developer setup by workload, not poll rank
Developers and administrators should base a platform decision on the work the machine must support, rather than treating either survey as a purchasing recommendation. The reported Windows changes justify examining specific sources of friction; the poll justifies caution about assuming that improved capability automatically translates into wider adoption.
- Treat the 12.8% Windows result as an informal snapshot of Orosz’s X audience, not a global developer-market-share figure or a measured migration rate.
- Keep usage and preference separate unless a survey explicitly asks respondents which environment they would choose.
- When assessing a Windows development machine, distinguish the desktop operating system from the environment that actually runs its tools and builds.
- For WSL workloads, include project-file location in the assessment, because the reported Microsoft guidance identifies a performance boundary between Linux tools and the Windows filesystem.
- Separate generally available components from previews and experiments before making a new Windows feature a team-wide dependency.
Microsoft has concrete workflow problems to address, and its developer-focused Windows changes show that it is addressing several of them. The reported polls establish that Windows is a minority choice in one prominent engineering audience; they do not establish that those changes were tried and rejected. For readers choosing a development environment, the next useful decision is whether a particular Windows improvement removes a real obstacle in their work—not whether it moves an unrelated social poll.