Is Open Source Ready for Prime Time?

Well that's an obvious question. And you'd be surprised if you were expecting Microsoft to say no to it. :) Fact is, Microsoft has learned / adapted to embrace and support open source communities and models.

I had the opportunity to speak at the UCLA Anderson School of Management's IS Associates event, titled "Is Open Source Ready for Prime Time".

SlideShare | View | Upload your own

 

My esteemed fellow speakers included Dan Frye (VP Open Systems Development, IBM), Robert Kabat (Senior Counsel, Twentieth Century Fox), and Howard Wright (IT Strategist, Stradling Globl Source; formal head of IT at Dreamworks). Our discussions were moderated by Maryfran Johnson (Editorial Director of Executive Programs, CXO Media; former Editor in Chief of Computerworld).

Some people at the event had anticipated that Microsoft would be very vocal against open source. But in general, all of the speakers, including myself, were in agreement that many open source software products have gained sufficient maturity to meet many enterprise needs.

Microsoft's Perspective on Open Source

So what exactly is Microsoft's perspective on open source? Basically, the IT environment today is a mix of open-source and private source software (or proprietary commercial software), and Microsoft recognizes that it needs to be an active participant in that environment, in order to continue to provide value to customers.

Slide7

Microsoft does this via a number of efforts:

  • Partnerships with open source software vendors - such as SugarCRM, JBoss, Xen Source, MqSQL, Novell, Zend, Mozilla, etc. For example, Microsoft's engineering teams worked closely with the FireFox team to make sure FireFox will run well on Windows. Similarly, ensuring platform compatibility and interoperability with many open source software products
  • Engaging communities - participating in community events, open source conferences, forums and alliances such as the Open Source Interoperability Initiative, Open Source ISV Forum, Interoperability Forum, Interoperability Vendor Alliance, etc.
  • Code contributions - including technology open sourced by Microsoft through the Shared Source initiative, or developed through sponsorship or community project partnerships
  • Support for research efforts - relationships and collaborative projects with the academic research community in computer science, sociology, and economics

Essentially, Microsoft is now leveraging open source development models and approaches, and supporting open source business models. By embracing diverse application development and business models, Microsoft seeks to participate successfully and responsibly in a world of choice in which individuals and organizations can pursue their goals based on what uniquely inspires them, including open source.

However, as a software company, Microsoft does compete with open source software products (i.e., Linux, Open Office, MySQL, FireFox, Java, Apache, PHP, etc.). But this does not represent a conflict of interest. Microsoft focuses on supporting the people working on and with open source.

And many open source software products today do present significant challenges to Microsoft's competing products. So does that spell the end of Microsoft, now that conceivably free software that are "good enough" are available? Well, not really. But they do force Microsoft to innovate and add value. In fact I think open source from this perspective is actually a good influence on Microsoft; it requires us to work harder and try to do what's right for customers.

Take for example, Microsoft Office. Does Open Office or other conceivably free applications like Google Apps mean that Microsoft should open source Microsoft Office as well?

Slide26

Microsoft's response is two-fold.

First from a product suite perspective, Office today is no longer just a bag of desktop clients used to create documents. Office 2007 is a bona fide user collaboration and business productivity platform that integrates high-fidelity client components on the desktop, free and subscription-based services in the cloud, enterprise servers, and mobile devices. It provides sophisticated capabilities, and a range of choices in terms of how users want to leverage the capabilities. It's not a one-size-fits all solution compared to the current open source and freeware counterparts.

Second, from a development perspective, the entire suite of Office products consists of multiple project teams. Microsoft's vision for the user collaboration and business productivity platform requires a closely managed and well-orchestrated effort across these teams. And the question is, is it more effective to make it open source so that the community can contribute to its future development, or to continue leveraging Microsoft's closely knit full-time development resources? In Microsoft's opinion, keeping Office private still makes more sense.

And of course, this gives Microsoft the ability to continue using traditional licensing means to generate revenue from Office. But I think Office does offer great value to customers at commodity-level pricing points.

Users' Perspective on Open Source

Granted, Microsoft is not a major user of open source software products, even though it actively participates in the open source communities. Thus for everyday users of software products, the perspective on open source software is different from Microsoft's. Ultimately, the best way to look at open source software products, is that they are software products just like proprietary commercial software products.

Slide21

In general, neither open source software or private source software, is inherently or naturally better than the other. Advantages claimed on one side for some products, can also be claimed as advantages for some products on the other side. Same holds true for disadvantages.

For example, concerns for product support has been cited as the biggest challenge for open source software products, as it is unclear who owns accountability and support responsibilities when no one owns the software (the community owns it). However, that doesn't mean products like Linux has inferior support. Customers can get support from established vendors like Red Hat that leverages the support services model.

For the most part, trade-offs are quite unclear between both sides. As benefits claimed by one side are not always true. For example, one will say "zero cost", and the other will say "lower long-term cost", or "good enough" vs. "cheap enough", etc. The list goes on, but none of these claims are consistently true.

Slide22

Thus for users evaluating to adopt open source software products, the decision should be made based on specific requirements, and evaluated against a list of options which may include both open source and private source software products. The evaluation process should focus on value, which can be a combination of short-term acquisition/deployment costs, long-term ongoing support and maintenance costs, and sometimes hard-to-quantify benefits and costs like productivity gains/costs.

Slide23

Some Final Thoughts

Having said the above, there are still some inherent differences between open source and private source software. One major difference is how these software products are developed. In general, open source software products are created by mostly highly technical people, whereas private source commercial software products often are combined multi-disciplinary efforts that include, for example, marketers, analysts, researchers, usability experts, creative designers, user experience experts, mangers, architects, engineers, etc. Consequently, we can see that the most successful open source projects today are products (true community-driven projects; not vendor products that do open source) that address technical and infrastructure issues. But this is not necessarily good or bad; just different. And the likelihood is higher that open source projects and development processes will continue to mature, and may at some point integrate additional types of communities to collaboratively create products.

How does one measure the viability of an open source software product, when evaluating financial viability of vendors (as a business partner)? There is no good answer for that question today, but the best way to look at that is to look at the size and activeness of the community around a project. The larger and more active the community, the more viable the project is from a long-term perspective. For example, one study indicated that over 2,000 developers contributed to one year's worth of changes into the Linux kernel (just the kernel!), which is one indication on the likelihood that this project will not be abandoned anytime soon.

And not all software projects should be moved to open source models. Some projects are very well-suited to leverage open-source development, but some would benefit more remaining private. Again, there are differences between truly community-driven open source projects like the Linux kernel, and vendor-driven products like Eclipse and MySQL that do open source. But in general, we do find that technical products have a higher likelihood of building a strong community to maintain the product from a long-term perspective. Thus there is still plenty of room for proprietary/commercial software vendors like Microsoft and IBM to innovate and add value. For example, IBM is building on top of open source products, and Microsoft is focusing on user experience and innovative capabilities.

Licensing in open source products, such as LGPL, GPL v3 and the ongoing debates around that, and the proliferation of different flavors of open source licenses, are still sources of confusion for users. For example, who is responsible to provide indemnity from a legal perspective? Our recommendation is, end-users of open source software products don't really have to worry about this, including developers who build applications using open source software. However, if open source software components are embedded and/or distributed as another commercial product, then the organization needs to engage its legal counsel to identify legal risks and map out mitigation requirements.