(Please excuse the raw format of this post, it will get updated if I find something
really awful in the next few days).
As no one really wants or
have time to answer (or just pretend),
I thought, well, let’s dig into this huge post.
First, please, Joel darling, I love your writing style and your blog, but stop making
my life that difficult, and put the full length article separately from your blog!
First and foremost, seeing Linux as a huge threat to windows is premature,
I completely agree with that. There’s several points to this I’d like
to ask.
When you hear Linux taking hold of the server market, and even when you listen to
Microsoft fears about linux eating some of the market share they could gain over Unix,
I have a very strong feeling: The figures leading to these worldwide paranoia marketing
campaigns rely on very big customers (i.e. people running a lot of servers).
The figure in the SOHO market, both in terms of shipped units and deployed units,
is still largely in favor of Microsoft, and I’m pretty sure Linux will have
to wait for quite a long time at the door before it can enter this market.
For the desktop, Linux has progressed tremendously, no question asked about that.
But so did Microsoft Windows. Can you replace a windows in a corporate environment
(locked down, no administrative rights, no hardware plugging and unplugging everyday,
etc) by a similarly locked down linux? Yes, absolutely, and it won’t make a
huge difference for the users. The Java Desktop System from Sun is a good example
of what can be achieved.
But now think about the other side of the fence, and the development of applications.
(I’ll dig into that a bit later on, to follow Joel’s progression in his
article). Do you really think that a CRM call center wants to use a web application?
Do you think an administrative wants to complete all his reports and do his charting
on a web application? Exactly my point. Ease of development is the main issue with
a Linux desktop. Is Java bringing anything to the table for that? Well, java sucks
at desktop software (did I get the Slashdot kids angry enough just yet?). To be more
to the point (before someone else points to a counter
example), Java developers sucks at writing desktop applications. Why? They don’t
have the desktop software culture, they have the system application culture.
The whole talk about stability, management, configurability and composability of the
windows platform was absolutely valid. But now there are solutions to
these problems, and pretty good ones with that. Why can’t all these productions
happen anyway? Because they look at the current state of things, and try to imagine
what will happen in five or ten years (time taken for OS/2 to die nearly completely).
If Microsoft just stopped innovating, it would be valid. But what can compete with
Avalon and aero on linux today? Which project has been built to deliver something
in the same time-frame as longhorn? (only acceptable links are for projects that are
not still at version 0.0001 after four years of rewriting of the X server. If you
get me something interesting, I will update this post and its associated logic).
All this to say, if Microsoft is still in the lead, it is because they know to adapt.
It is also because they can adapt their strategy to what the consumer needs. Does
the consumer need compatibility? Absolutely. Which leads me to my next point (and
Joel’s).
Joel says there are two camps at Microsoft, the Raymond Chen Camp that favor
compatibility bug for bug, and the MSDN Camp that doesn’t want
to guarantee anything that is not documented, pushing an API specification as a moral
contract with a developer. Which side am I? Most people responded to that in one way
or another. My answer would be, both! Why would the two be incompatible?
For backward compatibility, Joel talks about VB6 and VB.net. I worked with both technologies,
and can remember very clearly the first pages on the vb web site where object orientation,
full multi threading and the new class library were announced, before the NGWS (that
became the .net framework and CLR, and which were previously COM3) were announced
by Bill Gates. Did Microsoft say at the time that VB.vNext would be incompatible?
Never, and they presented it as an evolution of vb6, not as a break. Did the marketing
suck? Absolutely, we led vb6 developers to think vb.next was just the next enhanced
version, and not a complete change. I would have to agree with Joel when he says that.
Should’ve Microsoft provided a better upgrade path to vb6 users? That’s
a question I would tend to respond by the following: do you want to shape your community,
be its slave, or be in between? With vb.net we are in the “in between”,
a lot of vb weirdness are preserved (late binding anyone?), but a lot of things break
as well. I think that in this case, the msdn camp didn’t win. The camp that
won was the one thinking you had to move over, and recreate something that was not
good enough any more, or would’ve taken significant engineering time to preserve
for an overall bad result. Why would’ve it be difficult to support vb6 out of
the box? VB was very limited, and you often relied (at least I did in the glory days)
on a lot of api calls, libraries wraps, and pure simple hacks to turn the data entry
language into proper efficient code. Would have it been possible to port that to .net?
I highly doubt that any vb hacked multi-threaded application would’ve supported
it (one of the ugliest hack of vb6 was the use of winAPI calls to create threads and
execution of methods with the AdressOf keyword).
Where I start disagreeing with Joel completely, absolutely, vehemently (can you spell
over reacting ?), is when he decry this, IIS6 and WinFX as not an “evolution”
but a “break”. Here, I have to ask… What is broken exactly Joel?
IIS5 was broken, IIS6 supports a new mode, and a compatibility mode for IIS5. Did
they tighten security? Yes. Did they did that and it broke some application? Yes.
Would’ve it been reasonable to provide a compatibility hack so that applications
can be a danger to the overall system and work out of the box? I don’t think
so.
Is WinFX replacing win32? Frankly, doesn’t seem to me like Win32 replaced
win16? COM replaced OLE 1? OLE replaced DDE? They are all evolutions of the others,
and each time they appear as a new technology, in addition to the old one. An example?
Microsoft is building indigo, and still fixing bugs in DCOM. They are fixing DCOM
but they still provide fixes for NetDDE (that no one in their right mind would ever
use ever ever again). They’re building indigo, and they’re hooking it
up with the COM stack to provide a two-way compatibility. They worked on .net and
made sure you could use .net from COM and COM from .net.
Did .net 1.1 break a few things from 1.0? Yes, and that’s why you have a way
to do side by side versioning on these libraries. But did win32 break a few behaviors
from win16? Yes it did, and
no it didn’t matter.
Question to you joel. I made my company buy your software, fogBugz (if you have a
Cubiks company in your records, that’s because of me and only me, and next time
am in the us I expect a dinner for that!). Anyway. If you want to add a new functionality,
like workflow management of a bug, with validation by managers, and integration with
the branching of source control software, are you going to implement that in the current
fogBugz software? As a consumer of your product, I would love that (nothing to pay
for it) but I really don’t expect that to happen. My guess is that you’ll
ship that in the next version. Will you break what has been done for previous versions?
Nope. But you will make sure to add stuff. That’s where I completely
disagree with your analysis. What is important here is that the new apis are added on
top of the current apis. They are not replacing the previous api, nor are
they breaking the previous api. And that’s, once again, exactly why NetDDE
still works even though DCOM have been there for years and Indigo is on the pipeline.
Joel continues by saying that “The old Microsoft, the Microsoft of Raymond Chen,
might have implemented things like Avalon, the new graphics system, as a series of
DLLs that can run on any version of Windows and which could be bundled with applications
that need them.”. There are several reasons why he should know that’s
not true. First, Microsoft like any commercial company needs to generate new revenues, upgrades revenues.
I really hope for the sake of your company that you’re not going to freeze fogbugz
at its current version and offer all the new functionality for free to all of your
users. That would be immediate bankruptcy. Second reason is the scale of the change.
Microsoft will include http.sys (the http kernel driver used by win2003) in windowsxp SP2
for free. That’s right, this new server side technology, you’ll get it
on the desktop for absolutely free, nothing, peanuts. Not a sausage. Indigo will be
available on winXP, win2k3 and Longhorn for free. Nothing. Peanuts. Not
even one sausage. Now if you look at aero, you’re talking about a new
display infrastructure, a new driver model, a fully new subsystem, completely replacing
the previous one, while being completely backward compatible with GDI. If you
ship an update to an OS that replaces 100% of its graphics file system, you can’t
support windows in the same way as you used to, because it will soon become two different
versions of windows.
Joel goes on by argumenting against WinFS as a search technology.
I would just follow Robert’s point number (7), WinFS is first and foremost a
technology for storing data, that relates to other data, adding meta-data to provide
“intelligent” management, not just text search. Text search already works
just fine on windows, thanks to the Indexing
Server and the IFilter interfaces. Here, we’re talking more of other kind
of data, not only text. How can I relate a picture with the people on it, and ask
my operating system “show me pictures of my boyfriend from last year”?
If you try to text index it, you reach a wall you won’t be able to overcome.
WinFS is not there only for text, we already know how to work with text. As you say,
it was not hot anymore I wasn’t born yet.
I would agree with Joel saying that memory management and easy of use of Visual Basic
have been upgrading developers productivity tremendously. Who wouldn’t?
But then, he says “And yet, people aren't really using .NET much.”. Do
you think that’s because of .net itself? Let me tell you a story. I bet my carreer
three years ago on .net. That’s right, for the first c# beta, I said, I will
be in .net and do only .net from now on. The market has been very hard for the first
two years. Where is it now? Companies start seeing .net as something to use because
of its productivity enhancements, but especially because it’s old enough and
no one stood up and screamed “We were ruined because we chose .net”. It
takes time for a new technology to build confidence in the manager paying the check
for a new development project. You do sign checks and you still didn’t sign
anything for .net, you should know. .net starts seeing a huge progress in the
corporate environment, and it’s gradually replacing most of the Java developments
(same trend in the financial services industry for that matter).
The point of .net was to provide a common execution environment, and cross language
interoperability. The .net framework was mainly written to provide c# and vb.net
the same api. Why? Because the vb api was always limited, there was never enough resources
to put in there all the things the vb crowd wanted. Microsoft thought that if you
could combine a big api, you could reduce development cost while increasing functionality.
Yes they did reinvent the wheel. But so did they when they created OLE/COM, or when
they created win32 even though they had win16. It’s just the same story over
and over again.
Avalon is a new API for graphics. True enough. It is still backward compatible with
gdi though. If you write a winforms application now, you’ll be able to write
them in the future. If you write them now, they will still run on longhorn. But frankly,
can we really push GDI any further? No, and that’s frankly for the best. Once
again, I will say, there is absolutely nothing new. GDI+ was implemented on
the win2k OS, and never retrofitted back in windows98 and Me. Ctctrl3d.dll or whatever
the name of the common 3d controls under windows95 was not ported back to windows
3. And yet, a user interface for windows 3 is still working today. An API doesn’t
disappear. The MSDOS subsystem is still in the operating system, protecting your
investment. Yes you will have to learn again, a new technology, and that cost
money and is frightening. But that’s also what makes this industry moving (like
any other one for that matter), and what lets you ship new versions of your software.
Your company, Joel, is the best counter example to your argument. You decided not
to port to .net for cost reason. And you can still ship your software. And it works.
And will in the foreseeable future. Yet you’re alarmed that you’re being
let down. Where are the extensions to the vb4 runtime? There was none, it was added
to the vb5 runtime. Same thing. Again. And again. And again. Oh, and we still have
the sky above us. And I still got a job, and so does your company!
As for Microsoft wanting you to stop upgrading fogBugz, which we bought, even though
we knew about Team System, in common with vault, that I made my company buy too…
I will leave it to Eric to
explain why Microsoft probably doesn’t care much about fogbugz.
When you say that “no developer with a day job has time to keep up with all
the new development tools coming out of redmond”, are you suggesting most of
my blog roll is actually fake professional people? A lot of people find the time to
know in advance what they are going to do. If you want to succeed, you must aim high.
If you aim high, you need to be on top. If you need to be on top, you always find
the time to know beforehand where your industry, where what makes your day job possible
is going. That’s why I have both longhorn and Whidbey installed. And my day
job is a real day job. That’s what makes the difference between my salary and
the one from my “enterprise developers” pals which are still feeling very
sentimentally about vb6 and how cool it was.
And then the discussion slip to supposed “lock in”. There, I don’t
understand. How would the win32 api be more open than the winFX api? How would the
first one be less of a lock in than the second one? If you write code correctly against
.net, you’re actually more open than when writing against win32, as technologies
like mono let you run natively on linux, unix, freebsd, solaris, ibm mainframes, macosx…
So where is the lock in exactly?
WinFX is only for longhorn, and that may be the lock-in: The fact that something new
is only available in the new platform because it’s such a change that backporting
it to old platforms would cost the same thing as providing a new version, which present
both support and marketing advantages (Are you running Windows FX or WindowsXP? Instead
of “Are you running WindowsXP or WindowsXP+Avalon+SP3?). That is not lock in,
that is a new api. Each version of windows, historically has introduced new
APIs, Windows98 SE introduced new APIs compared to Windows98. Did some software rely
on that? Yes. Could they just not use it and keep on doing Windows95 compatible applications? Yes
yes and yes. You have choice, and these technologies continue to be supported.
If you have a bug in one of the win32 apis, and fill a ticket with Microsoft and have
a support contract (like any serious developer team should have), then they will go
down there and investigate, and provide you with a solution or a fix for that api.
It may even get fixed in the next service pack. Is Win32 getting anywhere? No, no
no no no… Not even imaginable. What you may discover though is that, even on
Longhorn, the win32 api has been extended. See this
post for a short example.
And there, I just don’t get it. Joel switch to an over focusing on web applications.
Yes, GMail is sweet. So is Oddpost. I know of a few other web sites which are just
cool as well. But nothing, nothing can replace an efficient rich client application.
Do you think I would read 500 feeds from a web application? No, I’m using newsgator and
outlook. Would I manage the 100 mails I receive a day from a web application? Not
in your wildest deams. Would I do development, picture management, video editing and
sorting (you know, just normal family divx videos, lots of them), from a web application?
No, never ever. The web sucks, it is slow, forces me into waiting in between two pages.
The only good thing about the web is the “liveness” of the data and the
rich formatting. Guess what, Microsoft is providing Indigo for the first one and Avalon
for the second! The web is nice to read web sites, I guess. I’m still not sure
the browser paradigm will keep on living on for years though. People are bored of
the “click, wait, see white screen, load page, click again”.
Then, I don’t understand anymore. Joel informs us that it’s over, the
web have won. My experience might be slightly different, but I see lots of windows
applications being written. I don’t see CRM call centers being web based in
the near future. There is space for both technologies, one that REACH users
whatever their computer or browser is, and one that is RICH and empowers users
to work faster and better. Don’t tell me you manage everything from a web site?
Why the hell would you have a computer then? Why didn’t web tablets succeed
back in the late 90s… Why did Be die?
(ok, I really needed to play drama queen and sound really nervous in there, Joel does
say “I love my rich client applications and would go nuts if I had to use web
versions of the applications I use daily”, but I can’t really start a
big argument if I agree with him , or if he agrees with me, can I?)
Development positions… Yes, low level people are paid more because there are
very few of them. Who knows what happens if you marshal a MBR object across appDomains?
Not many people. How the remoting sinks work? Not many either. Do those that knows
get paid better? Yeap (except for me obviously lol). That’s just a simple matter
of a minority of developers interested in how it works rather than what
does it let me do. This was true in the COM days. It was even true in the VB6
days.
Do most people refuse to move back from their web development position? I don’t
think they refuse. They are waiting for the right technology that will let them have
the same level of freedom than they have on the web. That’s why Microsoft says,
all in all, that the very rich client is back. It’s cool, easy to use,
and so rich that I don’t have to bother with a web site anymore, unless I want
to reach. It will take years to do the conversion, but if the technology is
cool enough, it will get users moving, which in turn will get devs moving, etc…
As always, enterprise applications will be the last to move, in 10 to 15 years!
Could HTML have won? It would have with a richer model than the pull one, if standards
for manipulating the dom and its events appeared back when the browser war was hot,
and if the w3c didn’t turn into that huge unable to achieve monster that, these
days, only shines when standardizing or clarifying what was done by others (shame
to say that, considering how much I supported the w3c all these years).
HTML didn’t win. It’s one of the less bad technologies available, but
everybody working on it feels frustrated. Microsoft is betting on providing enough
candies for you not to get frustrated anymore. And in my opinion, it is going to work.
Would I bet my career on it now? No. .net is just the right migration path. Future
will tell (and hopefully prove Microsoft and me right).
So, Joel… Where did you invite me for dinner already?
SerialSeb