IIS 7.0: Too Little, Too Late?

March 2007 Cover of MSDN Magazine Back in January 2006, I blogged about how much I wanted an IIS 7.0 that handles extensionless URL rewriting. Well this week I just got my March 2007 copy of Microsoft’s MSDN Magazine in which they ran a detailed technical preview of the features and functionality of Internet Information Server 7.0. Reading through it, I found myself salivating over it’s capabilities that I’ve needed for literally a decade. Those who follow some of my other escapades know that the #1 feature I want it to provide over IIS 6.0 and prior is the ability to fully control the URL with our without an extension. Yet, something is different now. Five years ago I would metaphorically have killed for that functionality. Even a few years ago, I wanted it badly. But reading about all the great things in IIS 7.0 today for future availability on server hosting platforms next God-knows-when (i.e. after Longhorn ships *and* most Windows-offering web hosts upgrade) sadly comes across to me as just too little, too late.

Too Little

Too little because Microsoft won’t deliver IIS 7.0 to run on Windows 2003 Server necessitating a costly and in some cases problematic operating system upgrade. This will drastically limit the number of situations in which people can choose to switch to develop for the new features of IIS 7.0. For example, when the funds for operating system upgrades are not in the budget or simply because the developer doesn’t have the corporate clout to convince management of the need to upgrade.  And the only people who will even be able to experiment with IIS 7.0 will be those with Windows Vista. And since upgrading to Vista also requires funds and often new hardware, it is not a foregone conclusion. Consequently there will only be a small percentage of Microsoft-centric developers writing web apps that uses the functionality of IIS 7.0 over the next several years. Given the limitations of IIS 6.0, I just find this scenario to be unacceptable.

Too Late

Too late because Microsoft’s outdated process and slow release cycle, which I blogged about last month, has given rise to compelling alternatives on the Linux platform.  And Apache has has many of the key features that IIS 7.0 provides, most importantly via it’s mod_rewrite functionality, that by the time IIS 7.0 is ready for prime time, there’s a good chance only a tiny percentage of web developers will care. I for one need to develop web apps I can run on web hosts today, not wait around and dream for some yet-to-be-determined future brighter day. Microsoft, the rules have changed and you are not immune. You can no longer schedule product updates years out and expect people to wait to pay you for them years from now when free-to-use open-source alternatives addressing the same need exist today. I can no longer bring myself to design or run a web app on IIS 6.0[1] when the URL management functionality I crave is already available on Apache. And by the time IIS 7.0 is released I doubt I’ll even consider running an IIS server.

Unless…

However Microsoft, there is a solution if you will only listen, which I highly doubt. Microsoft You should know more than any other tech company that your key to success is getting developers to write programs for your platforms. Yet on the web developers are voting with their feet and most new web applications not sponsored by a "You don’t get fired for buying Microsoft" large company IT organization are choosing to build on Linux and Apache.  IIS was once the leading server on the web, but today it can barely eek out more than 1/3rd market share. If you don’t stem this time, things will only get worse. Much worse. Here’s what to do: Release IIS 7.0 as an update for Windows 2003 Server and Windows XP that gets installed automatically via Windows update. Offer it in parallel to IIS 6.0 so it must first be configured by an admin and IIS 6.0 disabled, if necessary. Feel free to restrict it in whatever ways you must given 2003/XP’s lack of Longhorn/Vista infrastructure, but don’t use that as an excuse to eliminate key features such as URL management and HTTP response filtering. Doing this won’t change the minds of those who have already given up on Windows, but it will certainly minimize the profuse bleeding.

Footnotes

  1. Given how much I dislike ASP.NET and how frustrated I am with IIS 6.0, I can’t wait till I find the time to move my blog to another program besides dasBlog.

17 comments ↓

#1 George on 02.15.07 at 6:34am

If dislike ASP.Net and IIS why are you still programming in it? Believe it or not some of us developers do enjoy programming in ASP.Net and using IIS. So instead of whining about it, move on…

#2 Jesper on 02.15.07 at 7:44am

Thank you very much for writing about this. I am happy that you are continuing write about the lack of URL Rewrite in IIS 6.0.

I really hope that Microsoft would consider to release IIS 7 for Server 2003. That would be an fantastic gift to the developer community. URL Rewrite is the only thing I need from the new system. I don’t need Vista and longhorn server just yet.

I do love programming on ASP.NET and IIS, but I sometimes get really frustrated over the situation with the URL Rewrites. On all other areas I’m a happy camper. We need people whining over this issue.

#3 Mike Schinkel on 02.15.07 at 1:27pm

George: I don’t still program for IIS and ASP.NET, but I want to; that’s the problem. The reason I write about it is I really want Microsoft to offer better solutions. As stated above, in this post about IIS, I gave a clear suggestion as to what I’d like to see as opposed to just whining as you state. In a future post on ASP.NET I will do the same.

I used to think ASP.NET was the greatest, until I started looking at the alternates. Maybe you should too…

#4 Mike Schinkel on 02.15.07 at 1:28pm

One more thing George. I *really* like .NET, and as much as I like .NET, I dislike ASP.NET.

#5 Mike Schinkel on 02.15.07 at 1:30pm

Jesper: You are welcome! I will definitely keep writing about it. BTW, have you seen my URL-related blog over at http://blog.welldesignedurls.org?

#6 Mike Volodarsky on 02.22.07 at 4:00am

Mike,

Have you checked out ISAPI Rewrite - http://www.isapirewrite.com/? It can provide some rewriting capabilities you may need in the meantime for IIS6.

Also, if you hate ASP.NET (care to explain why?), you may be interested in the recent work we’ve been doing to get PHP running reliably and fast on IIS with the new FastCGI support. This comes in both IIS6 and IIS7 flavors, so you can take advantage of this today. You can learn more and download it from here: http://mvolo.com/blogs/serverside/archive/2007/01/31/Turbo_2D00_charge-your-PHP-applications-with-IIS-FastCGI-Technical-Preview-2.aspx. If Ruby on Rails is your thing, you can try the experimental support in the FastCGI TP2 for it as well: http://mvolo.com/blogs/serverside/archive/2007/02/18/10-steps-to-get-Ruby-on-Rails-running-on-Windows-with-IIS-FastCGI.aspx.

Hopefully this can be of some help right now …

Thanks,

Mike

#7 Mike Schinkel on 02.22.07 at 5:32am

Mike Volodarsky: Thanks for stopping by.

"Have you checked out ISAPI Rewrite - http://www.isapirewrite.com/? It can provide some rewriting capabilities you may need in the meantime for IIS6."

Have I checked ISAPI Rewrite? Well, do these links of mine answer? :)

http://www.mikeschinkel.com/blog/category/ISAPI+Rewrite/
http://wiki.welldesignedurls.org/ISAPI_Rewrite

And also, how the heck do you think I managed to get dasBlog to use URLs without the .ASPX extension? ;-)

I’ve been using it and writing about ISAPI Rewrite for a long time. Problem with ISAPI Rewrite is that most shared hosts will not even install it, and as I’m the Lead Advocate for The Well Designed URLs Initiative[1] that fact that many people running IIS can honestly tell me they CANNOT use Well Designed URLs upsets me more and more every time I think about it.

Why don’t you guys just buy ISAPI Rewrite and include it in a patch of for Windows 2003 Server?

>> Also, if you hate ASP.NET (care to explain why?),

I’ve been meaning to explain in depth, and kept putting it off waiting to collect up ALL the reasons and to do all my research on the subject, but I did just provide a list of my complaints over on SitePoint[2]. I plan to be discussing each of those points in detail during the coming months…

>> you may be interested in the recent work we’ve been doing to get PHP running reliably and fast on IIS with the new FastCGI support. This comes in both IIS6 and IIS7 flavors, so you can take advantage of this today. You can learn more and download it from here: <url>

Yeah, I’ve been watching that and it is quite interesting. Is it something that someone running on a shared host would be able to use? (that’s not an issue for me, but I tend to be an advocate for others as well as looking out for my own needs.)

>> If Ruby on Rails is your thing, you can try the experimental support in the FastCGI TP2 for it as well: <url>

I will definitely be checking these out. BTW, can you provide me your cell phone # for support? (Just kidding! Unless of course you would!)

OTOH, what about Classic Python support (as opposed to IronPython?) For example, the ability to run Django or TurboGears?

Lastly, is there a real technical reason (a subset of) IIS7 can’t be added to XP and 2003 Server?

>> Hopefully this can be of some help right now …

Again, thanks.

-Mike Schinkel

[1] http://www.welldesigneduls.org/
[2] http://www.sitepoint.com/forums/showpost.php?p=3291715&postcount=7

#8 Mike Volodarsky on 02.22.07 at 12:55pm

Re: FastCGI for shared hosting, the answer is definitely! We are working with many of them already to try this out and make sure their needs are met. I’ll post some information on my blog when accounts with this support start being offered.

If you are interested in IIS7 hosting, there is already a web host that offers free IIS7 hosting so you can try IIS7 now: http://www.appliedi.net/iis7-hosting/.

Re: Python support, its currently being investigated. Its definitely in our sights, as well as Perl. We do welcome any community help in trying different FastCGI frameworks / scripting environments, and helping us find and fix issues in the FastCGI support. You can find the forum / download links off my blog.

Re: Cellphone for support. Sure: 555 - … alright, no, I can’t :) But I am available to answer questions on the http://forums.iis.net, and I occasionally post about common issues and IIS topics of interest on my blog.

Re: IIS7 on Windows XP / 2003. We would love to do this. Unfortunately, the IIS7 code base is deeply tied into the Vista/Longhorn server platform, via APIs, componentized setup technology, etc. Removing these dependencies would be a major task, testing them on IIS6 to make sure the product works as advertised would be an even larger one. We are 150% focused on delivering a solid server product in Longhorn, so unfortunately at this point this kind of effort is infeasible. This is not to say we dont feel the pain for not being able to do this.

One somewhat positive note for the future is that IIS7’s componentized extensibility story makes it possible for us (and of course for anyone else) to change/add to the IIS7’s feature set without releasing a new operating system version. We already have a number of projects that are taking advantage of this, and plan to continue doing so. This means faster release schedules, better feedback loops with the community, and a dynamic features set for IIS going forward. So, we have heard the call of the community … and will be doing our best to answer it :)

Thanks,

Mike

#9 Dave on 02.22.07 at 6:36pm

Nice article, Mike. I agree that not having IIS7 on Windows XP / 2003 is a huge problem. I guess it means I will be forced to move to Apache.

#10 Mike Schinkel on 02.22.07 at 6:58pm

Mike Volodarsky: thanks again for the comments. A few points:
>> Re: FastCGI for shared hosting, the answer is definitely!

Actually, based on your reply, the answer is definitely not! In other words, a shared hosting customer with an existing account cannot add it themselves. Nor can they use it *if* their shared host chooses not to implement it. As is, Microsoft (or possibly the customer) will still have to convince the shared host to offer it, so we still have a case of the "haves" and the "have nots." One of the reasons PHP is available for *every* Linux shared host v.s, say, Python is that it is part of the standard install. I asked a Python developer who runs a web host why he didn’t offer Python, and he said because it doesn’t come in the standard distro; the same issue related to ISAPI Rewrite, expect ISAPI Rewrite has a financial hurdle too.

What would be ideal for the developer (though possible not for the shared host or for Microsoft, I do now know enough about the constraints) would be if the developer could install FastCGI on a shared host themselves. So while it is good news that FastCGI exists and good news that Microsoft is trying to get shared hosts to use it, it is not good news that it will still be far from ubiquitous. Unless of course I completely msunderstood…

>> If you are interested in IIS7 hosting, there is already a web host that offers free IIS7 hosting so you can try IIS7 now: http://www.appliedi.net/iis7-hosting/.

But I already have a hosting account that I pay handsomely for! (ServerIntellect; great service, great support, but expensive.) Seriously, most people already have an account and I view a free account on a non-shipping operating system as a toy and not worthy of using to deploy a web app that is critical to a real business.

>> Python support, its currently being investigated.

Python support is what I am most interested in. And I’m sure it would make your newest colleague Jon Udell really happy! (one example: [1])

>> Its definitely in our sights, as well as Perl. We do welcome any community help in trying different FastCGI frameworks / scripting environments, and helping us find and fix issues in the FastCGI support.

Maybe you should recruit Jon to help. Contact him to see if he’ll interview you about the FastCGI, or even make a screencast. And while you are there, you can ask him about Python…

>> Re: IIS7 on Windows XP / 2003. We would love to do this. Unfortunately…

I understand. Thanks for clarifying.

>> One somewhat positive note for the future is that IIS7’s componentized extensibility story…

Yeah, it’s just hard to override the fact that these days most people are far less interested in what’s coming down the pike when compared with what they can do today as there are great alternatives. But those alternatives lead down a path for which there is little chance of returning to IIS.

ALL THAT SAID…

…and in the category of "necessary but not sufficient," you still didn’t address URL Rewriting on IIS6. Sure, FastCGI is all well and great, but it only makes *performant* what was previously already possible[2]. Performance is not that important on low traffic sites and there are many more of those, but clean URLs are important everywhere. URL Rewriting is simply *not* possible on IIS6 if you ignore ISAPI filters that do not ship with IIS for the moment. Yes, I guess it is *possible with Wildcards but doing so is incredible complex annd I’ve never seen an example of how. Further, according[3] to Scott Watermasysk of Telligent, using Wildcards is also *painfully* non-performant.

Alan Kay’s guideline (emphasis mine) "Make simple things simple, and complex things *possible*" is brilliant yet out-of-the-box IIS6 fails miserably at it with regard to URL Rewriting.

And even in the case of a web developer buying ISAPI Rewrite, they still can’t get many hosts to install it! Here’s a particularly painful thread on Community Server specialist ASPNIX.COM about customer demand for ISAPI Rewrite and their complete unwillingness to offer it[4]. Please read the entire 3 page thread to see just how painful it gets with customers asking for something which really is simple and they just ignore it. Unfortunately, this is not unusual with shared hosts.

Let me give you an analogy. IIS6 with FastCGI support is like that goofy girl from high school that you haven’t seen in years and then you see here and she’s totally changed. She’s matured, is fashionable, and is frankly not really hot. Except for one thing. She still has this huge wart at the end of her nose. And try as you might, every time you look at her your eyesare drawn to that wart and you can’t see anything else. IIS6 without *built-in* URL Rewriting to me like that beautiful girl with the huge wart. I hope that puts it into perspective (and yes my analogy is superficial but hey, what can I say? I’m a guy and us guys are superficial! ;-)

Why the lack of URL rewriting in IIS6 is especially so particularly egregious is because of how it causes people building apps on IIS (and ASP.NET) to think about URL design. Their "design vocabulary" results in the web being littered with many horrible URL designs. And it makes it harder to get users to understand URLs and harder to get web site owners to understand the value in URL design when they see so much crap on the web. Read Jon Udell’s post today [4a] about (among other things) what I call "Monkey See, Monkey Do."

And here [4b] is a discussion of why a major ASP.NET application vendor that you yourself use (Community Server) and why they won’t provide URLs without file extensions (i.e. this is the beginning of the [3].)

So this lack of URL Rewriting bothers me so much that I will continue to rant about it on this blog, over at [6], and anywhere else that I can find an audience. Here’s hoping you will realize it as a serious problem that needs to be addressed and *finally* take action on providing built-in URL rewriting support in IIS6 that will work everywhere, including shared hosts, and not just in boxes that one has admin control of.

-Mike

P.S. Far be it for me to complain but not offer a solution. Here are several solutions, in order of recommendation:

1.) Buy ISAPI Rewrite, incorporate into IIS6, slip stream it into Windows Update, and recommend shared hosts make it available to their customers.

2.) Work a deal with Helicon to incorporate the freeware version ISAPI Rewrite in IIS6, slip stream it into Windows Update, and recommend shared hosts make it available to their customers.

3.) Incorporate Ionics ISAPI Rewrite Filter into IIS6, slip stream it into Windows Update, and recommend shared hosts make it available to their customers (I don’t like this so much because you will devastate the Helicon guys, but if you did this they could still add innovation on top by, for example, support URI Templates[8].)

4.) Bring ISAPI Rewrite and Ionics ISAPI Rewrite Filter in house for TESTING, so you can endorse them to shared hosts as being solid. What I hear from hosts I ask about this is they say "We don’t run IIS filters for fear they will cause us problems with our servers." Yet those same hosts run asp.dll and aspnet_isapi.dll all day long without a care in the world! You see my point?

5.) MINIMALLY please evangelize the NEED for the same web hosts that you are talking to about FastCGI to provide customers with a solid URL Rewriting solution, be it ISAPI Rewrite, Ionics ISAPI Rewrite Filter, or something else. Tell them customers are DEMANDING it, or those same customers will switch to Linux (that’s what I current recommend to all my clients, because of the URL Rewriting problem…) Actually, don’t tell the shared hosts that already run Linux because they’d rather sell Linux hosting accounts. :)

I really hope you will reply to this specific issue (if not, I’ll just have to write a new blog post about it, and start all over! :) And I’m hoping that reply is better than just "I feel your pain" but will discuss concrete steps to address the need for URL Rewriting at shared posts.

P.P.S. Oh, one last thing I just remembered; there *is* a way to accomplish URL rewriting on IIS6[9]. And while I will give that this technique is very inventive, if you care anything at all about proper use of the HTTP standards it is just too painful for words. See what the community has been forced to degrade to[9] simply because Microsoft hasn’t felt the issue worthy of addressing, over 10 years after the first release of IIS..

P.P.S. Ouch, see what Dave just posted as a finish up the reply about moving to Apache.

[1] http://blog.jonudell.net/2007/01/03/conceptual-barriers/
[2] http://www.visualwin.com/PHP/
[3] http://communityserver.org/forums/permalink/563877/563877/ShowThread.aspx#563877
[4a] http://blog.jonudell.net/2007/02/22/screencasting-tips/
[4b] http://forums.aspnix.com/forums/thread/10330.aspx
[5] http://communityserver.org/forums/thread/563883.aspx
[6] http://blogs.welldesignedurls.org/
[7] http://wiki.welldesignedurls.org/Ionics_ISAPI_Rewrite_Filter
[8] http://blog.welldesignedurls.org/2007/01/03/about-uri-templates/
[9] http://evolvedcode.net/content/code_smart404/

#11 Mike Volodarsky on 02.22.07 at 9:23pm

Mike,

The way I understand your main points is:

1) Ease of adoption for new technology, such as delivering it for existing platforms, is important for getting the technology to be more ubiquitous and benefit more people especially in environments where they themselves rely on others in control being persuaded to adopt it (Case in point, shared hosters, or corporate IT environments).

1.a) FastCGI is definitely not something people on a shared host will be able to use because it requires to get through the adoption hurdle for hosters.

2) Rewriting is critical and is a major lacking feature in IIS6. Again, here the lack of an "official" solution hurts adoption of existing third party products.

I am hoping we can stay away from "product bashing" in this conversation and address the specific issues, since, as you realize I work on the product team so I am not interested in "XXX sucks" type of feedback unless its reasonable and helps me improve the quality of the product in a realistic way. So, I am interpreting your feedback exclusively from this perspective.

Re #1:

We already discussed why IIS7 cannot easily be provided downlevel. We as a team are focused on IIS7 in Vista / Longhorn, and looking to solve a lot of other issues that you dont discuss here that seriously impact our product and business. These include shared hosting isolation, site density, configuration and deployment in corporate environments, and extensibility foundation for a developer ecosystem. Our goal is to provide a foundation for the future where a lot of these fundamental issues are/can be solved. So, while it sucks that we cannot deliver all the goods downlevel, longer term we hope these efforts will pay off in significantly lower TCO for IIS, a more vibrant developer ecosystem and feature set, and overall a better web development and deployment platform.

Re #1.1:

I dont agree with you in that FastCGI will necessarily have adoption problems. The biggest issue today on Windows is that existing ways of hosting PHP are either 1) unstable - ISAPI or 2) non-scalable / non-performant - CGI. There is nothing but gain for a hosting provider to roll over to FastCGI transparently, resulting both happier customers, higher site density per box. This means cheaper costs for Windows hosting / more customers willing to host on Windows = more profit for hosters. There will be NO REASON not to move, and those who wont will be losing money because of it. Also, as I mentioned, we are engaging hosters to aid in this adoption and iron out issues. So, again, will this be available on shared hosting servers? Absolutely.

Note that Zend is also working with us to improve the performance of PHP itself on Windows. They are committed to making things better, and with PHP 5.2.1 already out, we are much closer to where we want to be then we ever were. With more then 80% of developers using Windows for development, the community is very excited about being able to test and deploy on Windows too.

Re #2.

You have a point there - IIS is missing an industry standard re-writing solution today. With IIS7, we have a number of enhancements in the platform to enable this solution to be built, and I wouldnt mind discussing some ideas I have directly with you if you are interested. If you consider the gargantuan effort that went into transforming the core IIS platform in IIS7, to deliver on many of the things I mentioned above, you may realize why we were not able to deliver everything at once. But, with IIS7 out, we will have a foundation on top of which we can deliver these things a lot quicker then we ever could before, and I fully intend to take advantage of that.

For a followup conversation, please send me your email address directly via my blog, and we can have this discussion.

Thanks,

Mike

#12 Mike Schinkel on 02.22.07 at 9:38pm

Mike Volodarsky,

Thanks again for the very thoughtful reply.

First, if you interpreted my comments as product bashing, they were not. If anything they were a frustrated plea to get a resolution to critical situation that has IMO gone on far too long.

Addressing your replies:

>> Re #1: We already discussed why IIS7 cannot easily be provided downlevel…

Yeah, I already got that and I completely accepted your answer. I wasn’t pushing on that issue at all.

>> Re #1.1: I dont agree with you in that FastCGI will necessarily have adoption problems.

I think I either overstated my concerns, or you interpreted them different than I meant. I simply meant that it won’t be automatic and there will be a period of time while there is a transition. And that was too bad.

If I had 100 points to apply to my concerns, however, I would apply 3 points to the FastCGI adoption concern and 97 points to the lack of native URL Rewriting in IIS6.

>> Re #2. You have a point there - IIS is missing an industry standard re-writing solution today.

Thank you! I will definitely be doing that later tonight.

-Mike

#13 Lioness on 02.26.07 at 11:48pm

Perhaps off topic, but as said by Roma — ASPnix Web Servers now have ISAPI Rewrite!

#14 Mike Schinkel on 02.27.07 at 12:17am

Lioness: >> Perhaps off topic, but as said by Roma — ASPnix Web Servers now have ISAPI Rewrite!

Awesome, we are making progress!!! (sorry, but I have to ask: why did it take so long…?)

#15 Jake on 09.17.07 at 12:25pm

Seriously, man… Before you make these wild, "I hate Microsoft even though my career was built on their products," take a quick second to do a little research. First, we have the ability to do whatever we need to do with Isapi Extensions. You want extensionless urls? you want urls that are reversed and turned upseide down? fine, write a simple Isapi extension. Microsoft listened to our complaints that filters stunk and moved to simple, managed extensions.

Oh yeah, Helicon - Isapi_ReWrite is the mod_rewrite for windows iis. It works flawlessly, is high performance, and it is FREE for a single site on each server. Want more configuration, its $100/server. Everything can’t be free. In open source, people like you and me actually produce and donate that code to the community. Someone, somewhere, has to make a buck. Microsoft can’t provide everything for free, particularly when someone like Helicon did it first and for a completely reasonable price. Why put them out of business because you think Microsoft should do everything for you?

#16 R. Pitts on 09.08.08 at 11:42am

This is so funny. I am a microsoft web developer and have been developing in microsoft products since the mid-nineties. I posted a comment regarding IIS 7.0 installation and the broken microsoft business model and it essentially complained about the same things as in this article which I am now reading.. guess what .. they did not want to hear it.. other developers also started politely complaining and the response back was name calling then censorship.. the post was deleted.

#17 MikeSchinkel on 09.08.08 at 11:57am

@Jake: You don’t get it. Me writing an ISAPI extension doesn’t give the thousands of websites implemented on ASP.NET access to my extension. My complaints are about the standard supported by the platform, not the esoteric edge cases that I can build for myself if I really go to lots of effort.

I used Isapi_Rewrite for years, and 1.) it wasn’t free when I was using it, and 2.) most web hosts don’t offer it. That latter point makes anything else you can say about it moot. I even offered to help Helicon evangelize to web hosts at one time but didn’t get any interest from them.

As for someone, somewhere making a buck, ask yourself how it is that so many open source companies (Red Hat, MySQL, and many lesser companies) seem to be making more of a buck than Helicon?

BTW, I didn’t ask Helicon to be put out of business; 1.) Microsoft could buy them giving them a lot more money than they’ll ever make selling Isapi_Rewrite, and 2.) I’ve seen many smart companies innovate up the stack when the core vendor added a more simplistic version of their functionality. If Microsoft added basic rewrite functionality it would legitimize the market and Helicon could develop more advanced features and sell a lot more. Or not if they are not savvy.

But none of it matters anymore. Because “Microsoft isn’t doing everything for me” as you said, I’ve moved on to Apache and so have millions of others. This isn’t about me “wanting stuff for free”, this was about me (at the time) pleading for them to address market needs. They didn’t, and I moved on.

So how does me (a former Helicon customer) moving to Apache help Helicon?

@R. Pitts: Yep, Microsoft as an organization really has lot the plot, haven’t they?

Leave a Comment