Development environments: Microsoft vs. Open Source

Development environments: Microsoft vs. Open Source

Summary: In a previous discussion of OpenOffice versus Microsoft Office most respondents addressing the development issue seemed to prefer the Microsoft development tools over the comparable open source ones. I believe this is probably correct from the individual developer perspective, but wrong from the corporate perspective.

A few weeks ago we had a fascinating discussion here comparing the functionality available with the Staroffice/OpenOffice open source cluster to that available with Microsoft's Office set. The general conclusion, I thought, was that the two sets of technologies are roughly equivalent on office functionality but Microsoft wins easily in terms of development integration and related tools.

Today I'd like to start expanding that discussion into two related areas: one focused on risk, the other on developed application functionality.

Since I believe in the adversarial advocacy route to truth used in the judicial system, I'm going to take the position first that the applications delivery ideas underlying the architecture in use determine both the limits of its toolsets and the extent of the risk you accept by using them; and second, that risks are higher, and the limitations more constraining, for Microsoft's client-server than for the Unix/Smart display approach - where the latter is assumed to rely as much as possible on open source applications and development tools.

In today's opening round on this I want to challenge readers who use Microsoft's development tools in an Office or general business applications context to contest the following statement:

Anything you can do with Microsoft servers, clients, Office, and technologies I can do better [i.e. at some combination of greater functionality, lower risk, and lower cost] using the standard LAMP/SAMP toolset with emphasis on OpenOffice and the Apache cluster.

I see are three key differences between the two sets of technologies:

  1. the [LS]AMP technologies, particularly Cocoon, centralize processing, impose no client distinctions, and ultimately require storage of no more than one copy of the original data, document, or other material being worked with;

  2. the [LS]AMP technologies are open source and rely on open standards and technologies; and,

  3. the [LS]AMP technologies heavily front-load the learning curve: once you know how to properly use one to do anything, everything else you can do with it becomes relatively easy.

    (In fact Apache Cocoon's documentation turns strong men pale - coming to it from a Wintel BASIC background has to be a lot like getting off the couch for a trip to the fridge only to suddenly find yourself stranded naked on an iceberg and forced to scavenge for fish among hungry penguins. A sample, from the "welcoming" page for the Maven development block:

    The purpose of the block preparation goal is making a block runnable as web application and enabling rapid application development. It uses the Jakarta Commons JCI library which provides a reloading classloader. As the names already promises, it is able to watch resources (e.g. .class files) for changes. In such a case the classloader will use the latest version of the resources in the future.Some Java servlet containers already provide the automatic reload of loaded servlet contexts in the case of changes but this comes with the downside that you might lose the application state and that you are not allowed to change the signatures of classes and methods.

    By no coincidence the Cocoon technologies are both the most powerful and the hardest to learn - but on the plus side the stuff works in depth, and people coming to it from a Unix C/Java background typically have no problems seeing the values and ideas behind the jargon.

In the context of Office and general business applications the advantages offered by the open source approach should be obvious.

At the top of that list is risk reduction.

On the most superficial level: no client storage or processing means no client security exposure. Compare the risks of giving people access to confidential data on Sun Rays versus Wintel laptops, and the difference is obvious.

Go one step further: to secure document management, and every Wintel method both requires coercion and is subject to ifs, buts, and maybes - while doing it with Cocoon is straight forward enough that no photo of anyone's screen is going to make the front page of the New York Times simply because the photo itself can tell you who did it.

More interestingly, a key risk many companies forget about involves long term information access - all of the Microsoft proprietary formats, particularly those involving encryption, are subject to arbitrary change and therefore loss. I don't know a single long term Windows user who hasn't lost personal documents to Windows upgrades - and I know quite a few companies which have lost full or partial access to information - particularly with respect to formats, icons, signatures, and read/write time and change authorization records - due to third party, mostly Microsoft, initiated change entirely outside their control.

Open standards minimize those kinds of risks of loss -and most directly avoid such common remedial costs as those of loading, reformatting, and re-saving documents originally formatted with previous Word, Excel, or PowerPoint generations.

At the top of the risk actualization tree is the branch everyone developing and using Wintel applications falls off: millions of companies built for NT, rebuilt for 2000, revised for 2003/XP, now face rebuilds for the 2008 Server/Vista combination -and can look forward to throwing away any successes they achieve in this process just as soon as Microsoft gets whatever they want to sell next out the door.

In contrast, applications I worked on using Unix 4Gls like Accel with Unify 4.0 in the late 1980s have generally proven automatically upgradable to new technologies and most could be taken off those 60MB NCR and SunOS tapes, loaded on Solaris with PostGresSQL, automatically converted to Java, to run with no manual editing needed - and if you want anything you write using PHP/MySQL and Apache today to be usable ten years from now, all you need to do is stick to standards while squirelling away a copy of the source for everything involved - just in case.

Near the bottom of that list is hardware adaptability. Cocoon, in particular among Apache technologies, is an almost perfect application set for demonstrating the power of Sun's CMT/SMP technologies - and would take less work than most to adapt to IBM's cell processors.

Wintel, in contrast, is hamstrung by the lack of software adaptability to anything outside the x86 franchise - people porting Windows applications to Windows 2003 for Itanium have not, for example, much enjoyed the process or done much more than self-consciously defensive preening about the great successes obtained by trading down from cheap Xeons to multi-million dollar Itanics.

In between are other issues, many of which I hope to get to in the weeks ahead, and all of which seem, at least at first glance, to favor corporate investment in open source people over paying for proprietary licensing. Next Thursday, for example, I hope to explore the cost of training and retaining staff for both environments - but, until then, the bottom line is in the challenge - and for those of you want to prove me wrong, here it is again:

Anything you can do with Microsoft servers, clients, Office, and technologies I can do better [i.e. at some combination of greater functionality, lower risk, and lower cost] using the standard LAMP/SAMP toolset with emphasis on OpenOffice and the Apache cluster.


A footnote: Microsoft's direct-X has nothing to do with X - and along that same line there's a Microsoft Cocoon project which appears to be just another government/Microsoft health care information exchange boondogle whose naming Microsoft seized on to confuse the market.

Ironically, however, it may actually be predicated on use of the open source Apache Cocoon software.

The project's "technology infrastructure" page consists entirely of a diagram with the word "Cocoon" in small vertical print on the XML piece and this cogent explanation:

The most important element on which COCOON will be based is its Infrastructure. Several technologies are involved into it because it will be the most important part of the project. On top of services offered by this Infrastructure, it will be built all the knowledge related services, collecting information from already existing peers, nodes, which are the real knowledge repositories, which integration is the COCOON target. The figure below gives the vision of how Smart Search Engines, K.M. Services, and Multi-channel delivery are connected to the Infrastructure and knowledge repositories.

So I don't know what they're doing (besides getting paid) - but if I wanted to do this kind of thing for real, I'd certainly use Cocoon to do it.

Topics: Open Source, Emerging Tech, Microsoft

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • A little simple reasoning

    ... is enough to reveal what's going on. Let's try.

    Quote: "Anything you can do with Microsoft servers, clients, Office, and technologies I can do better [i.e. at some combination of greater functionality, lower risk, and lower cost] using the standard LAMP/SAMP toolset with emphasis on OpenOffice and the Apache cluster."

    Let's assume the above is true. Now with LAMP solution stack being totally free while M$ tools carrying a non-trivial price tag, LAMP should have easily blown M$ dev tools away in the IT industry, right? The reality shows that's not happening, so the assumption must be false.

    See, that simple. It doesn't take rocket science to figure out. But then I can tell you don't have much development experience, it therefore is understandable you wrote a frankly laughable article thinking LAMP has a game against M$ development strength.
    • Psssst.....

      LAMP did blow MS away in its industry. What do you think 40% of the internet is using as an application stack. And that is only counting PHP. That doesn't count the other P alternatives in the stack like Ruby, Python and PERL. .Net is used mainly on intranets where duty is light and business execs make decisions on marketing rather than actual cost and merit.

      Your post is the only thing thats laughable.
      • Got any links?

        Show me.
        • Sure

 - the A in LAMP is and has been the dominant web server since 1996.

          I can't find the original market share articles at the moment but this one mirrors the same statistics.

          If I can find the other articles I will post those as well. But it doesn't take rocket science to see the number of major sites on a LAMP variation vs the number of major sites on MS. And once the sites get smaller the FOSS technologies get even more dominant. A HUGE chunk of message board, blog and CMS installations are PHP based. Its really not that hard to see.
          • Isn't netcraft

            the one routinely dismissed as proof of IE domination? If so, it's not good support for your assertion.
            No, it doesn't take rocket science, it takes real numbers to prove your assertion.
          • Everybody in the industry uses Netcraft stats

            Where do you people come from anyway?
          • I thought . . . .

            I thought the discussion was supposed to revolve around DEVELOPMENT TOOLS? You develop FOR Apache not WITH Apache!!So leave LAMP out of it, unless you just want to talk about the P.

            So basically should only be comparing PYTHON to VISUAL STUDIO.

            Give me Pascal.
          • re: Isn't netcraft

            [i]the one routinely dismissed as proof of IE domination? [/i]

            Netcraft doesn't track browsers.

            none none
          • No it isn't...

            I haven't seen anyone complain about netcraft regarding IE. I'm not even sure if they have browser stastics on that site. The mainly measure serves their OS, web server and uptime. If anything the netcraft numbers have been skewed in favor of MS by MS making deals with companies to spoof their servers. You can read about it on the netcraft site as the explanation for some Linux servers reporting IIS as the web server. There was also the great domain parking switch by go daddy.

            Sorry man but don't ask the question if you can't handle the answer.
          • i've got no problem with the answer

            if i was wrong about how reliable it is. Do you know what site tracks the browsers?
          • It was net applications I was thinking of

            not netcraft.
          • Yep thats the one....

            I don't bother with browser tracking but I do believe IE is most likely still dominant. It would only make sense since you have to actually download FF.
      • 40%!!! LOL, typical OSS propaganda

        What's the percentage of the entire world population still ride on bicycles compared with those have their own automobiles? I guess you are gonna tell us Toyota, Honda, Mercedes and so on are blown away by those bicycles. Thanx for the laugh.
  • RE: Development environments: Microsoft vs. Open Source

    I've been working with computers since 6th grade (1979), my first computer classes were in BASIC and PASCAL at Duke University "DUCK" camp during the summers of '79 and '80.

    Although I have high hopes for the open source community, and have seen some very good programs come out of it, open source DEVELOPMENT tools have a long, long way to go before they can match the flexibility and ease of use of "closed source" development suites.

    You start with the discussion of whether Microsoft or Open Source OFFICE PROGRAMABILITY is better and then throw LAMP/SAMP into the mix?

    You're mixing office application programmability with web application programmability. If I am writing an application leveraging Microsoft Office that is NOT web based, I can perform 99% - 100% of the development within the office environment without relying on another shell to provide functionality, quickly and easily.

    Documentation is clear, and there are so many resources to assist. VBA is easy to use, easy to learn, easy to understand, and easy to document and modify. JAVA? C?

    Why does it seem that "easy to learn", "easy to use", and "clearly and effectively documented" seem to be anathema to the majority of open source?

    I've made some half hearted attempts to duplicate Microsoft Access Applications using Open Office Base, and found the application, development tools and the documentation are woefully inadequate to the task.

    If you want to bring full blown application development tools into the mix, then Visual Studio, and the free "express" editions blow the few open source and freeware tools I've seen so far out of the water it's not even funny (when comparing documentation and ease of use).

    Maybe I was spoiled by the first programming language manuals I used, where each keyword included a full description of the function as well as programming examples using the keyword.
    • Nicely done - thanks

      I think you've stated the case for MS here very well - but there is rather more to it.

      For example, it's pretty obvious that Access is way better than the matching open office component - but I'd argue that most of the things Access typically gets used for dig the corporate hole deeper and should be thought about a little more before people commit to them - i.e. that the right open source answer to Access development is usually some other class of toolset entirely.

      Remember, I'm not talking here about what you do in the privacy of your own home, I'm talking about committing employer dollars in a risk and compliance intensive environment - and in that context what can be done with Access is better done with a scalable RDBM and something as objectively pathetic as PHP.

      As to the learning barrier: you're quite right - but once you do learn, the productivity barrier goes away and you can do the right thing in no more time than it usually takes the other guy to do the wrong thing.
      • Hmmm,

        "As to the learning barrier: you're quite right - but once you do learn, the productivity barrier goes away and you can do the right thing..."

        Well, you could learn to use wood plane instead of that nice, easy to use electric router. And I am certain doing so is gratifying to anyone wanting to learn how to use a wood plane expertly. But in the end, the router is faster, easier, and does not have the learning curve.
        • A perfect example

          A plane is not a router - admittedly a power router is easier to use than a manual woodplane, but since the tools are not equivelent - and a router is not appropriate where a plane is - I think you've illustrated the usage problem very nicely.

          • </substitute>Bosch 3365 Power Planer</end Sub> nt

            OutsideThe Box
    • The funny think about Visual Studio... that when my MS friends come to me drooling over new features in VS I laugh and pop open Eclipse or NetBeans and show them where the feature was already there either directly or through a plugin.

      At one point it was so bad that I was completely lost as to what Intellisense was when I first started with Studio 2005 I believe it was. These same developers kept going on and on about how wonderful it was and I kept waiting for it to pop up and do something for me. One day one of them was at my desk and my code completeion popped up and he said yea isn't IntelliSense nice....and I burst out laughing. I had BEEN using this in Eclipse, JDevloper and JBuilder knew it simply as code completion. The MS crowd had just got it and since a lot of them have never touched anything non MS they thought it was some new invention.

      Now my latest version of Oracle SQL developer has code completion and I'm willing to bet Toad has it to while SQL Management Studio 05 doesn't. Now I bet when MS adds this feature to the next version MS fans will drool again thinking this is the only place you can get this remarkably "new" feature. lmao
      • As it happens...

        Visual Basic had intellisense in '96.

        Visual Studio 97 extended it to C++.

        And Visual Studio .Net has always had it.

        Which IDE had it first, I don't know or care, but that doesn't excuse you talking bollocks.