Forgot your password?
typodupeerror

How Open Source Has Influenced Windows Server 2008 145

Posted by ScuttleMonkey
from the everyone-learning-from-everyone-else dept.
willdavid writes to tell us that Sam Ramji over at Port25 has a nice succinct list of the major open source principles that have been used while developing Windows Server 2008. "Overall, we've learned and continue to learn from open source development principles. These are making their way into the mindset, development practices, and ultimately into the products we bring to market. I've focused here on 'what Microsoft has learned from Open Source' - and ironically, I've agreed to do a panel at OSBC on 3/25 with Jim Zemlin of the Linux Foundation on 'what Open Source can learn from Microsoft'. As all of the different organizations in IT continue to evolve, we'll learn from each others' best practices and make increasingly better software. As in science, this incremental improvement will move all of us forward."
This discussion has been archived. No new comments can be posted.

How Open Source Has Influenced Windows Server 2008

Comments Filter:
  • by morgan_greywolf (835522) on Friday February 29, 2008 @02:33PM (#22602886) Homepage Journal
    Oh, look! It's Sam Ramji, showing he knows nothing about open source principles.

    Modular architectures
    You can find these wherever you see participation at scale - and often a rearchitecture to a more modular system precedes expanded participation. Great examples of this are Firefox, OpenOffice, and X11 - from both the historical rearchitecture and the increased participation that resulted. The Apache HTTP server and APR are good examples that have been modular for as long as I can recall.
    OpenOffice? Modular? Maybe OOo is developed in a modular way, but the end result is hardly anything but modular. In fact, it's quite monolithic -- when you start OpenOffice Writer, you also start OpenOffice Calc, Base, Draw, Impress, etc.

    Programming language agnostic
    A given project uses a consistent language, but there are no rules on what languages are in scope or out of scope. Being open to more languages means opportunity to attract more developers - the diversity of PHP/Perl/Python/Java has been a core driver in the success of a number of projects including Linux.
    Open source projects are 'programming language agnostic' because they used public, published and open interfaces. They follow standards. The reason a the Linux kernel build process can be a mixture of bash, Python, Perl, awk, etc. is that all of these things can connect together using pipes and whatnot. The reason you can write GNOME applications in almost any programming language is that the APIs are completely open. The reason why AbiWord and KWord can read Open Document Text files is that that spec is completely open and free of royalties, patents, etc.

    Feedback-driven development
    The "power user" as product manager is a powerful shift in how to build and tune software - and this class of users includes developers who are not committing code back, but instead submitting CRs and defects - resulting in a product that better fits its end users.
    Huh? How are CRs the same as accepting code patches? Open Source development differs in that these "power users" as he calls them can make their own changes and, if necessary, fork off their project to offer a competing or even a completely different project.

    Built-for-purpose systems
    frequently seen in applications of Linux, the ability to build a system that has just what is needed to fulfill its role and nothing else (think of highly customizable distributions like Gentoo or BusyBox, as well as fully custom deployments).
    Uhhhh....BusyBox is not a "distribution" and cannot really be compared to Gentoo except that, yes, the program (as in single program, hence, not a distribution) is cutomizable through the use of custom build options.

    Sysadmins who write code
    ability of a skilled system administrator to write the "last mile" code means that they can make a technology work in their particular environment efficiently and often provide good feedback to developers. This is so fundamental to Unix and Linux environments that most sysadmins are competent programmers.
    Unix sysadmins are generally NOT competent programmers. We're lazy schmucks who whip up quick-and-dirty scripts to accomplish tedious and boring tasks out of sheer laziness. And then we call it 'enhancing productivity' in an attempt to get a raise. :)

    Standards-based communication
    Whether the standard is something from the IETF or W3C, or simply the implementation code itself, where these are used projects are more successful (think of Asterisk and IAX2) and attract a larger ecosystem of software around them.
    Real open standards are developed by the community at large through agreement, not by a monopoly who can change the "standard" at anytime without notice.
  • by Anonymous Coward on Friday February 29, 2008 @02:35PM (#22602918)
    Hmm interesting...

    If you just say it's great you can get more of the market.

    If you say you innovate people believe you.

    If you name your product close to the more popular true standard you can confuse the PHBs into paying you money instead.

    If the competition is winning tell everyone your competitor is unfair to competition.

    If people like a bad practice, and it's yours, then keep doing it.

    There more money in prolonging the problem then just putting out a solution.

    If you can convince a big bux company to buy your product it is a good vehicle for the advertising/PR department.

    No mater how much you neglect your customers' previous purchases, privacy and security, you can still keep them buying your products.
  • by 140Mandak262Jamuna (970587) on Friday February 29, 2008 @02:48PM (#22603058) Journal
    What the article lists as "lessons to be learned from Open Source" is what is usually taught in Software Engineering 101. Come on, Modular Architecture, language agnostic coding, follow standards... This is the lesson from Open Source? These are basic things that every software manager should know.

    The problem with MSFT is not that they don't know these things. They do. But the internal power structure in MSFT is so driven by "if the playing field is level, we will lose" cowards. So they still do things that was ok when they held a 20% share against Word Perfect and 10% (by revenue) share against unix and mainframe giants, back in the late 80 and early 90s. They got lots of money and grew too fat and have too many layers of management. So they go and hire this dogbert to tell them what they already know.

  • by kmike (31752) on Friday February 29, 2008 @03:54PM (#22604122)
    Their goal isn't to copy F/LOSS or the principles of open source movement,but to influence the general public (or at least those pointy-haired guys in charge) so it will associate MS products with Open Source and openness in general. This rhetoric does just that, nothing more, nothing less.

    The recent "opening" of some of MS protocols and specifications blends well into this PR strategy.
  • by HermMunster (972336) on Friday February 29, 2008 @03:58PM (#22604198)
    Bottom line is that the OSS model will surpass the closed source model in time. It has no choice but to do that. Open cooperative community development has no choice but to meet and exceed that of the closed source model due primarily in that it is very evolutionary. The OSS industry will update faster (bug fixes and new features) than the closed source with the typical 18 month to 5 year product cycle of the closed source. Given time the OSS industry will create more useful features and modify those features over and over long before equivalent features will be available in the closed source market. It is like an organism that evolves more rapidly vs an organism that evolves in huge spurts with larger time intervals in-between. The organism with the shorter evolutionary steps has a greater possibility of finding flaws, correcting them, and creating new features and testing those.

    Open source by its very nature will overcome monolithic development cycles of closed source, given enough time. Closed source doesn't have the time and can't experiment much. Open source has all the time in the world.

    Let's also keep in mind that 1) Microsoft is a finite entity with limited number of developers and thus a limited number of ideas, where only so many of those limited ideas will pay off (this is why they steal everyone else's ideas). 2) The Open Source community has the resources of the community as it exists "world-wide" and thus has a significantly greater chance of coming up with new and unique ideas. 3) Some ideas are just obvious and that is why you see duplicity of ideas in each platform. These ideas tho can be extended and modified faster due to Open Source's ability to have more minds looking at the product and submitting coding ideas.

    If any of you read the blogs of the ex-Microsofties that left just prior to or just after the Vista release you can see clearly that each developer in the Microsoft community is a microbe that has limited access to the brain and does what they are told even if the process is to redo and undo and redo the same thing again and again. This is certain to result in significant slow downs and even failures (as we have seen with Vista).

    The Open Source model will succeed because it is designed to succeed whereas closed source practices dictated by a criminal monopolist to developers using their platform tools, etc., will result in systemic failure and their ultimate demise. How long will it take? It doesn't matter because the open source community has the time and the manpower.

Today's scientific question is: What in the world is electricity? And where does it go after it leaves the toaster? -- Dave Barry, "What is Electricity?"

Working...