Mary Jo reports that Windows 8 sales are roughly on par with Windows 7 sales. Which is good news for Windows 8, because Microsoft said (at the time) that Windows 7 was the fastest selling OS to that point.

She also points out that actual usage of Win8 isn’t terribly high at this point – which isn’t at all surprising (see my blog post on if Windows 8 is a success).

The real value of the numbers just provided by Microsoft is that they are an apples to apples comparison between Win7 and Win8, and that they demonstrate that Win8 is following roughly the same track as Win7 in terms of production and sales.

That’s good news, given that Win7 is (by nearly any measure) extremely successful, and is considered by many people to be the best OS Microsoft has released. Windows 8 on an x86 machine can basically be viewed as a faster version of Windows 7, plus the ability to run WinRT apps, and so I pretty much think of Windows 8 as a slight improvement over the already excellent Windows 7.

As Mary Jo notes, we don’t know if the 100 million figure includes Windows RT. At this point I’m not sure if that really matters – at least not from a business app dev perspective. Windows RT can only run WinRT (Windows Runtime) apps, and the WinRT dev platform is too new and immature to risk targeting it when building large enterprise apps (not to mention the side-loading cost issues).

At this point most organizations appear to be building new smart client apps using WPF, and of course they continue to maintain a great many Windows Forms apps. The strength of Windows 8, as I see it, is that it remains an extremely relevant and potent business app platform via its desktop mode, which runs Win32/.NET apps at least as well as its predecessor.

If Microsoft resolves the side-loading cost issues so licensing and deployment becomes reasonable for small, medium, and large organizations I do think WinRT has a reasonable shot at being the successor to Win32/.NET for business developers. In another version or two it should stabilize and mature to the point that it is pretty comparable to WPF, and thus is attractive and useful to C#/XAML developers. That’ll probably take a couple years, which is also the timeframe that corporate IT groups will probably be willing to consider upgrading from Windows 7 to Windows 8.

In summary: good Windows 8 sales today means that betting on WPF for smart client development should be pretty safe, and will hopefully have a decent migration path to WinRT in 2-3 years.

This question keeps floating around the Internet, and I thought I’d give my viewpoint.

Obviously I have no more intel on sales numbers than anyone else (which means pretty much nothing). So anything anyone says at this point is pretty much speculation, and that includes me too.

So rather than speculate uselessly, let me provide a bit of narrative.

Almost nobody buys operating systems. This is a truth that has existed since the dawn of the concept of an operating system. Operating systems exist as an abstraction over the hardware that allow developers to build applications without having to deal with the low-level details of interacting with hardware.

Of course over the past couple decades “operating system” has come to include a lot of things. At a minimum these days people expect the OS to include drivers for every type of device ever invented (or to be invented), a nice user interface, and a set of pre-installed “first party” apps. None of that stuff actually is the OS, but most people view it as part and parcel.

Even so, very few people buy an OS. They buy a device (computer, ultrabook, tablet, phone) because the device enables them to do something useful. More precisely the device allows them to run software (apps) that do something useful.

(I’ll freely admit that I’m biased. As a software developer, I do tend to see software as the most important part of this whole picture. And I think I’m correct, because if you give anyone a device and tell them they can’t install any software on that device I can pretty much guarantee you that they won’t be able to use the device for much of anything.)

I’d also suggest that there are two broad categories of “person” in this discussion.

There are regular individuals like you and me. We buy devices ourselves, investing hundreds or thousands of dollars so we can do things like access the Internet, write letters, manage home budgets, send email, play games, etc. Our motivations in buying a device are to gain access to the apps that allow us to do those things we consider worthwhile in life – whatever that might be for each of us. And yes, people like me also get joy out of the device itself because we’re geeks, but most people just see these things as extremely useful tools or toys.

There are organizations (which are also apparently “people” thanks to Citizens United). They buy devices for their employees so the employees can do things that provide productivity and value to the organization. Some organizations are OK with employees using those devices for personal reasons, others aren’t. In almost no case does an organization buy devices other than because an employee needs the device to perform important aspects of their job.

I keep running into people who think there’s no difference between these scenarios. And maybe I’m a little slow, but I really struggle to see how organizations are going to start buying (and supporting) devices outside the scope of enabling employees to be productive. Nor do I see how dock workers, administrative assistants, lab technicians, and other employees are going to start purchasing devices for the intent of using them at work. Actual human people buy devices to make their personal lives better, not because they intend on using them as an alternative for a work-supplied device.

(In other words BYOD is pretty much bunk – but that’s another blog post.)

To judge the success of Windows 8 then, one must evaluate it in the context of people buying devices for their own use, and organizations buying devices for their employee’s use.

From what I’ve seen there is some resistance on the part of people in terms of buying Windows 8. On the tablet side of things there aren’t a lot of apps, and people buy these devices for apps, not the device itself. On the ultrabook, laptop, and desktop side of things people buy a PC because they want to run PC software – all of which runs on Windows 7 just fine, so there’s no obvious reason to go to Windows 8. But there is an obvious reason not to go to Windows 8: everyone knows it is different, and people fear change.

So if I’m a regular person looking to buy a tablet, I’ll probably gravitate toward the tablet with the most apps – hence an iPad or perhaps a Kindle Fire. And if I’m a regular person looking for personal productivity with Office, CAD software, or gaming, I’ll be perfectly happy with Windows 7 (or even Vista) as long as my current computer keeps working.

Please note that I am personally not a regular person in this context. I’m a geek, and thus have been running Windows 8 since long before it was released. But I have sat in restaurants and overheard conversations about Windows 8 by random people – conversations that lead me to be pretty confident that my previous paragraph is correct.

None of this says that people won’t slowly adopt Windows 8 as their existing computers need replacing, because they probably will. And as more people actually start using Windows 8 and tell their friends and neighbors that it really isn’t that scary, then the fear of change will fade. And with any luck the number of apps available for WinRT will grow relatively fast so people will consider buying Windows 8 tablets because they feel confident those devices have good and useful apps.

Does this mean Windows 8 is a success or failure? I don’t know. We are in uncharted territory to some degree, because today’s computers (with their i3, i5 and i7 processors) are essentially identical in performance to computers from three years ago. For the first time in recent memory (and perhaps ever) computers have stopped getting faster, eliminating one of the primary reasons why people would buy a new computer. Now the only reason to buy a new computer is a complete failure of your existing computer, and computers often last a very long time…

In other words, Windows 8 adoption in the personal space might be slower than in the past (we don’t really know). But if it is, I strongly suspect one major factor has less to do with Windows 8 than the reality that few people are motivated to spend hundreds of dollars to buy a computer that isn’t any faster than the one they already have.

On the organizational side of things the dynamic is entirely different. Organizations try to minimize the number of device types, operating systems, and operating system versions because it is extremely expensive to support more than one. Organizations use “apps” (applications, or enterprise software) that is required for the organization to function. When those apps fail the business loses money by the second – often many thousands of dollars per second. Upgrading from Windows X to Windows Y is never done without extensive testing to ensure those important apps work on the new operating system version. And such upgrades are done according to an orchestrated plan that minimizes the time the organization is forced to support both versions.

This is nothing new. This is the reality of enterprise computing that has existed for as long as I can recall (thus dating back well more than 2 decades).

Strangely, I’ve had people argue that this dynamic is no longer true. That organizations are now going to adopt BYOD, even though that directly means supporting numerous devices, operating systems, and operating system versions all at the same time. I’m not sure what these people are smoking, nor am I sure I want to try it because I think whatever they’ve smoked caused some brain damage. But I could be wrong – perhaps organizations are ready to radically increase their IT support costs in order to allow employees to use random hardware devices and operating systems? Or perhaps there is no increased cost to IT because (as one person told me) it will now be the employee’s responsibility to ensure they have a working device at all times – thus all IT support costs will be born by the end users. Something I’m sure will thrill the minimum wage workers in the warehouses who’ll apparently now have to buy and support computers they’d never have purchased before?!?

Back in the world of the sane, what is actually happening is that a great many (most?) organizations are just now migrating from Windows 2000 or Windows XP to Windows 7. This is because those older operating systems are off support, or will be off support in April 2014. No more bug fixes. No more security patches. Nothing. I truly pity any poor souls left on XP a year from now.

This migration from XP to 7 is not cheap. It is not only an IT issue in terms of upgrading hardware, drivers, and operating system installs. It usually also means updating or replacing ancient enterprise software that was written in VB6 or PowerBuilder or other technologies that haven’t been current for many years.

As a result, almost no organizations even have Windows 8 on their radar at all. Virtually nobody is planning for a Windows 8 migration, because they are just now getting to Windows 7. In fact, my informal polling while speaking at conferences around the world is that nobody expects to move to Windows 8 until 3+ years from now.

Does this mean Windows 8 is a failure? Of course not. Remember, these organizations are just now moving from XP to 7. Windows 7 was released in 2009, and only eclipsed XP in 2012 in terms of installs.

Following that time schedule, we won’t know of Windows 8 is a success or failure until around 3 years from now: in 2015.

In summary, is Windows 8 a success or failure? I can’t say. Nor can anyone else, even though a lot of people (including myself) speculate about it quite a lot

The space to watch is the personal/individual computing space, because that’ll move somewhat faster than the organizational space.

Like every previous version of Windows, we won’t know the success or failure of this version until 3+ years after its launch, because enterprises always move at a stately (if not glacial) pace.

I was recently confronted by an odd bit of reality, about which I thought I’d vent a little.

I am the creator and owner of a widely used open source project (CSLA .NET) that has (in one form or another) been around since 1996. If you want an example of an open source project with longevity, CSLA .NET ranks right up there.

And CSLA is “true” open source, in that it uses a liberal and non-viral license, and there’s no commercial option (a lot of OSS projects use a viral license as a “poison pill” to drive any real use of the project to a paid commercial license that isn’t free as in beer or speech).

Recently at a conference I and some colleagues were presenting on some development techniques and patterns, and the code makes use of several open source projects – including CSLA.

Oddly this was a source of blow-back from some in the audience, who thought the talk was “overly commercial”.

Apparently talking about other people’s free open source products are fine, but if you talk about your own then that’s commercial?

And for that matter, how can it be commercial if you are talking about software that is free as in beer and speech? If anything, FOSS is anti-commercial by its very definition…

It would seem, by this ‘logic’, that the primary experts on any given OSS project should not talk about their project, but should instead talk about tools they might use, but don’t actually create or build.

In other words, people attending conferences should never get the best or most direct insight into any OSS product, because presentations by the people who create that product would be somehow “too commercial” if they talk about the stuff they’ve built.

So much for learning about Linux from Linux developers, or jquery from jquery developers, etc.

Obviously that’s all pretty dumb, and similarly I suspect the majority of the people at this conference (or any conference) don’t feel this way and do want the highest quality information they can get.

I think the real issue here is that some reasonable number of people just don’t understand open source.

A lot of people (especially in the Microsoft dev space) have never knowingly used open source – living entirely within the realm of products provided by Microsoft and component vendors.

(whether these people have actually used open source is another matter – and odds are they have unwittingly used things like jquery, ASP.NET, Entity Framework, MVVM Light, Subversion, git, etc.)

I only bother blogging about this because over the past couple years it has become virtually impossible to create any modern app without the use of some open source products.

I can’t imagine anyone building a modern web site or page without some OSS products. Much less a web app that’ll be based almost entirely on OSS products.

Similarly, it is hard to imagine building a XAML app without the use of at least one OSS MVVM framework.

And the same is true with unit testing, mocking, etc.

In short, the best tools available today are probably open source, and if you aren’t using them then you are depriving yourself and your employer of the best options out there.

What this means imo, is that people who think talking about your own open source product is “too commercial” had better grow up and get a clue pretty fast, or they’ll be finding everything to be too commercial…

In 1991 I was a DEC VAX programmer. A very happy one, because OpenVMS was a wonderful operating system and I knew it inside and out. The only problem was that the “clients” were dumb VT terminals, and it was terribly easy to become resource constrained by having all the CPU, memory, and IO processing in a central location.

This was the time when Windows NT came along (this new OS created by the same person who created OpenVMS btw) and demonstrated that PCs were more than toys – that they could be considered real computers. (yes, this is my editorial view )

From that time forward my personal interest in software has been expressed entirely via distributed computing. Sure, I’ve built some server-only and some client-only software over the past 22 years, but that was just to pay the bills. What is interesting is building software systems where various parts of the system run on different computers, working together toward a common goal. That’s fun!!

This type of software system implies a smart client. I suppose a smart client isn’t strictly necessary, but it is surely ideal. Because most software interacts with humans at some point, a smart client is ideal because that’s how you provide the human with the best possible experience. Obviously you can use a VT terminal or a basic HTML browser experience to provide this human interface, but that’s not nearly as rich or powerful as a smart client experience.

For the past couple decades the default and dominant smart client experience has been expressed through Windows. With smart client software written primarily in VB, PowerBuilder, and .NET (C#/VB).

The thing is, I am entirely convinced that our industry is at a major inflection point. At least as big as the one in the mid-1990’s when we shifted from mainframe/minicomputer to PC, and when n-tier became viable, and when the infant web became mainstream.

Prior to the mid-1990’s computing was chaos. There were many types of mainframe and minicomputer, and none were compatible with each other. Even the various flavors of Unix weren’t really compatible with each other… Software developers tended to specialize in a platform, and it took non-trivial effort to retool to another platform – at least if you wanted to be really good.

Over the past couple decades we’ve been spoiled by having essentially one platform: Windows. Regardless of whether you use VB, PowerBuilder, .NET, or Java, almost everyone knows Windows and how to build software for this one nearly-universal platform.

Now we’ve chosen to return to chaos. Windows is still sort of dominant, but it shares a lot of mindshare with iOS, OS X, Android, and ChromeOS. We appear to be heading rapidly into an environment more like the late 1980’s. An environment composed of numerous incompatible platforms, all of which are viable, none of which are truly dominant.

There is one difference this time though: JavaScript.

Please don’t get me wrong, I’m not a rah-rah supporter of js. I am extremely skeptical of cross-platform technologies, having seen countless such technologies crash and burn over the past 25+ years.

But there’s an economic factor that comes to bear as well as technical factors. Unlike in the late 1980’s when computing was important but not critical to the world at large, today computing is critical to the world at large. Individuals and organizations can not function at the levels of productivity we’re used to without computing and automation.

In other words, in the late 1980’s we could afford to be highly inefficient. We could afford to have a fragmented developer space, split by myriad incompatible platforms.

Today the cost of such inefficiency is much higher. I suspect it is too high to be acceptable. Think about your organization. Can you afford to build every client app 3-6 times? Will your board of directors or company owner accept that kind of increase in the IT budget?

Or can you afford to pick just one platform (iOS, Windows, whatever) and tell all your employees and partners that you only work with that one type of device/OS?

(btw, that’s what we’ve done for the past 20 years – we just tell everyone it is Windows or nothing, and that’s been working well – so such a move isn’t out of the question)

Let’s assume your organization can’t afford a massive increase in its IT budget to hire the dev/support staff to build and maintain every app 3-6 times. And let’s assume we collectively decide to embrace every random device/OS that comes along (BYOD). What then?

I suggest there are two options:

1. Return to a terminal-based model where the client device is a dumb as possible, probably using basic HTML – to which I say BORING! (and awful!)
2. Find a common technology for building smart client apps that works reasonably well on most device/OS combinations

Personally I am entirely uninterested in option 1. As I said, I spent the early part of my career in the minicomputer-terminal world, so I’ve been there and done that. Boring.

The only technology that looks even remotely capable of supporting option 2 is JavaScript.

Is that a silver bullet? Is it painless? Clearly not. Even if you ignore all the bad bits of js and stick with JavaScript: The Good Parts it is still pretty messy.

However, VB 1, 2, and 3 were also pretty immature and messy. But a lot of us stuck with those products, pushing for (and getting) improvements that ultimately made VB6 the most popular development tool of its time – for apps small and big (enterprise).

So sure, js is (by modern standards) immature and messy. But if the broader business development community sees it as the only viable technology going forward that’ll bring a lot of attention and money into the js world. That attention and money will drive maturity, probably quite rapidly.

OK, so probably not maturity of js itself, because it is controlled by a standards body and so it changes at a glacial pace.

But maturity of tooling (look at the amazing stuff Microsoft is doing in VS for js tooling, as well as TypeScript), and libraries, and standards. That’ll be the avenue by which js becomes viable for smart client development.

If it isn’t clear btw, I am increasingly convinced that (like it or not) this is where we’re headed. We have a few more years of Windows as the dominant enterprise client OS, but given what Microsoft is doing with Windows 8 it is really hard to see how Windows will remain dominant in that space. Not that any one single device/OS will displace Windows – but rather that chaos will displace Windows.

As a result, barring someone inventing a better cross-platform technology (and I’d love to see that happen!!), js is about to get hit by a lot of professional business developers who’ll demand more maturity, stability, and productivity than exists today.

This is going to be a fun ride!

The final release of CSLA 4 version 4.5.20 is now available for download

http://www.cslanet.com/Download.html

It is also available via NuGet.

CSLA .NET is a software development framework that helps you build a powerful, maintainable business logic layer for WinRT (Windows 8), WPF, Web, service-oriented, Windows Phone, Silverlight, and workflow applications.

This new release adds support for Windows Phone 8 to the existing support for .NET 4, .NET 4.5, Windows Runtime (WinRT), and Silverlight 5.

It also includes some important bug fixes, and relatively minor enhancements in other areas of the framework. So if you are using any previous version of 4.5 you really should upgrade to this new release to realize these benefits.

One other note: this release uses a new WIX-based installer, and so it shouldn’t have the issues people encountered with the InstallShield-based installer used in the previous release. As always, I generally recommend using NuGet to include the assemblies in your projects, as that’s the simplest and most reliable approach.

I know a lot of people have complained that Windows 8 replaced the start menu with the start screen. Personally I rather like the start screen in Windows 8, and haven’t felt the need to seek out a start menu replacement (like the popular Start8).

However, like a lot of people I run Win8 on multiple monitors (on my desktop and when I dock my laptop). Being able to run WinRT apps in only one window, and to really only see one app at a time is extremely limiting to power users or developers or people with multiple monitors.

About 90 minutes ago I installed ModernMix, a program from the creators of Start8 that basically fixes this whole issue. It allows WinRT apps to run in windows, so you can have multiple WinRT apps running at once, and on different monitors.

It is literally like unlocking the potential of Windows 8! Just 90 minutes later my love of Win8 and WinRT has jumped an order of magnitude (and keep in mind, I already really liked Win8).

The ability to have some of my favorite WinRT apps running and visible while using other WinRT apps and/or Win32 desktop apps improves productivity immensely.

For example, I really like Xaml Candy (http://apps.microsoft.com/webpdp/app/8b9e2d69-feed-409c-befb-4ea97f97351a) and have always wished I could have it in one monitor while using Visual Studio in another. Now I can!

Similarly, the ability to have Feed Reader (http://apps.microsoft.com/webpdp/app/d03199c9-8e08-469a-bda1-7963099840cc) sitting in a window on my second monitor makes it much more useful. It never needed to consume all of my massive monitor space, and now it fits in a much more appropriately sized window.

Seriously, installing ModernMix is like night and day in terms of productivity for Windows 8. If you use multiple monitors and/or are a power user or developer you really want this tool.

(note, I don’t work for those guys, nor did I get the product for free – I’m just so happy with the results I wanted to share!)

I’ve now done four posts where I summarize Microsoft’s side-loading licensing scheme in terms of just how it works, what it looks like from various business perspectives, and why I think they have designed this scheme to compete with the wrong target (iPad instead of HTML 5).

1. Cost to enable side-loading on a Windows 8 device
2. Windows 8 LOB deployment ‘story’
3. Perspectives on WinRT app licensing
4. Windows 8 WinRT sideloading update

If you work for a large enterprise with EA/SA agreements and an IT staff that manages all your domain-joined Windows 8 Enterprise workstations you can probably stop reading now. You are the one demographic that is well-covered by the existing licensing model.

If you are a small or medium business, or an enterprise (such as a franchise or co-op org) where you have lots of non-domain joined machines, machines that run Windows 8 Pro, Windows RT, or the lowly “Windows 8” basic edition, then read on.

After my first four posts I heard from community members and people inside Microsoft – “ok tough guy, you’ve said what’s wrong, now how would you do it right?” (to paraphrase of course ).

My first reaction is that this isn’t my job. If Microsoft wants to make WinRT unpalatable for business developers so we all switch to cross-platform HTML 5/JavaScript (h5js) then who am I to stop them? Besides, don’t they have high-paid experts to figure this stuff out, and so why should I give my thoughts for free?

My second reaction is that from 2001-today I’ve had the pleasure of working with .NET, and these have been the most enjoyable years of my professional career. Although TypeScript appears to offer some reasonable wrapper around the horror that is JavaScript, I’d much prefer it if Microsoft didn’t destroy the idea of building WinRT apps with XAML/C#/VB.

So here are my thoughts – though please keep in mind that I’m not a licensing expert, nor did I stay at a Holiday Inn Express last night.

To be successful, WinRT licensing needs to address its real competitor: h5js and/or WPF+ClickOnce. If WinRT is going to levy an additional licensing cost above those technologies, then WinRT must have commensurate benefits to offset that cost.

What is the cost to deploy an h5js app? Effectively zero, because the app downloads from a web deployment server into a browser. The browsers are all free, there’s no per-workstation license to enable downloading HTML or JavaScript, so the cost is essentially zero.

What is the cost to deploy a WPF app with ClickOnce? Effectively zero, because the app downloads from a deployment server and is installed on the workstation through a standardized ClickOnce client process. No per-workstation license is required – as long as you have a legal copy of the OS, .NET (and thus ClickOne) are free.

I’ve already covered the costs of deploying WinRT apps in the current scheme in my previous blog posts. Those costs can easily add up to thousands or even millions of added dollars – just for the privilege of deploying your own app to your own workstations.

So does WinRT have benefits over h5js or WPF that make it work this added licensing cost? Probably not at this time. It is a version 1 technology and so is less mature than h5js or WPF. Unlike h5js it isn’t cross-platform, and unlike WPF it doesn’t have a simple pre-built deployment technology like ClickOnce. It does have two benefits: WinRT apps can run on ARM devices as well as Intel devices, and WinRT offers a superior model for building touch-enabled apps. I’ll let you decide if those benefits are worth thousands or millions of extra dollars.

Assuming we agree that WinRT isn’t good enough to justify the added licensing fees over its competition, the question becomes how to license WinRT side-loading in a competitive manner.

Microsoft has expressed the (imo) very valid concern that they don’t want to enable the free-for-all side-loading model of the Android world. And I agree – the last thing I want is for my kids to yet again be able to download random software from random locations that are infested with viruses and malware. I really want control over what gets into public stores. I want my software to be vetted when it comes from public locations.

At the same time, I absolutely don’t want added cost or overhead or complexity for apps coming from my corporate marketplaces. I’m in consulting, so the model must allow for Magenic to have a marketplace for our employees, and our consultants must also be able to leverage the marketplaces of our clients so we have access to their apps while we’re working for them.

Thus far I’ve accumulated some requirements:

1. No per-device licensing fees
2. One device must be able to access multiple marketplaces
3. Public marketplaces must be controlled (or perhaps there is just the one Microsoft Store)
4. People do work from home, where the “Windows 8” edition is most common, so it should support side-loading as well
5. InTune is a fine idea for deployment, but it shouldn’t be the only option – customized/tailored “marketplace” experiences should be possible

No per-device fees

Let’s start with this requirement. Microsoft doesn’t charge extra for us to use Windows for business, and it makes no sense as to why they think they can charge an extra tax for us to use WinRT for business. This includes discarding the $30/device fee as well as not requiring the InTune per-device/per-month fee.

If InTune has enough other value people will buy it, but h5js and ClickOnce don’t have a monthly fee, so WinRT needs a comparable model.

Multiple marketplaces

As I noted above, employees of a company like Magenic need access to the Magenic marketplace, and to the marketplace of the company(ies) where they are working as consultants. And one would hope we’d have access to the Microsoft Store as well! This implies a way for each device to access multiple “stores” or marketplaces.

Public marketplaces

I’m rather neutral about public marketplaces beyond the Microsoft Store. My only requirement here, is that if Microsoft did allow such a thing to occur then they should be able to revoke any public marketplace’s “license” or “key” if that vendor becomes a source (intentionally or unintentionally) for malware. The bar for any public marketplace should be as high as the Microsoft Store in that regard.

Or perhaps a better solution is to make public stores legally liable for malware. So it becomes possible for me to seek financial or legal recourse if a marketplace allows malware to slip through onto my device?

Work from home

It is patently absurd to think that I can go to Best Buy and purchase a lowly Windows RT tablet and it can side-load business apps, but the most common Windows 8 edition (Windows 8) can’t be used to run my business apps. I can’t envision any justification for this at all, so clearly this just needs to be fixed.

No InTune requirement

I understand the value of InTune – it does a lot of cool stuff, one of which is deployment. But not everyone wants all that other stuff, and making InTune the only real ClickOnce replacement makes WinRT uncompetitive. Again, h5js and ClickOnce have no monthly cost, and WinRT needs a zero cost option as well.

The result

As a result I think the answer is to license deployment servers not client devices.

And for public servers these licenses should be revokable so Microsoft can easily shut down rogue public marketplaces. I’ll leave the public marketplace concept alone for the rest of this discussion, as I’m much more interested in corporate marketplaces.

To make this work for a small business (think 2-500 employees) the cost of a deployment server license/key must be quite low. A 5 person company might spend 10’s or low 100’s of dollars by not beyond that. I can see how Microsoft might want the cost to scale somewhat, so you could envision deployment server licenses working against a “registered device” model. I honestly think Microsoft would be best served by not charging an extra fee, but if they feel they must find a new revenue source perhaps it could work like this:

• <=100 devices $100
• <=500 devices $500
• <=1000 devices $1000

MSDN subscribers should get a <=10 device license as part of their subscription, allowing for software development and testing.

EA/SA customers might get some deployment server license “for free” as part of their negotiated contract.

Interestingly, Windows Phone 8 already has a corporate marketplace concept built into the phone, where you can register your phone with a corporate marketplace. They (to my knowledge) only support one marketplace, but the core idea is there.

To make this work, a server admin must be able to revoke the registration of a client device (employee leaves, device stolen, etc.), and there should probably be a pre-built WinRT app users can run to register their device with a marketplace (perhaps based on access to an appropriate email domain – like WP8 again).

So a Magenic employee would run this WinRT device registration app and enter their magenic.com email address. Perhaps this causes the marketplace server to send an email to that address with a confirmation hyperlink. The user clicks that hyperlink to confirm and the marketplace completes registration of that device, making the apps in that marketplace available to the end user.

Conclusion

Again, I’m not a licensing expert. I’m simply looking at the competitive landscape and trying to figure out how to make WinRT financially competitive with h5js and WPF+ClickOnce. Assuming that WinRT has no incredible value proposition over its competitors (and I don’t see that it does) then it must provide a cost-comparable licensing/deployment model.

Given that h5js and WPF+ClickOnce have a zero licensing/deployment cost, the goal should be for WinRT apps to have a zero licensing/deployment cost.

At the same time, I surely don’t want public marketplaces to come into being without some substantial recourse and penalty for any such marketplace that becomes a vector for malware.

I think something along the lines of what I’ve proposed here can achieve these goals, and can make WinRT into a viable business development platform in the future. My guess is that Microsoft has a few months, perhaps 18 at most, to make this happen (or at least to lay out a clear roadmap) before business developers really start migrating away from Windows toward h5js in an effort to ensure their careers remain vibrant and healthy.

If you’ve followed my blog recently you know I’ve done a lot of research into the licensing around deployment (side-loading) of business apps on Windows 8 (Windows Runtime aka WinRT).

1. http://www.lhotka.net/weblog/CostToEnableSideloadingOnAWindows8Device.aspx
2. http://www.lhotka.net/weblog/Windows8LOBDeploymentLsquostoryrsquo.aspx
3. http://www.lhotka.net/weblog/PerspectivesOnWinRTAppLicensing.aspx

As a result of this two things have happened.

First, I’ve had some interesting conversations with a few people at Microsoft. Some understand the issue, others just don’t get it. If you think this is an issue I suggest you have conversations with any Microsoft people you know because that’ll help educate and pressure them to fix the problem.

As an aside, it is hard to talk to the right people at Microsoft because the Windows Division owns all this stuff and they don’t talk to developers. In fact, they are almost constantly behind what’s known as the “veil of silence” – essentially unable to discuss anything interesting without risk of being fired. This unwillingness to talk to developers on your own platform is pretty ridiculous, and makes it virtually impossible to generate enthusiasm for building apps on the platform. I have hopes that Sinofsky’s departure from Microsoft will eventually allow them to come to their senses…

Second, I’ve had a number of people ask if I think Windows and/or Microsoft is done for on the client, at least in terms of business software development.

Although I think that’s a very real possibility, given just a bit more maturity in the HTML 5/JavaScript (h5js) space, I don’t think the Windows client is a lost cause yet either.

The thing about the licensing/deployment side-loading story is that Microsoft has it set up to be perfectly acceptable to large enterprises. Those orgs almost certainly already have an EA/SA and use SCCM and run domain-joined Windows Enterprise machines. Their Windows RT or other Win8 mobile devices are covered by the SA and/or companion device licensing. So their only incremental cost is the $4/mo/device InTune cost. That’s extremely comparable to the cost of MDM products for iPad/Android devices.

Where the Microsoft story falls short is in the SMB (small-medium business) space where businesses probably don’t have those bigger contracts and IT infrastructure. That’s where the incremental costs start to add up pretty fast (as per my previous blog posts and Excel cost calculator). Of course the long tail suggests that there are a lot more SMB orgs than enterprise orgs, so the poor story for this segment of the market is pretty devastating.

I keep posting and talking bluntly about the licensing/deployment story because I think we all need to be aware of what’s going on. We all need to know it so we can make near-term decisions regarding the use of WPF, h5js, and/or WinRT. And because those of us who enjoy building smart client Windows apps can pressure Microsoft into fixing the licensing story before it is too late.

Finally, speaking of “too late”, that’s a slippery phrase.

Businesses are mostly just now upgrading to Windows 7, and won’t go to Windows 8 for 2-4 more years. So in a sense you can argue that Microsoft has a lot of time to fix the side-loading story, because almost no one is going to care about this for a long time anyway.

On the other hand, the developer community tends to move a bit faster. We’re a fickle bunch. If we don’t perceive WinRT as a viable future platform for business apps then we’ll start retooling our skills to something else in order to preserve our careers. That won’t take 4 years. I suspect Microsoft has less than 2 years to get developer buy-in to WinRT or the siren call of h5js will become too much to bear.

At the moment of course, h5js has no rational or consistent smart client deployment story either. Although its ability to support smart client business development is maturing pretty fast, the only widespread deployment model still requires a real-time connection from the client device to a web server. Once the industry settles on a way to package and deploy “h5js apps” for offline use (and I believe that _will_ happen) then Microsoft’s ability to generate enthusiasm for WinRT becomes much harder.

I see this as a race. Can Microsoft generate enthusiasm around WinRT in the business developer world (by fixing the side-loading issue and by actually talking to developers at all)? And can they do that faster than the h5js world can devise and settle on a reliable smart client story of their own (because they already have developer enthusiasm).

In short:

1. Microsoft has the technical issues pretty much solved, but seems intent on alienating business developers.
2. The h5js world has a lot of developer enthusiasm, but has yet to tackle or solve some critical technical issues

It’ll be fun to see what happens over the next couple years.

A short time ago I decided to move the CSLA .NET project off my self-hosted Subversion server to GitHub.

I’ve used svn for years now, and really liked it a lot. But my server was getting old in the tooth, and everyone seems totally nutso about git. Apparently it not only does source control, but makes a mean gourmet meal and will eventually solve world hunger.

I want to thank Nick Schonning for helping get a lot of the GitHub stuff up and running. He just jumped in and was a great help, thank you!

My original run at moving was to just export the latest trunk from svn and add it to a blank new git repo. Sure I lost a decade’s worth of history, but my wife often tells me I just need to let go and stop being a pack rat

That worked really quite well, or so I thought. The ultimate problem hadn’t really surfaced yet, and wouldn’t for a while longer. You see I was the only person using the repo, and only from a Windows dev workstation, so the (really bad) default settings for GitHub repos in terms of line termination characters didn’t cause me issues.

Here’s some technical detail on the background of the line termination issue if you are curious about stuff that shouldn’t exist in modern computing…

Then Nick kindly ran an svn2git tool and provided me with that decade’s worth of history I’d lost. Awesome! I added that to the repo and merged in the changes I’d been making. I think this is where things started to go awry, because Nick ran that tool on a Linux box, resulting in some files using LF and some using CR/LF line termination characters.

What happens to you at this point is that you change one line in a code file and GitHub thinks you’ve changed every line in that file. And often random other files too. So I’d change one file and end up with a few dozen files in my next commit. Total chaos!

Nick added a .gitattributes file, but the merge of his fork failed. People keep telling me git has flawless merges, but in my brief experience this is far from true… So I added the .gitattributes file directly. And I followed the instructions on the GitHub page dealing with line endings.

WARNING: DO NOT FOLLOW THEIR INSTRUCTIONS – THEY LEAD TO A BAD PLACE!

I was then referred to a stackoverflow post on the topic. Ultimately it appears that this thread (in and amongst the arrogance and anti-Microsoft sentiment) was what fed into the GitHub help page.

AGAIN, WARNING: DO NOT FOLLOW THEIR INSTRUCTIONS – THEY LEAD TO A BAD PLACE!

See the thing is this: I followed the instructions from these two sources. Several times. Carefully, because I kept thinking I’d overlooked some minor detail. At no point was the problem solved. In fact, it turns out that manually adding a .gitattributes file and following these instructions blocked the resolution of the problem.

Scott Hanselman discusses the issue in his blog post on the pink wall (of doom). Although this post has good info, it still left me confused – and that’s the reason I’m writing THIS blog post.

What I learned out of all this is that Scott is right: the GitHub for Windows GUI tool does fix the problem. But only if you haven’t already tried to follow the manual instructions!!!! (also Git for Windows is not the same as GitHub for Windows, and you need GitHub for Windows.

The correct overall solution is this:

Create your GitHub repo

Clone your repo to your Windows dev workstation

At this point you will not have a .gitattributes file in your repo (and this is important!!!)

Add the client-side repo to the GitHub for Windows GUI tool (if necessary)

Then open the repo

And click the Tools | Settings menu option

This is where I hit the problem. Because I’d already done the manual (and not successful) steps to address the problem, I already had a .gitattributes file. As a result my screen didn’t match what I’m showing you here in this blog post. You really need to see the screen I’m showing here!!

The value of this screen is that the GUI tool will perform magic of some sort. It adds a .gitattributes file as shown, and when you click the Update button it will trigger an update to all the files in your repo.

Commit those updates to fix all the line endings for all your files

Then push the commit to GitHub

From what I can determine this has solved the issue. So after wasting several hours farting around with cryptic command line tools, the solution was to let a tool do magic for a couple minutes. If only I’d known to delete the .gitattributes file earlier (or to have never manually created it) I’d have been infinitely happier.

In summary, git does seem pretty cool. But it clearly is no more of a silver bullet or super-solution than anything else in our industry. It is a decent tool, but I suggest taking all the hype about git with a shaker of salt.

First: CSLA .NET has moved to GitHub and has a new home page: www.cslanet.com

Second, the most recent beta version 4.5.12, is now available for download and through nuget. There are a couple bug fixes, and some server-side data portal enhancements to better support the use of IoC containers for creating business objects when using the encapsulated data portal model.

In summary, you can create an implementation of Csla.Server.IDataPortalInterceptor where you can implement code that runs at the very start and very end of every single data portal call. Then you can create an implementation of Csla.Server.IDataPortalActivator where you can assume responsibility for creating an instance of the requested business type, and for initializing the object instance (thus supporting property injection).

Along with this, the data portal now allows you to use interfaces instead of concrete types (assuming you've supplied an IDataPortalActivator of course):

var obj = Csla.DataPortal.FetchAsync<IPersonEdit>();

In this example, the 'obj' reference might be any type that implements IPersonEdit, and the actual concrete type is determined by your IDataPortalActivator implementation. The default implementation is to create an instance of the supplied type, so the supplied type must be a concrete type. As a result, no existing code is affected by this change.

In a recent email thread I ended up writing a lengthy bit of content summarizing some of my thoughts around the idea of automatically projecting js code into an HTML 5 (h5js) browser app.

Another participant in the thread mentioned that he’s a strong proponent of separation of concerns, and in particular keeping the “model” separate from data access. In his context the “model” is basically a set of data container or DTO objects. My response:

-----------------------------

I agree about separation of concerns at the lower levels.

I am a firm believer in domain focused business objects though. In the use of “real” OOD, which largely eliminates the need for add-on hacks like a viewmodel.

In other words, apps should have clearly defined logical layers. I use this model:

Interface
Interface control
Business
Data access
Data storage

This model works for pretty much everything: web apps, smart client apps, service apps, workflow tasks (apps), etc.

The key is that the business layer consists of honest-to-god real life business domain objects. These are designed using OOD so they reflect the requirements of the user scenario, not the database design.

If you have data-centric objects, they’ll live in the Data access layer. And that’s pretty common when using any ORM or something like EF, where the tools help you create data-centric types. That’s very useful – then all you need to do is use object:object mapping (OOM) to get the data from the data-centric objects into the more meaningful business domain objects.

At no point should any layer talk to the database other than the Data access layer. And at no point should the Interface/Interface control layers interact with anything except the Business layer.

Given all that, the question with smart client web apps (as I’ve taken to calling these weird h5js/.NET hybrids) is whether you are using a service-oriented architecture or an n-tier architecture. This choice must be made _first_ because it impacts every other decision.

The service-oriented approach says you are creating a system composed of multiple apps. In our discussion this would be the smart client h5js app and the server-side service app. SOA mandates that these apps don’t trust each other, and that they communicate through loosely coupled and clearly defined interface contracts. That allows the apps to version independently. And the lack of trust means that data flowing from the consuming app (h5js) to the service app isn’t trusted – which makes sense given how easy it is to hack anything running in the browser. In this world each app should (imo) consist of a series of layers such as those I mentioned earlier.

The n-tier approach says you are creating one app with multiple layers, and those layers might be deployed on different physical tiers. Because this is one app, the layers can and should have reasonable levels of trust between them. As a result you shouldn’t feel the need to re-run business logic just because the data flowed from one layer/tier to another (completely different from SOA).

N-tier can be challenging because you typically have to decide where to physically put the business layer: on the client to give the user a rich and interactive experience, or on the server for more control and easier maintenance. In the case of my CSLA .NET framework I embraced the concept of _mobile objects_ where the business layer literally runs on the client AND on the server, allowing you to easily run business logic where most appropriate. Sadly this requires that the same code can actually run on the client and server, which isn’t the case when the client and server are disparate platforms (e.g. h5js and .NET).

This idea of projecting server-side business domain objects into the client fits naturally into the n-tier world. This has been an area of deep discussion for months within the CSLA dev team – how to make it practical to translate the rich domain business behaviors into js without imposing a major burden of writing js alongside C#.

CSLA objects have a very rich set of rules and behaviors that ideally would be automatically projected into a js business layer for use by the smart client h5js Interface and Interface control layers. I love this idea – but the trick is to make it possible such that there’s not a major new burden for developers.

This idea of projecting server-side business domain objects into the client is a less natural fit for a service-oriented system, because there’s a clear and obvious level of coupling between the service app and the h5js app (given that parts of the h5js app literally generate based on the service app). I’m not sure this is a total roadblock, but you have to go into this recognizing that such an approach compromises the primary purpose of SOA, which is loose coupling between the apps in the system…