Ok - I've got a new theory to explain some of Microsoft's more inexplicable behavior. After all the anti-trust muckety-muck they've been through, they're a little gun-shy about taking over the world all at once, so they're hitting a few short flies to the infield to keep everyone off guard. That's my theory, anyway. It's the only thing I can come up with that would explain why they're not swooping in and simply scooping up market share with a big bucket.There are three big areas where Microsoft is just whiffing right now, and I can't believe that this isn't abundantly obvious to them.
- App server integration
- Low-end development tools
- Workflow / business rules
Ok, one at a time now. App server integration. I've remarked in the past that someone could make a big dent in the market by integrating .Net support into a recognized J2EE app server. Gotta be one that's already acknowledged in the market. We've got enough app servers out there already, after all. Build .Net support (via Mono) into an App server such that JNDI and app management work similarly no matter what the app was written in.
Speaking of Mono, for Pete's sake, get behind these guys, already. They've just released Mono 1.1.10, and they're starting on .Net 2.0 support. They're funded largely by Novell right now, and they're doing the best they can to keep up, but there obviously are some things falling by the wayside due to lack of funds / bandwidth (Novell had apparently told them they're not going to fund development of VB.Net support in Mono, for example).
So there's this group of developers sitting in the open-source camp growing a list of followers - throw 'em a bone. Make a public announcement endorsing the guys, and toss them a few bills. You kill two birds with one stone: Mono is going to attract developers who would otherwise be using Java or LAMP on a non-Microsoft platform, so you're eroding someone else's market share, plus you get to point to this great open-source showcase the next time someone starts griping that Microsoft is big and mean and closed and anti-competitive.
My final observation on this point is that I've personally experienced the horror of not being able to sell .Net as a development platform simply because it implies platform lock-in. I ended up having to architect in Java for a shrinkwrapped software product simply because I couldn't get over that point. At that time, Mono was very young, and even alternatives like Mainsoft were just beginning to surface. I don't know how many other people out there are falling victim to exactly the same circumstances that got me, but Microsoft could end all that by just coming out and endorsing / supporting something that offers the promise of open platform support. Compete on the basis that Windows is the best place to run your app -- not the only place it can run.
Next point: low-end development tools. First, when I say low-end, what I mean is low learning curve, not inferior. Microsoft once had a pretty broad spectrum of development tools in Visual C++ and Visual Basic. These tools essentially merged with the introduction of VS.Net. Granted, there are different languages to ease adoption from the various camps, but the biggest learning curve in .Net is the framework itself, and that's the same no matter what language you're writing in. The .Net framework in general, and C# in specific are widely acknowledged to be Microsoft's response to Java, and in general, I think that's a good thing. Hit the mark pretty well, if you ask me.
What's missing, though, is the tool support for everybody else. The original concept behind Visual Basic was to enable Windows development for the masses. Though "the masses" turned out to be a subset of developers, this was still an huge score for Microsoft. You've no doubt seen references to the VB developers who feel scorned an abandoned by Microsoft now that they're ending support for VB6. If you ask me, I think an awful lot of the real hurt those people are feeling is not over the death of VB6, but over the death of the original idea behind Visual Basic.
When a group of customers asks for something that appears not to make sense, you've got to look past the points on the surface to understand what's really irking them. In the case of the abandoned VB developers, the thing they really miss is the simplicity and elegance of early VB. There's a hole in Microsoft's product line, and it's not going to be filled merely by giving away VS.Net "Express" editions.
There's growing support for simplified platforms like Ruby-on-Rails -- largely among Java developers, but the appeal for any developer is obvious (here's an excellent example from the point of view of a J2EE developer). Development platform like ROR have the simplicity and productivity of early VB while offering the ability to run on open platforms -- important for an app you may want to host on someone else's server for $9 / month.
I covered the open platform point already, so I'll stick to the simplicity point here. Lots of people have tried to hit the sweet spot where business analyst meets developer. From the analyst side, we've (nominally) seen UML, which missed badly. We've also seen Microsoft try to extend office with Access and Frontpage and VBA with limited success. The original VB tried to his this spot from the development side, and the "express" products are targeted there right now.
Nice tries, all of them, but not quite enough. Current direction calls for Office to keep pounding away with tools like Infopath and Sharepoint, but we need more. There needs to be a real "less is more" product that knows what its limitations are and is ok with that. Maybe it can't be a whole other product, for fear of fragmenting the product lines too badly. Maybe it's something you insert into word doc or an excel sheet like you'd insert a table or a chart (insert new Application...).
All of this transitions nicely into my last point - workflow and business rules. I've already written about my initial reaction to Microsoft Workflow. By targeting Workflow squarely at developers, Microsoft is missing again that confluence of business users and IT groups. Yes, I know that this is just the beginning of a strategy that's supposed to play out as Vista and Office 12 are released. In the mean time, the business user is left wanting.
This will remain the case even after Office 12 if programming languages are the only way to express business rules. Business Rules Engine (BRE) products are poised for growth soon in the same way that Business Process Management (BPM) apps have grown over the last couple years. Among these BREs are products that can express business rules graphically - no coding required. Most of the BRE's out there lack the scope needed to effectively integrate into the enterprise out-of-the-box, making integrators essential to deployment.
If Microsoft could learn from some of these vendors (or possibly snap up one or three), I'd bet they could produce a fully Office-integrated application that a business person could use to produce solutions that were really enabled from front-office to back-office.
The good news for everyone who isn't Microsoft is that as long as they leave these holes unfilled, there's room for other vendors. The part I don't get is why nobody's seen the holes yet.