Windows

Pros and cons of recommending Microsoft-based solutions to IT consulting clients

When building a client solution from the ground up, you'll almost inevitably have to weigh the benefits and drawbacks of whether to go the Microsoft route. Here's what you need to consider about interoperability, security, cost, and several other factors.

 

When clients call on me for help, their constraints usually dictate most of my technology choices -- that's because they're rarely starting from scratch; they have an existing solution that needs to have some new features added to it, or the solution needs to interface to some other service. Based on the time-honored maxim of "if it ain't broke, don't fix it," I would never recommend rewriting an existing solution under those circumstances unless there were no other reasonable paths leading to the desired result.

Occasionally, your client will hand you a slate that's nearly blank and ask you for your best recommendation on building a new solution from the ground up. Among all the other questions that you must consider, one of the first that inevitably arises is "To Microsoft, or not to Microsoft?" More specifically, should you recommend a solution that is based on Microsoft products such as Windows and the .NET Framework, or should you avoid Microsoft products like the plague? Here are several points to consider:

  • The client's existing investment in Microsoft technology. I'm not saying that you shouldn't encourage clients to try new things, but if all of their servers are running Windows, their Web sites are all on IIS, their administrators have never worked on any other platform, and all their programmers are used to .NET, then switching to something else adds cost and risk.
  • Availability of additional developers. If they need to hire new people for the project, they can certainly find developers with Microsoft experience. On the other hand, some of the brightest developers prefer not to work with Microsoft products, while beginner developers often gravitate towards Microsoft in order to increase their marketability. This increases résumé noise when looking for qualified .NET developers, as opposed to other frameworks that attract adherents for less mercenary reasons.
  • Training materials and support. Microsoft products offer paid support, free documentation on MSDN, and a huge online developer community. Open source solutions vary widely in terms of their community support; in some cases, you could be left out to dry if you have a problem. On the other hand, I find that Ruby and Common Lisp developers (among others) often provide better assistance for free than you can get from Microsoft's paid support because the members of these communities feel strongly about promoting the growth of their product's usage.
  • Interoperability. If your client's product will need to integrate with other Microsoft solutions (Office, SharePoint, etc.), then sticking with Microsoft has its advantages. I've written COM interfaces in Microsoft-neutral languages, and it's not pretty. If you do anything with Microsoft, it pays to do things The Microsoft Way. That cuts both ways, though, because it's also a good reason to avoid Microsoft products when you need to integrate with non-Microsoft solutions. Even when employing open standards, Microsoft likes to "enhance" openness in ways that create headaches for everyone else.
  • Ubiquity of Microsoft users. If your client intends to market this product, then they must consider the constraints imposed by their market. Like it or not, Windows still rules the desktop, so writing a desktop application that doesn't target Windows is like opening a restaurant that only serves people with advanced degrees. Even in Web-based applications, you're cutting off a large potential market if you don't bow to compatibility with Internet Explorer, although that can be achieved without using Microsoft solutions for development. Maintaining compatibility with Internet Explorer and other browsers can be a pain in the you-know-what, but if you don't also support Firefox, Safari, and Chrome, you risk alienating a growing group of more savvy Internet users.
  • Key components. The .NET Framework offers components that cover a wide range of needs, and third-party offerings augment those needs. For some specialized components, you may not have a choice between .NET and other alternatives, or the alternatives might be second-class citizens in terms of support and enhancements. You could end up writing more of it yourself, which has its trade-offs: better control over your fate vs. more time spent reinventing the wheel.
  • Security. Microsoft suffers from a bad history of security vulnerabilities that took ages to patch; nevertheless, many consultants see the security of Microsoft products as a relatively known quantity -- that is, something they feel comfortable with because it's "the devil they know." The old adage "no one ever got fired for buying IBM" gets applied to Microsoft these days, especially regarding security: If the client suffers from a vulnerability in Microsoft products, that's just the way the firewall crumbles -- but if it happens in some non-Microsoft component that you recommended, then it's your fault. But if you truly have your client's best interests at heart instead of the interests of your own backside, you can rarely if ever recommend Microsoft on the basis of better security -- if for no other reason than that Microsoft's market share makes the company a big target.
  • Closed source. If something doesn't work the way you expect, you can spend a lot of time with technical support and/or trial and error trying to figure it out because you can't look at the source code. Increasingly, Microsoft has made more of its source code available to developers, but key layers remain hidden from view. If you've ever looked at some of what the company does make public, you'll understand why they're shy -- most of the code is as overgrown as their organization. Open source alternatives tend to be much better written because they're under constant public review and improvement.
  • Cost. Microsoft is almost never the most expensive alternative -- in fact, I still encourage my clients who are software vendors to use Microsoft as a pricing benchmark for their products. However, Microsoft's products are still infinitely more expensive than "free." Microsoft and its proponents argue that Total Cost of Ownership is lower for its products, but I remain unconvinced. While it's true that "there ain't no such thing as a free lunch," I don't think that Microsoft has adequately demonstrated that the price of its products is offset by the supposed extra costs of using something else.

I expect this article to generate some heated comments in the discussion. Many of our readers strongly support Microsoft products, while others are just as strongly repulsed by them. I've tried to present a balanced view here.

While I feel that Microsoft's success is due more to the quality of its marketing than its products, I can't dismiss the company's dominance, and it's a fact of business that consultants have to live with. If you refuse to offer Microsoft-based solutions, then you're severely restricting your niche. But if every problem automatically looks to you like a nail awaiting the Microsoft Hammer(tm), then you're cheating your clients and yourself.

Related TechRepublic resources

Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

50 comments
rayv
rayv

You appear to have the same philosophy and approach to solving clients' problems as I. We always consider all cost aspects of projects, not just the upfront acquisition costs and absolutely include the clients' staff's experience and environment. Good article.

bluscarab
bluscarab

***The clients existing investment in Microsoft technology.*** Why abandon the ship if its still sailing? Just over a decade ago we comitted this crime which eventually led to yet another abandonment - back to an MS based solution. ***On the other hand, some of the brightest developers prefer not to work with Microsoft products,*** Correction:a small percent of the brightest developers prefer not to work with MS products. ***On the other hand, I find that Ruby and Common Lisp developers (among others) often provide better assistance for free than you can get from Microsofts paid support because the members of these communities feel strongly about promoting the growth of their products usage.*** While open-source support is often spirited during the early stages, it often dwindles to a bare existence later on. Ruby's shining moment became apparent in 2007 with the unscalability of Twitter.com. Solution? Abandon Ruby and deploy Scala. What kind of support is that? ***I've written COM interfaces in Microsoft-neutral languages, and its not pretty.*** Thats because you attempted to write them in "neutral" language. Have you ever tried to write an interface in a unix "neutral" language? ***If you do anything with Microsoft, it pays to do things The Microsoft Way.*** If you do anything with Linux, it pays to do things The Linux Way. Disaster awaits for square peg and round hole. ***its also a good reason to avoid Microsoft products when you need to integrate with non-Microsoft solutions.*** What we've found over the last two decades is that in a mixed environment, your best chance for success are with MS solutions. Nothing else comes close to the integration options and services that are available in the MS universe. ***writing a desktop application that doesnt target Windows is like opening a restaurant that only serves people with advanced degrees.*** No. Its like opening a retaurant that only serves the homeless. The opensource app eventually runs out of revenue, steam, and finally, enthusiastic support. ***You could end up writing more of it yourself, which has its trade-offs: better control over your fate vs. more time spent reinventing the wheel.*** Most of us executives learned the hard way that a great business app is not how much control we have over it, but rather, how long can it survive after the writers have left the building. ***Microsoft suffers from a bad history of security vulnerabilities that took ages to patch;*** MS currently has the best record for fastest software & security patching of all the solutions available today. They patch stuff faster than antivirus companies update their engines. The kid with the most practice is the kid who will hit the homeruns. ***most of the code is as overgrown as their organization. Open source alternatives tend to be much better written because they're under constant public review and improvement.*** Acutally, they're under constant pruning which is why any opensource solution has horrendous problems with varying technologies - modern as well as legacy. ***Microsofts products are still infinitely more expensive than free. Microsoft and its proponents argue that Total Cost of Ownership is lower for its products, but I remain unconvinced.*** The amount of firepower we've spent shifting from mandrake to red hat to debian and now finally to ubuntu overshadow the TCO of our migration from DOS to W7 by many orders of magnitude. Opensource - along with unix and OSX - suffers badly from changes in hardware technology. Just a simple upgrade from SPARC to UltraSPARC cost us millions and millions of TCO dollars. Even a simple change in mouse technology - the invention of the scroll wheel - cost us a lot of TCO dollars. In contrast, the TCO of our MS solutions are near zero because the apps that were written for DOS3.0 on a 386 with math co-processor ..... still function today on a core2duo running Windows XP. Zero recoding time = zero TCO. Total Cost of Ownership is not the money spent on the initial software solution. It is the amount of time spent doing unecessary things according to the eyes of the CEO at the helm.

Marty R. Milette
Marty R. Milette

"On the other hand, some of the brightest developers prefer not to work with Microsoft products, while beginner developers often gravitate towards Microsoft in order to increase their marketability." I'd have to suggest that this is an extremely inflammatory and utterly false statement in several respects. Having worked in the offshore outsourcing business on and off for many years -- I've seen absolutely brilliant developers on BOTH the Windows and non-Windows development streams. Just because a developer prefers to work one side or the other is NO REFLECTION of their competence. Maybe they just prefer managing their career by going where the work is? Or maybe it is just a matter of personal taste? There is certainly a NEED for brilliant developers on both sides -- your view that only the newbies and incompetents choose the Windows stream comes off as sounding somewhat arrogant. Like the old "Real programmers use nothing more than a text editor and LOVE it." In fact, I'd say that the truth would be further in the opposite direction. Seems there are a lot more unprofessional hacks developing F/OSS -- more as hobbyists than anything else. You can't eat 'free' or pay your bills with it. On the other side, it seems that those doing Windows development actually expect to be able to make a living doing professional-grade work by getting paid for it - even if they only charge $15 for a piece of shareware.

PMPsicle
PMPsicle

The other side of cost is lifespan. With Microsoft there are two figures necessary. Short story. I used to sell software based on MS products. I quit because every year or two MS would release a new version of their product which obsoleted my work. Effectively, I was spending all my time rewriting base functionality rather than enhancing the way the product performed for the customer. The term legacy only exists in the Wintel world (okay, I exagerate ... but I'm from big iron and we stopped using the term in 1963). So why does this matter? Cost is spread over the use lifecycle. So let's say you have a system which is expected to survive 5 years. Option 1 costs $300 and is good for 5 years. Option 2 costs $100 but has a legacy lifecycle of 1 year. And Option 3 costs $200 and a legacy lifecycle of 3 years. Which is best? Option 1. TLC is $300. For option 2 it is Rndup(5x1/1)x 100 or $500. For option 3 it is Rndup(5x1/3) x $200 or $400. If you had considered only the cost then option 2 would have been the choice. In fact, it was the most expensive option over the long term. This is especially true when you start including the cost of installation. Don't forget the two different life spans or you'll end up making the wrong decision. Glen Ford, PMP http://www.trainingnow.ca http://www.learningcreators.com/blog

brooksgr
brooksgr

There is no "Free" software. If you buy Microsoft, you have a have a fairly good idea of the cost. If you build your own, or use Open Source, both of which we do, it will cost a similar amount or even more.

Realvdude
Realvdude

You definitely succeeded in your balanced presentation.

Sterling chip Camden
Sterling chip Camden

Back when Windows 3.0 came out, I advised my clients to target Windows as a platform ,because I knew it would overtake the market. Many didn't believe me at the time, but they found out otherwise. Now, on the other hand, I'm telling my clients not to put all their eggs in the Microsoft basket -- in five or ten years, that could make them a basket case. What do you think?

biancaluna
biancaluna

Hallelujah, spot on the money, G.

Sterling chip Camden
Sterling chip Camden

Microsoft just makes a good foil and example, because it's so pervasive and divisive.

mjbrichards
mjbrichards

One of the things I think about is what the UI looks like. Because Windows rules the desktop, it's easy to use MS technologies to build something that the client's user community thinks they know how to use, either because it delivers via packages they're familiar with or because it looks like those packages. So implementation and support costs are typically much lower for Windows-based front ends, in my experience. And, if that's the case, then, as you rightly say, it's easier to keep the whole stack in Redmond, for good or ill... The browser makes this a slightly less powerful argument, I know; but I still think it's worth considering

apotheon
apotheon

Correction:a small percent of the brightest developers prefer not to work with MS products. Cite your source, please. You seem to be claiming you have actual statistics. I'd like to see them, and where you got them. While open-source support is often spirited during the early stages, it often dwindles to a bare existence later on. You're kidding -- right? Ruby has been around since 1995, and LISP for more than 50 years. Ruby's shining moment became apparent in 2007 with the unscalability of Twitter.com. Solution? Abandon Ruby and deploy Scala. What kind of support is that? That's not a support matter. That's a "choose the right tool" matter. Do you know what "support" means? Have you ever tried to write an interface in a unix "neutral" language? As someone who has toyed with Synergy/DE (mentioned in the article) myself, I can tell you it is very much both MS-neutral and Unix-neutral. Considering that Mr. Camden is one of the top Synergy/DE people in the world, and should probably be the first guy anyone talks to when a Synergy/DE consultant is needed -- yes, he definitely has "designed an interface in a unix [sic] 'neutral' language". Nothing else comes close to the integration options and services that are available in the MS universe. I can't even begin to fathom how you came to that conclusion. That's beyond bizarre. Do you realize you're talking about the corporation that created its much ballyhooed Active Directory by gluing together a set of open standards, then tweaking them all to make them incompatible with the original open standards? Numerous MS memos have been leaked over the last twenty years or so talking about how important it is to make software incompatible with competing software for the sole purpose of interfering with easy integration. Whatever you're smoking, I want some. The opensource app eventually runs out of revenue, steam, and finally, enthusiastic support. Yeah -- all those open source software projects whose software is older than Microsoft are proof there's no staying power for open source software. Oh, wait . . . that doesn't make sense. us executives Ah . . . that explains why you have no clue what you're talking about. MS currently has the best record for fastest software & security patching of all the solutions available today. Wrong. On what planet do you live? The record for the fastest patch for MS Windows is ten days. The average for some other OSes is under a week. Only Apple is slower, amongst current, major market, general purpose desktop OSes. The kid with the most practice is the kid who will hit the homeruns. So . . . Unix? You do remember that MS Windows has only been around in a usable form since 1993 -- right? Acutally, they're under constant pruning which is why any opensource solution has horrendous problems with varying technologies - modern as well as legacy. What does that even mean? Your sentence doesn't parse in current context. Please rewrite so you appear to be saying something meaningful. The amount of firepower we've spent shifting from mandrake to red hat to debian and now finally to ubuntu overshadow the TCO of our migration from DOS to W7 by many orders of magnitude. Why the heck did you do all that? Opensource - along with unix and OSX - suffers badly from changes in hardware technology. In what way, exactly? Just a simple upgrade from SPARC to UltraSPARC cost us millions and millions of TCO dollars. What the heck does that have to do with open source software? In contrast, the TCO of our MS solutions are near zero because the apps that were written for DOS3.0 on a 386 with math co-processor ..... still function today on a core2duo running Windows XP. I'd like to talk to one of the technical people in your organization and find out what DOS applications you're talking about. Of course, a copy of wc is easy to write such that it's basically future-proof -- but anything nontrivial is another story entirely (and, frankly, I'm happy with the POSIX standard wc anyway). Total Cost of Ownership is not the money spent on the initial software solution. It is the amount of time spent doing unecessary things according to the eyes of the CEO at the helm. Actually, it's the amount of time spent doing things that would be unnecessary if you were using something else -- regardless of what BusinessWeek ad the CEO has been reading about how certain costs are inevitable (even when they aren't) and others are higher with the competition (even when they aren't).

Sterling chip Camden
Sterling chip Camden

"Total Cost of Ownership is not the money spent on the initial software solution. It is the amount of time spent doing unecessary things according to the eyes of the CEO at the helm." Time spent in my career maintaining compatibility with new versions of Windows: thousands of hours. Time spent in my career achieving compatibility with new versions of Unix: less than a hundred.

Neon Samurai
Neon Samurai

sorry.. I thought you where writing a serious (though mis-informed) response up until you made that claim.

apotheon
apotheon

You seem to have overlooked the implications of the word "some" there. Sterling mentioned that his editor removed "(but not all" from the sentence -- but that doesn't change the fact that it still says "some". Please stop trying to assign absolutist claims he didn't make to his statements. He in no way expressed a "view that only the newbies and incompetents choose the Windows stream", and I think your willingness to read things that weren't said into his words -- that, in fact, directly contradict some of what he said -- isn't helping anything. You're just cluttering up the discussion. Like the old "Real programmers use nothing more than a text editor and LOVE it." Actually, real programmers use echo and redirects. Alas, I'm not a real programmer, able to hack it with those grizzly old gurus of yore. You can't eat 'free' or pay your bills with it. That's a poppycock argument, and you should know it.

Sterling chip Camden
Sterling chip Camden

I said "some (but not all)" - my editor removed "(but not all)". I definitely agree that there are some brilliant software developers who embrace Microsoft solutions. But I'll stand by my point that most newbies go straight for Microsoft, and that waters down the overall pool.

Sterling chip Camden
Sterling chip Camden

MS has gotten worse in recent years about obsoleting old code. VB6 anyone? Or how about early C++ managed code? By contrast, I have customers who developed apps with Synergy/DE back in the 70s and 80s -- they can still compile those programs without changes, even though the language has been extended significantly. Synergy/DE isn't free, but software created with it has a lifespan of decades.

Sterling chip Camden
Sterling chip Camden

How does Open Source cost the same or more? Can you support that with numbers?

dayen
dayen

Bill Gates left and I don't like what I see, Windows Genuine Advantage and Office Genuine Advantage being check by a program from microsoft that suppose to be checking for malware but realy looking to see it you have these and if they brake it's wipe the machine, we don't need the downtime. When the Man who builds a company leaves or dies the person or persons who take over may not care about the company only the money in their pocket a fine example is GM.

cpubymike
cpubymike

I pride my self as being a very sensible person. I just answered a question of how to turn Server 2k3 into a proxy. My answer why why tie up a $500 or more dollar server licence, as well as haveing to Get MS ISA server to put on it another 5-6 hundred dollars. use some thing free and open source and you can use it as you wish for as long as you wish or what not. Windows Domain controller ok I'll give ya that one. but paying a thousand dollars or more in licensing and software for a SMB server a proxy or a firewall server. Why anyone would configure a Windows box as a security appliance is beyond me but. You could use something else and diversify and layer your network. Anyway I recommend if you don't absolutely need windows or even if you only need certain aspects WP/Spreadsheets/surfin the net/ Im just use something else for free

apotheon
apotheon

It's easy to use Microsoft and its software to make a point, because in a technical context like TR, everybody knows what it is. As such, it's perfectly natural that it would be used as a common example. Sometimes, picking the rare and obscure example makes less sense because you then have to spend several paragraphs (or chapters) explaining it before it can adequately serve to illustrate a point to readers.

apotheon
apotheon

You're right about the fact that user familiarity can greatly reduce some costs for MS Windows solutions. This is especially the case when you're only in the position of having to deal with that specific part of the overall operating environment, and don't have to deal with other parts of it where costs may be increased by using MS Windows. Aside from discussion of the browser as a bit of a foil, I think Sterling did a great job covering the bases -- and you did a great job of spotlighting an important part of what he said.

Sterling chip Camden
Sterling chip Camden

I never intended this article to be about bashing Microsoft, as some of the other commenters seem to have concluded. There are benefits and costs to using Microsoft solutions, and those must be weighed against each client's needs.

Sterling chip Camden
Sterling chip Camden

Funny you mention wc, a simple Unix utility. Windows never had a tee utility, so I wrote one several years ago. Trying to do things the MS Way, I used managed code. Recently, I needed to make a change to it, and found that it wouldn't even compile on VS 2008! Microsoft had made such radical changes to the syntax for managed C++ code in the interim that a simple utility of about 50 lines of code wouldn't compile without changes to about half of the code! I should have just written it in good old dangerous unmanaged stdio.h C code (which would have been shorter to begin with), rather than drinking the .NET Koolaid.

Marty R. Milette
Marty R. Milette

Considering the MONUMENTAL changes with each major version of Windows -- one should naturally expect a certain amount of rework to update the applications. Let's face it, the vast majority of the codebase in today's UNIX is probably older than the vast majority the coders using it. I suppose there are still a few people out there who are only comfortable using 20-year-old console-based applications to process overnight batch jobs on flat text files...

Sterling chip Camden
Sterling chip Camden

Who needs ASCII? Real programmers deal in machine instructions. Just kidding, of course. We all need our abstractions, we're just comfortable with different levels thereof. Thanks for your defense of my intentions.

Sterling chip Camden
Sterling chip Camden

My editor removed "(but not all)" because it was redundant -- not because it was incorrect.

Marty R. Milette
Marty R. Milette

...it should be obvious which is cheaper -- a license for an existing, working, fully-integrated product or to pay you to re-invent the wheel trying to shoehorn an open source product to 'fit'. How many hours (days or weeks) of your time did it honestly take you to create the COM interface and glue to cobble together that solution? With open source, you get a block of wood for free -- but then have to hire a very expensive carver to actually make something useful out of it.

apotheon
apotheon

When someone hitches his/her horse to a particular wagon, sometimes he/she becomes unwilling to notice that other wagons may be better suited to some tasks. I think the (two?) other people in this discussion who refuse to grasp that there's such a thing as give-and-take between MS options and some of Microsoft's competitors when it comes to competitive advantage to using a given piece of software must be of that breed.

apotheon
apotheon

Hope for the best; plan for the worst.

Sterling chip Camden
Sterling chip Camden

... and I kept it in managed code, for good or ill. I'll probably have to "upgrade" it again in a few years...

apotheon
apotheon

I had forgotten about that tee utility of yours. I don't remember -- did you ever get it working with VS2008? The fact you need to avoid the "latest and greatest" tools from Microsoft in order to write code that will reliably work in a few years is kind of a damning counter-argument.

apotheon
apotheon

although in fairness you can do a lot more from the command prompt/PowerShell now than you used to be able to do. 1. Sadly, cmd.exe and command.exe are just as limited as ever. 2. PowerShell might be great, if it weren't for the limitations of the environment. Two facts substantially hinder the usefulness of PowerShell: 1. Almost nothing in the MS Windows world is designed to interact well with a programmable shell environment. 2. PowerShell itself is very poorly integrated with the OS environment. Many tasks are much easier using cmd.exe and/or command.exe -- and, unfortunately, they're the sorts of tasks that form the building blocks of the sort of more-complex task automation for which PowerShell is supposedly suited. For instance, execution path management is much slicker with cmd.exe and command.exe than with PowerShell. With the old, crappy shells, that works almost as well as with the common Unix-based shells; with the new PowerShell, it's like pulling teeth trying to get it to pick up new execution paths and/or new programs within its execution path. In fact, given PowerShell's limitations, the Ypsilon REPL icon on my MS Windows test system gets a heck of a lot more cliking than the PowerShell icon next to it. By contrast, Ypsilon is less regularly used than any of the other interactive, programmable shells I regularly use on Unix systems (even though Ypsilon is more useful on Unix than on MS Windows, too). The short version is this: MS Windows is not the place to go for custom sysadmin level automation or quick command-line task completion, and even Microsoft's attempts to solve that problem mostly just add more problems to the pile. What good is a more capable shell if it makes the easy things so difficult that something from a third-party vendor is more useful?

apotheon
apotheon

Considering the MONUMENTAL changes with each major version of Windows -- one should naturally expect a certain amount of rework to update the applications. True, but you haven't provided any evidence or argument that this is a good thing. Please provide more information. Let's face it, the vast majority of the codebase in today's UNIX is probably older than the vast majority the coders using it. True, but you haven't provided any evidence or argument that this is a bad thing. Please provide more information. I suppose there are still a few people out there who are only comfortable using 20-year-old console-based applications to process overnight batch jobs on flat text files... True, but you haven't provided any evidence or argument that his is a bad thing. This also ignores the fact that 20 year old console-based applications are the only tools available on non-MS systems that can perform such tasks, or that flat text files are the only available data types, or that clicking buttons and sitting around for three hours waiting for the OS to let you do some additional work again during the day -- because you have to be there in person to monitor what's going on -- is better than letting stuff run overnight when nobody needs to use the computer for anything else, and so on. Please provide more information.

Sterling chip Camden
Sterling chip Camden

Unfortunately, Windows' convergence towards Unix has failed to grasp its key feature: simplicity. Rather than providing simple tools that each Do One Thing Well and can be combined to perform complex tasks, Windows still relies on monolithic GUI-based management tools -- although in fairness you can do a lot more from the command prompt/PowerShell now than you used to be able to do.

Double-G
Double-G

Your responses (this one and previous) indicate a significant bias regarding UNIX/Linux. "...it should be obvious which is cheaper -- a license for an existing, working, fully-integrated product or to pay you to re-invent the wheel trying to shoehorn an open source product to 'fit'." There are OpenSource, or for that matter, non-Microsoft solutions which are ready-for-market and does not need to be "shoe-horned" into shape. and non-Microsoft does not automatically imply OpenSource or free (there is a difference, you know)...... "You can't eat 'free' or pay your bills with it." once again, your inference that if a programmer does not choose Microsoft tools, or that if one chooses OpenSource tools, for development, then he is programming for free. Using OpenSource development tools does not require one's output or product to be OpenSource or free (once again, there is a difference). "Let's face it, the vast majority of the codebase in today's UNIX is probably older than the vast majority the coders using it." Don't you think it is interesting that, although UNIX' codebase (including technology and OS philosophy) is over 30 years old, every new iteration of Windows looks more and more like it, gradually including the major features which continues to make UNIX seem superior (to some people). It may also be apparent that Microsoft also is privately of a similar opinion. "I suppose there are still a few people out there who are only comfortable using 20-year-old console-based applications to process overnight batch jobs on flat text files..." Now at this point, you are clearly showing your ignorance of UNIX and Linux in general, and seem to be spouting off the standard FUD that has been packaged and sold to the "faithful". Even Oracle has GUI tools to manage and manipulate their databases, plus third-party tools. In addition, using UNIX/Linux as a back-end server does not dictate a similar front-end OS. So one can use the "comfort" of Windows at the front end to have access to "all of the GUI tools" for management and data manipulation. Another poster indicated: "Why abandon the ship if its still sailing?" - I think this is precisely one of the points that Chip is trying to make - unnecessarily tying yourself to a single vendor with all of their vendor-specific technologies. Yes, the ship is still sailing, but you may not be able to get off when you choose - nor will you have any warning when the voyage will come to an end. People seem to be constantly making the assumption that non-Microsoft means OpenSource and free. Open source is not necessarily free, and typically, at the corporate level, is not. Similarly, OpenSource application development is not necessarily that one's product will be given away. The main point I took away from the article is that there are costs for each option - based on a number of factors. Some choices may be more costly, but is the preferred path due to other extenuating circumstances - legacy systems, partner/industry requirement, political philosophy, etc. However, one needs to be aware of those issues when making "clean-room" recommendations. G. George

apotheon
apotheon

1. "Fallacy" has two Ls in it. 2. The argument is that "many eyes make all bugs shallow" -- and thus, all else being equal, the software ends up being higher quality. Code reviews have shown a substantially lower bug rate in Linux code than in Windows code, in the ballpark of an order of magnitude fewer. All you've "proven" is that "many eyes" do not make Linux perfect, which was never claimed anyway (by anyone credible, at least).

Marty R. Milette
Marty R. Milette

The 'falacy' about the 'many eyes' making Linux supposedly so much better. You can try to minimalize or rationalize it all you want -- but the fact is that all these millions of eyes over the past 8 years didn't find the problem. Rather typical Linux supporter attitude to ignore any kind of 'inconvenient truth'.

apotheon
apotheon

As Neon pointed out, the key piece of information you seem all too willing to ignore is that the Microsoft bug was a known vulnerability for eight years. Probably half the bugs that are found in any piece of software that uses a continuous codebase over a period of years are bugs that are years old by the time someone discovers them. Everybody who fixes bugs regularly in such software fixes years-old bugs regularly. The difference is that some of them find an eight year old bug and fix it immediately, while others might find an eight year old bug and fix it in eight more years -- and even then, only because outside pressure "forces" them to do so. How exactly do you justify trying to defend that attitude? Just for completeness -- I'm not saying that software that has a discontinuous codebase over a period of years has fewer bugs and vulnerabilities. It's just that, instead of having one bug for eight years, it probably loses bugs pretty quickly as code is replaced, but adds in still more bugs because new code is basically the only way software acquires new bugs. Only changes in development practice can cause new bugs to be added in at a slower rate, and it's usually more advantageous to use a better development practice to eliminate existing bugs while maintaining a largely stable codebase than to just decide to rewrite everything to try to flush out the "old" bugs.

Neon Samurai
Neon Samurai

In the case of the MS eight year bug, it was known and left unpatched for that extended period of time. In the case of the Linux eight year bug, the patch was available with the bug report and major distributions included the new kernel patch within days. I remember watching the discussion on Debian's mailing list one and updating my kernel by 16:00 the next day; and it wasn't even a Tuesday. The point isn't that a bug was found in an OS but that it was known and left unaddressed for such a long period of time.

apotheon
apotheon

My favorite examples of Microsoft's "fast" turn-around time on patches are the eight-year bugs and their ilk. It's always nice to have a critical vulnerability known and ignored for close to a decade.

apotheon
apotheon

I just felt the need to point out that seeking insult, one is sure to find it -- even where it is not intended nor even reasonably inferred by mistake. You're more than welcome.

apotheon
apotheon

there is a big difference to pay a professional to install and configure a Microsoft system where everything is designed to work together -- and having to pay to have someone cobble a bunch of disparate and incompatible applications together into what 'appears' as a single unified system. The biggest difference is the way you use "install and configure" with a positive tone of (authorial) voice in one case, and "cobble" with a negative tone in the other, while referring to "disparate and incompatible applications" as if that's the norm outside of Microsoft's little "vertically integrated stack" bubble. I've built very complex systems of up to 20 servers and half a dozen MS applications in a couple of days (including hardening, SPs, cumulative fixes and updates). Good for you. Do you think nobody has done the same with Unix servers and non-MS applications? I've watched a lot of F/OSS folks try the same in much simpler environments and have seen them take many weeks to achieve a similar result. I've also watched quite a few MCSEs founder similarly. What's your point again? One can buy a lot of licenses for that kind of money. One can also hire competent consultants for that kind of money.

Marty R. Milette
Marty R. Milette

However, there is a big difference to pay a professional to install and configure a Microsoft system where everything is designed to work together -- and having to pay to have someone cobble a bunch of disparate and incompatible applications together into what 'appears' as a single unified system. I've built very complex systems of up to 20 servers and half a dozen MS applications in a couple of days (including hardening, SPs, cumulative fixes and updates). I've watched a lot of F/OSS folks try the same in much simpler environments and have seen them take many weeks to achieve a similar result. One can buy a lot of licenses for that kind of money.

apotheon
apotheon

If a business is deploying Microsoft "solutions" (buzzwords annoy me), and doesn't hire an expert consultant -- or, even more expensively below the macro scale, have one on staff -- it's doing things wrong. Half the reason that Microsoft software has such a crappy reputation for security in the enterprise is that the IT equivalent of a weekend warrior, who knows how to click the OK button with a mouse but doesn't have any clue about the deeper implications of his or her actions, is the norm for Microsoft software "experts". If you don't pay for a real expert up front, just as much with Microsoft software as with anything else, you'll end up paying down the line when the consequences of your oversight come home to roost.

Sterling chip Camden
Sterling chip Camden

These days, I spend far more time "shoe-horning" Microsoft solutions trying to figure out how to get them to work the way the customer wants, because I can't look at Microsoft's sources. I never have those kinds of issues with open source solutions, because if it doesn't work the way the customer wants, I can make it work that way.