103. The End of Windows Software

A reasonable question to ask is “Why did Windows 8 need to create a new platform?” Not only did Microsoft have Win32, the tried-and-true real and compatible Windows platform, but the company had pioneered the .NET platform and with Windows Phone 7 extended that platform to phones with Silverlight. This post is my take on the history and how we ended up at this point. It takes us way back and shows how sometimes what emerges as a major strategic problem can trace its origins back much earlier than one might think. In the next section we will unveil the platform to developers at the //build conference.

Back to 102. The Experience

The Windows platform and associated app ecosystem were sick. Across product executives we had a very tough time coming to grips with the abysmal situation. We definitely could not agree on when the situation turned dire or why or if it had. That meant doing something about it was going to be challenging.

Some were so desperate for good news that they grabbed on to any shred of optimism. At one of the infamous Mid-Year Review (MYR) meetings during the development of Windows 7, a country general manager proudly presented their results of the annual developer survey designed to show what platform developers are coding for and the tools they use.  The head of the developer segment for India said they were seeing Windows rise to the top of the chart for the most interesting and targeted platform. Windows! Immediately the room woke up from its MYR-induced stupor. Questions and comments were flying, “What outreach did you do?” “Did you start in University comp sci programs?” “How did you use financial incentives?”

The optimism was misplaced. The realty was even more bleak than a benign survey outlier, a common occurrence when compensation and corporate metrics were attached to surveys. There was no surge in Windows development. Nope, it was the opposite. India had become a favorite location for companies to outsource their legacy Windows software development. We weren’t measuring an uptick. We were literally measuring the final blow to the Windows development ecosystem as companies everywhere looked to place development out of sight and out of mind. I hate to say so, but it was obvious that’s what the data showed. Microsoft itself had incented teams to transition projects to India, and not often the most strategic ones as I had learned when we had to reconstitute the Windows sustaining engineering team.

Through the 1990s and the rise of Windows, BillG hosted an annual dinner for the largest and most important Windows ISVs, the CEOs and founders of leading tech companies of the era. The dinner was always a star-studded affair featuring the legends of the industry including Philippe Kahn, Jim Manzi, Ray Ozzie, Paul and George Grayson, David Fulton, Fred Gibbons, Scott Cook and perhaps 50 more. These were the leaders of the new industry each presiding over companies with hundreds of millions or billions of dollars of revenue. The companies built the tools from my earliest PC days: Borland Turbo Pascal, Lotus 1-2-3, Lotus Notes, Micrografix, FoxPro, Harvard Graphics, Quicken, and more.

As Windows won, ironically the health of these companies declined. There was a natural consolidation. Many were acquired, and their products slowly faded. Microsoft had its competitive products and the rise of Office, Visual C++, Outlook, and others certainly contributed. Microsoft’s singular bet on Windows and early success on Macintosh were factors as well.

It was, however, the internet and the web browser that really changed everything. The above ISVs started their companies in the 1980s on MS-DOS or in the early 1990s on Windows. Anyone starting a company, particularly in Silicon Valley, in the late 1990s started as a web company. Many startups created enterprise software, though we tend to remember the rise of Yahoo, Google, and later Facebook.

A look at the top software companies in 2010 read like a list of industrial giants more than pure play software. PwC published a list, Global 100 Software Leaders, that illustrated how the industry had changed. Among the top 100, there were only three that made tools or productivity software primarily aimed at Windows or Mac: Adobe, Autodesk, and Intuit. There were even more companies that built safety, security, or management tools addressing shortcomings of the PC: McAfee, Symantec, TrendMicro, Citrix, etc. Most of the companies were either transitioning or transitioned completely to web-based interfaces running against datacenter software.

The real end of the ISV dinner happened for me in 1999. The Microsoft Business Productivity Group (BPG) led by Microsoft senior vice president Bob Muglia (BobMu) announced a deal to acquire Visio Corporation for approximately $1.5 billion, Microsoft’s largest acquisition at the time. Visio was a profitable company approaching $200 million per year in revenue and nearly $30 million in net income. Bob was my manager though I didn’t know anything about the deal.

The Visio Corp. founders were the fantastic team of Jeremy Jaech, Ted Johnson, and Dave Walter. Jeremy and Dave had previously co-founded Seattle-based Aldus Corporation where Ted later led the engineering for Windows PageMaker. Aldus was acquired by Adobe in 1994.

Visio was a wonderful product and from the very start engineered a strong affinity to Microsoft Office, often working jointly with us on marketing, sales, and even consistency of product design. The product, an easy-to-use diagramming application, pioneered many structured drawing tools we take for granted today such as stencils of shapes, the ability to modify shape geometry, and magnetic connectors between shapes. The company was headquartered in downtown Seattle when Microsoft didn’t even have offices across the bridge.

Visio was the last poster child of the old ISV world left standing to have started out as a Windows software company. It was one of the first applications developed for Windows 95, a fact that was heavily promoted. Strategically it used everything Microsoft could throw at it from Visual Basic automation to data access APIs to OLE. Ted once joked with me that they would have used Clippy if we gave them the chance.

Ted, who stayed on for a bit with Microsoft and then later returned to work on Internet Explorer (TedJ), was always candid about their journey. He was wonderful to talk with and had the experiences of a founder, which was something I sought out. His view was clear that the days of being a breakthrough independent developer focused exclusively on Windows were over. It wasn’t just the browser, but also the demands of building out an enterprise sales force and having a full product line exclusively devoted to being a Windows ISV. This was even before the rise of mobile.

I had a few conversations with BobMu and SteveB over whether it was a good idea for the health of the ecosystem that we participate in the ongoing consolidation. I think they heard what I was saying as a resistance to the deal because I’d end up managing the team—that wasn’t it at all and I loved the team and product. Visio was a great addition to the Office family and brought a significant amount of expertise with a great team. For me, it meant the only remaining independent and relatively horizontal Windows ISV was Adobe. Should we buy them too? Then we’d be our own ISV ecosystem. It just didn’t seem healthy.

On the other hand, it was inevitable. The Windows ISV world wasn’t what it was, but why?

Microsoft wasn’t standing still while this decline took place. We struggled to build both a coherent strategy and execute effectively. It wasn’t a shortage of strategy, rather it was a combination of several strategies that ended up failing to reinforce each other and ultimately weakened the overall company strategy.

At the core was Microsoft’s collective response to the internet platform—the browser and the server programming model. The Windows team fully embraced the browser as the future platform, pioneering and advancing HTML along the way. In the late 1990s, Windows even redesigned the Windows desktop to integrate HTML and browser technologies on to the surface of the desktop. Still there was no bridge between Windows and the web platform. Windows simply became a place to run a browser. In Windows 7, we finally took a step of relying on Windows itself for browser features when we integrated DirectX graphics that enhanced animation, video, and overall browsing performance. That came after Microsoft ceded the dominance it earned in an earlier era, unfortunately.

This entire time, the Windows desktop API—Win32—went under-nourished, so to speak. It did not really matter because anything done in a new release of Windows would be ignored by ISVs unless it also worked on older versions of Windows. Enterprise PCs continued to run older versions of Windows longer than even the 3-to-5-year upgrade cycle of Windows and PCs were lasting longer as well. No ISV was willing to invest in writing code specific to a new version of Windows for what amounted to tiny marginal gains in functionality or features. Some teams released new features that ran on the installed base of older Windows, further reducing the perceived value of a Windows upgrade. This cycle of distributing new features for the old Windows installed base increased the complexity and fragility of existing PCs by designing implementations of system-level features to work in the context of multiple versions of Windows. It was a mess. Windows had turned into a distribution vehicle for features without a coherent platform strategy.

The Windows Server team faced its own API battle distinct from the client side. In the 1990s the team developed high-performance and scalable web server capabilities such as Internet Information Server. This platform handily won the enterprise market that was buying servers to host web sites along with Oracle databases, Microsoft Exchange email, and corporate file servers. There was an entire new software industry built on servers running Windows that rivaled or even exceeded the size of the old end-user software industry. Companies such as SAP, Siebel, VMWare, EMC, and more rose from this era. These companies were really the platforms of the server era as most also supported Unix, Linux, or even IBM mainframes.

The ISVs and developers of this era were also mostly inside of corporations or consultants, either independent or at shops of all sizes. Their business was in connecting and customizing these new server platforms one customer at time. While Windows along with a database (such as Microsoft’s SQL Server or Oracle) could easily serve web pages, the real business was in building a commerce site, a customer facing catalog, or internal corporate portal and connecting that site to internal line of business systems such as SAP. Windows wasn’t much of a platform for that.

The Developer division built that platform. The origin of .NET was to provide the platform and abstractions for the web application landscape.

Arising during the fierce competition for mindshare with the Java language from Sun, .NET was Microsoft’s own answer to “middleware” or software that was neither an application nor an operating system. The success of .NET proved that a platform does not have to be an operating system but can be anything that developers bet their business on—something we in Office had been saying about Word and Excel for ages. The .NET platform provided for the new world of browser and web server computing what Visual Basic and SQL provided for the Win32 client-server era.

This strategy and execution were incredible. The dominance in the enterprise customer segment prior to the cloud era was unparalleled. The emergence of cloud computing, however, posed new challenges. What had been an annoyance competitively had become the platform of the cloud. The tools affectionately known as LAMP, representing Linux, Apache, MySQL, PHP/Perl/Python and their progeny, defined how the new enterprise public cloud would be built. These were the building blocks of applications built on Amazon AWS as well. Almost as fast as .NET rose to prominence it faded to be the installed base. There’s a footnote to this in that many of the .NET-based systems built and deployed in the early 2000s were mission critical business systems that will be used, maintained, and enhanced for a decade or more.

The story did not end there because in parallel with the rise of .NET for servers, the Developer Division, tasked with battling Java, also had to compete with the use of Java on the desktop. There was ample evidence that the raison d'être for Java on the desktop was doomed to failure, the mantra “write once, run anywhere” meaning that Java programs could work on any type of desktop such as any version of Windows, Mac, or Linux. That was not reason enough to let it go.

As a result, there was a wave of products designed to bring .NET to the desktop to write Windows programs. The languishing Win32 API was no longer receiving much support or innovation from the Developer division. My old product, C++ and MFC the preferred choice of professional ISVs using Win32, was relegated to maintenance mode. Instead, a new and constantly expanding set of technologies from the Developer division were evangelized as the preferred way to write professional Windows software. The names and differences between them are not entirely critical and my intent is not to start a debate over the relative prominence, target customer, or capability of any one of these. Some of the new desktop technologies included: WinForms, Forms³, WPF/XAML, Silverlight, and others that were less visible or more oriented towards application internals.

A defining characteristic of each of the .NET technologies was a strong relationship to Microsoft’s programming language developed for the .NET server platform, C#, pronounced see sharp. This language was designed by the highly regarded language designer Anders Hejlsberg (AndersH) at Microsoft. He was previously at Borland which had licensed his product that became the legendary Turbo Pascal. The use of C# was a dream for BillG who always wanted Microsoft to develop and own a proprietary programming language implementation.

The combination of the C# language and the above growing list of technologies would together be known, confusingly, as .NET. While it made sense from a marketing perspective to have a single umbrella term, it meant for confusing discussions with developers. Were we talking about a language or the API? Were we talking about programming the desktop or the server? Which client API specifically, since they were both discrete and overlapped? This mattered because few developers used the whole of .NET and so when engaging with them narrowing it down mattered.

Even with .NET branding, owning a language was not enough. In fact, as I argued with BillG going way back to C++, a proprietary language was neither necessary nor sufficient strategically. The only thing that mattered in a platform battle was owning the APIs and runtime. Languages are both easy to copy and easy to replace, but the use of APIs in code developers write lasts a really long time. The “P” in LAMP was showing how many languages were already native to cloud computing. As we see today, the poly-lingual era of computing is the norm for most large systems. Enterprises did not like this, nor did the consulting and ISV world that was well paid by enterprises. They wanted a homogeneous C# world they could leverage across projects. The Developer division strategy fed that need to the exclusion of building quality Windows applications.

The other defining characteristic of the new Developer division desktop technologies was the weak or lack of a relationship to Win32. These technologies certainly ran on Windows, but they were not Windows itself and did not have the performance or quality of Win32-based, or what we called native, applications. They were layered on top of Windows architecturally. The strategy was specifically to evolve these technologies separate from Windows so they could be provided across Windows versions and because the implementation was specifically designed to avoid interfering with Windows.

Building .NET this way ensured that the Developer division was not beholden to the slowing and unpredictable Windows ship schedule. The rift between Windows and Developer grew significantly from 2004-2006 as the Longhorn/Vista project progressed. Then, Windows leadership effectively banned .NET from Longhorn because of performance and memory management issues. The Windows team made a rule that no applications written with .NET would ship with Windows Vista.

This infuriated the broad developer community as it seemed like a classic case of “do as I say, not as I do” after years of evangelizing that .NET was the future of Windows. There was a strong sense of betrayal among the .NET community outside of Microsoft, particularly those developing desktop applications. This put them on the defensive, constantly on the lookout for signs that Microsoft was backing down from support of their preferred .NET technology. One member of the .NET developer community consistently checked pre-release builds of Windows Vista creating a nutrition label of sorts and concluded that no more than 4% of Vista used .NET code. That was substantially different than the promise of a fully .NET operating system they believe Microsoft promised them.

Managing an ecosystem comes with a responsibility to maintain a consistency of messaging as well as to avoid undermining the financial investments people are making in that ecosystem.

Windows Server did not see .NET this same way. In fact, Windows Server fully embraced .NET and it became an integral part of the value proposition. Why was there such a difference when only a courtyard separated the teams? .NET was the Server platform, plain and simple. While there were some developers writing native code to the networking, storage, or kernel layers these were the rough equivalents of those writing device drivers for the desktop. They were an important part of the ecosystem, but a very small community. This would have been the right way to separate the different API layers on the desktop, but that was not the approach taken.

Instead, a deep schism was created between the Win32 and .NET APIs on the desktop. This schism went even further than that because .NET itself had non-overlapping technologies where any given development project would likely only pick one, for example Silverlight or WinForms, creating advocates for one part of .NET over another even as the evangelists painted a picture of a .NET family.

There were also various Win32 APIs that weren’t clearly part of the formal definition of Windows, such as DirectX graphics, but were used by different parts of .NET in varying ways. Often .NET would use a technology in Windows, which seemed good on the face of it. Diving in one would find .NET used a subset of Windows that precluded using the full capabilities from within a .NET program. It was super confusing. Such details were often lost in the fervent online discussions and zealotry that surrounding this debate. I understand as I write the preceding that people would want to even debate the merits of these opinions or offer examples of how one could indeed mix and match API sets. Section 091 describes such “stupid developer tricks.”

While the bulk of the world of software developers were moving to or had already moved to the browser, those within the Microsoft sphere of influence were debating the merits of their preferred way to write desktop apps for Windows, so long as it was using C# and not using Win32. There would be few to no pure-play commercial software products for sale that used .NET, other than some tools to support specific hardware or other support products. The Zune desktop app was often used as the example from Microsoft. A rewrite of Visual Studio itself was often discussed in this vein as well.

For the bulk of world’s developers, there was only one thing holding back the browser and HTML-only world so many developers desired, aside from bugs and inconsistencies between browser vendors and versions. Surprisingly, that was Adobe. Adobe acquired Macromedia Flash in 2005. Flash had become the way to bring the power of desktop computing to run inside the browser. It crushed Microsoft’s attempt as previously discussed, called ActiveX. Primarily it won over the world of streaming video having been chosen by YouTube and also the advertising world where Flash was routinely used for obnoxious and intrusive flashing and flyover advertisements, browsing interiors of cars, and movie clips.

Recall that Silverlight, in the 2010 timeframe, had originally been Microsoft’s answer to compete with Flash but had been repurposed to be the API for Windows Phone 7 and subsequently Windows Phone 8. Silverlight was related to the whole .NET umbrella term but came with its own set of constraints. It had little to do with our Windows platform. Silverlight was non-apologetic about running on not just old versions of Windows but also Mac and soon smartphones. Microsoft’s evangelism kicked into high gear for Silverlight. Many Microsofties fondly remember Netflix using Silverlight in the browser in the early days of Netflix.

Adobe Flash would hit a big speedbump, or more correctly a brick wall, along the way. Apple. The iPhone never supported Flash. Many thought this would doom the iPhone as Flash had become so synonymous with the fun part of the web and the economics of the web. The iPhone team worked with Google and YouTube to create an iOS app that played YouTube videos. That was not only the right solution for customers but made clear a deep philosophical point held by Steve Jobs—operating systems are a “thing” not a set of “layers” and to build a good operating system one does not layer one operating system-like technology on top of another.

This view would be seen as somewhat contrarian in the halls of Microsoft since both Silverlight depended on such layers as did the rest of .NET. Outside of Microsoft, people would perceive Apple’s stubbornness about Flash as simply Steve Jobs trying to control things. It was obviously frustrating for Apple. It got to the point that Apple and Steve Jobs needed to say something. The reason was that the iPad was about to hit the streets in mid-2010 and the tech press was hounding Apple over the need to support Flash on such a large screen browser as the iPad if it were to be a true computer and not a phone. It didn’t matter that Adobe never delivered Flash to any phone, as Jobs pointed out, or that on Netbooks Flash ran so poorly as to be useless. They wanted Steve Jobs to fix this.

Steve had a better idea. On April 29, 2010, commensurate with US availability of the iPad, Apple published a missive Thoughts on Flash signed by Steve Jobs. I thought it was brilliant. To this day I believe it was the most concise expression of excellent product strategy and appreciation of great engineering that any CEO anywhere had written during the PC era.

Jobs laid out one of the clearest and most well-articulated strategies for why Flash was not a good idea on the iPhone, or frankly, ever. In terms of strategic clarity in general this remains a standard by which to judge any strategy. He dismantled Flash in fewer than 1,700 words, detailing that Flash was closed, not really part of the web, performed poorly relative to reliability, security, and performance, had poor battery life, did not work with touch, and, most importantly, the whole concept of third-party runtimes is bad for everyone. Was it self-serving? Sure. Apple wanted people to build Apps for the iPhone using Apple’s proprietary tools and platform and everyone knew it. But Jobs wasn’t wrong. In fact, he was precisely right on the negatives, which killed everyone to admit. This was the technical buzzsaw at its finest.

As I read the polemic, I found myself nodding in violent agreement. The current choices we faced in building Windows 8 found us in the middle of the various .NET runtimes each of which shared shortcomings and limitations with Flash. The Jobs memo also took me back to my first product, Microsoft Foundation Classes, when we lived through making all the mistakes of building a C++ variant of a third-party runtime. We discarded the “Old AFX” project after explaining to BillG why what we built in 1991 was so big, slow, and unlike Windows. Everything about Thoughts on Flash resonated. I loved it.

I quickly circulated Thoughts on Flash and talked for a long time with Aleš Holeček (AlesH), by then a vice president leading the creation of the app platform for Windows 8 as the engineering leader of DEVX, the platform counterpart to the UEX user experience team. He had firsthand experience in this problem area having worked on a Flash-like competitor in the early days of the web. We shared a lot of nodding when discussing the Jobs memo.

What Jobs captured so well was that modern computing had moved in a new direction. The idea of a modern computing platform hosting another platform on top of it while that platform essentially emulated, but differently, the underlying native platform was patently dumb. It was a guaranteed way to drag down the whole of the experience across the gamut of reliability, performance, touch, battery life, privacy, reliability, and so on. For certain Jobs’s memo was a full assault on Flash, but it was the whole concept of building platforms on top of platforms that was the problem.

The Developer division did not see the situation the same way.

The tensions and divisions that had been growing between Windows and Developer since the arrival of .NET in 2001 were reaching a breaking point, not just within Microsoft but the developer community as well. From their perspective, Windows 8 should make a big bet on the runtimes they had created just as they had been promised previously.

We were well-aware of this desire and the existing schism in developing Windows 8. JulieLar and I both were rooted in our own experience in the Developer division in the early 1990s. PJ Hough (PJHough) who led the amazing cross-group partnership between Office and Visual Basic to bring VBA to all of Office was now a leader in the division. Our connections were strong. There was a good deal of positive history.

Similar experiences can yield similar engineering results and like Apple we had early in the Windows 8 design phase concluded that Windows needed a new platform, not yet another set of libraries on top of Windows like Flash. The Windows 8 platform needed to be Windows 8 itself, not a library floating on top. We were also determined to build first party apps the same way we were going to seek out developers to build their apps. This “eating our own dogfood” would be a critical validation of the platform. The tools and platform would support a new set of modern needs for Windows 8, paraphrasing from pre-release developer documentation defining the platform attributes:

* It is written to take advantage of the Metro-style immersive experience:

* It provides a UI / look & feel that is compliant with Metro-style including the app bar, animations, typography, layout, and so on.

* It supports modern startup, shutdown, and hibernation, windowing, and process lifetime management.

* It supports app contracts.  App contracts define capabilities apps can follow to participate in Windows controlled UI experiences, such as: live tiles, snap view, splash screen, search, share, notifications, file picking, app settings, connect.

* It runs in an Application Container for security and is completely isolated from other apps.

* It is only delivered through the new deployment technology, the new App Store.

* It is installed per user, not per machine.

* It installs and uninstalls cleanly leaving nothing behind at all.

* It is impossible for an app change the state of the OS in an irreversible way.

Nevertheless, at our unveiling of the user experience in June 2011 we ran right into this sensitivity and brought the full wrath of the .NET community. It was just the omission of a couple of words and a lack of appropriate deference to .NET that set us up for a good deal of pain. In the course of the demonstration, with both Julie and I on stage, we said and echoed each other about a key aspect of the new Metro-style apps.

We said these beautiful, secure, easy-to-build, safe, reliable apps could be built using “our new platform with HTML and JavaScript.” That was it.

It was just a reflex. It was in fact the news. Microsoft embracing the world’s most popular and widely used programming languages for its flagship product was a big deal. It was a key part of how we would make building Windows 8 apps easier and more accessible to legions of developers. It was also differentiated relative to Apple’s proprietary and un-loved Objective-C and Android’s Java that wasn’t living up to the hype. As if to pour gasoline on the fire, JensenH in his video viewed by millions said the same thing. Steve Ballmer even waded accidently into the fray simply repeating the statements made at the D Conference demo.

The problem was we inadvertently sent a message to a very sensitive and on-edge community that we had jettisoned .NET and finally made good on what the Vista team had essentially done by fiat. In an ArsTechnica article documenting the assault on .NET the headline ran “Why Microsoft has made developers horrified about coding for Windows 8” and was so indignant it even quoted an extraneous “uhh” in Julie’s statement, “our new developer platform, which is, uhh, it's based on HTML5 and JavaScript.”

This was a problem of our own making. The strength of this reaction was testament to our incredible evangelism efforts—the success of which greatly outpaced the impact of these technologies in the market. We knew the data from developer surveys and what people were using. We knew what programs were running on Windows PCs through our telemetry. We knew what technologies the new generation of cloud companies were using, and the world’s universities were teaching. We knew that within the Microsoft bubble .NET was everything. While that is a big bubble, it was small relative to the whole universe especially with the rise of mobile platforms. We used to joke about the Developer division surveys that always showed dominance of .NET because of the well-known Microsoft echo chamber or bubble—the survey results said “100% of .NET developers use .NET.”

There were many frustrations with our statement at the D Conference expressed through countless blogs and endless discussions about this transgression. Most began with the notion that HTML and JavaScript were immature and lacked the horsepower to serve as the foundation for great applications. Rooted in this commentary was a disdain for what were routinely dismissed as “script kiddies” or those calling themselves programmers who merely created static web pages or simply modified a few lines of a web pages and claimed expertise. This was from another era and reminded me of the age old “Real Programmers” meme from long before there were memes. The truth is by 2010 real programmers did use HTML and JavaScript. In fact, they were the most used, the most taught, and the most actively developed languages. Taking a buzzsaw to HTML was going to be a losing proposition, no matter the technical merits programming language experts might debate.

The main issue, however, was where this left all the other Microsoft technologies. Disrespecting HTML and JavaScript was simply smoke around the .NET fire. Specifically, where did we see Silverlight and its more feature laden parent WPF and the language C# fitting in. Developers were apoplectic about their investment in Microsoft .NET technologies not moving forward with Windows 8, whether those were WinForms, Silverlight, WPF, C#, or even C++.

Silverlight/.NET expert Mike James wrote, in “Dumping .NET - Microsoft's Madness” that if “the future of Windows apps is HTML5/JavaScript then Windows has no future.” His post went on to explain his idea that Silverlight is Windows, it just runs inside a browser. He also explained how .NET improved the Windows API and making it more readily programmable.

Our choice was to engage at the time without pre-release of code to test or validate what we were saying or wait it out for a Seattle summer when we would have code available. Obviously given the situation the concerned developer community would doubt every word we wrote. We knew once the pre-release code was distributed, we would have to answer these festering questions but could do so pointing to the product. I chose the latter and waited for our developer conference scheduled for September 2011. Engaging online discussions with an asymmetry of information in the context of such deep concerns would be a frustrating exercise for everyone.

Tim Anderson wrote in his blog, “Microsoft Refuses to Comment As .Net Developers Fret About Windows 8” and said, “In fact, it is bewildering that Microsoft is being so careless with this critical part of its platform, even if this turns out to be more to do with communication than technical factors.”

Finally, we could always count on Mary Jo Foley of ZDNet to catch a leak from the Developer division and her sources clearly indicated “Microsoft needs to tell Windows 8 developers now about 'Jupiter' and Silverlight.” Jupiter was the code name of the other part of our Windows 8 developer strategy—to use C#, WPF, and XAML. The article continued “Microsoft's longer-term goal is to align its various developer stacks, giving it a story that's comparable to Apple's. Because Apple supporting iOS on tablets and phones, Apple developers can write once and have their apps run in both places with relatively little modification.” Just as many of the blogs stated, this article also concluded “Like many devs I've heard from, I don't believe Microsoft can't [can] afford to wait three more months to let its developer base know what its intentions are. So far, however, ill-advised silence seems to be the Softies' plan.…”

We had a plan. We had a new platform. It addressed these concerns. We also knew that if we started answering questions now, we’d end up in theoretical debates from June through the developer conference in September. The conference, a rebranding of the PDC to //build, would provide code, tools, and answers to these questions. I thought.

Off to //build to share the platform we built.

On to 104. //build It and They Will Come (Hopefully)

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com