451 Research perspectives on OpenStack and Amazon APIs

There’s been an interesting debate on the OpenStack cloud computing project and its API compatibility with Amazon. The discussion and debate over the open source cloud software’s compatibility with cloud leader Amazon’s proprietary APIs was just beginning when the 451 Group released The OpenStack Tipping Point in April. With the advancement of the OpenStack software and community — along with lingering questions about the desired level of compatibility with Amazon’s cloud — the matter is heating up. However, the issue of Amazon cloud compatibility is largely a non-issue.

Enterprise customers are focused on solving their computing and business challenges. They typically center on promptly providing their customers and internal users and divisions with adequate resources and infrastructure; speeding application development and deployment; and avoiding so-called “Shadow IT,” which normally involves use of Amazon’s cloud. Read the full article at LinuxInsider.

I’m not the only one with an opinion around here. My 451 Research colleagues have also weighed in on the matter and 451 Research subscribers can view their argument that Amazon API compatibility may be a fool’s errand.

Google open source license picks and preventions

Google has gotten itself into a little bit of a licensing game again. This time, the company’s open source leader Chris DiBona had to come out and reverse a previous ban of the Mozilla Public License (MPL) from Google Code open source project hosting. The thinking was that MPL represented only a minimal number of projects, so to cut down on license proliferation, Google would just leave that one out. However, it turns out that little license and the limitations Google created were critical to some pretty important open source projects and communities, particularly Eclipse.

DiBona says Eclipse’s petitioning is prompting the software giant to rethink its licensing approach: “We’ve resisted until now as we felt that the features of the Eclipse Public License (EPL) were not unique enough to justify its inclusion. This hasn’t changed, but how we think about licenses is getting a bit more nuanced,” DiBona says. Adding that Google wanted to support Eclipse developers and show solidarity with them, DiBona goes on to say that the May 2008 removal of the MPL from Google Code “seemed a little absurd.”

Google is adjusting and it should be commended for owning up to a goof (which seemed a little strange since it was complaining of possible combinations and interations that skyrocket as the number of licenses grows” at the same time saying community-specific licenses (EPL, MPL, CDDL) “tend to create islands of code.”

However, I’m wondering now about the AGPL, which is viewed as both a risk and an opportunity depending on your perspective. We’ve also seen Google open up recently and contribute code using the Apache Public License (APL), which is now compatible with General Public License (GPL) thanks to GPLv3. Both of those licenses are OK on Google Code, but still AGPL remains prohibited.

License proliferation is a real and significant issue, but for Google to claim its license bias lies purely in a desire to address that issue is somewhat disengenuous. There are other considerations, such as code-sharing requirements, which are extended to SaaS under the AGPL. One of the big strengths of free and open source software is the flexibility and freedom to choose among a variety of options, and licenses are no exception. Rather than explaining why it won’t allow some licenses as anti-proliferation, Google should figure out a way to offer more of the options including EPL, MPL and AGPL.

As the ODF-OOXML world turns

Oh the drama. Most of us knew ISO approval of Microsoft’s OOXML format was not the end, but more of a beginning in the ongoing fight for the future’s file format. Any doubts of that were put to rest this week with a flurry of activity around OOXML’s approval, ODF adoption, Microsoft’s support and the stance of U.S. states and other governments.

Much of it started with Microsoft’s announcement that it would expand its Office 2007 format support, including ODF. The move, which means Office 2007 users will be able to set ODF as their default file format, is further evidence of changes at Microsoft and the need to support multiple formats and interoperability. However, it still drew criticism from a number of ODF proponents/OOXML opponents, whose concerns include the typical Microsoft skepticism, but also center on the software giant’s OOXML approval campaign and previous statements downplaying the market for ODF.

We also saw further objection to ISO’s OOXML approval, primarily an appeal from South Africa. As format expert and saga watcher Andy Updegrove points out here, the appeal centers on the approval process and also on the ‘business basis’ for OOXML’s fast-track approval. Despite that relatively rapid approval, Updegrove points out that, ironically, Microsoft Office users will not have the opportunity to use the file format until Microsoft’s coming Office 14, expected in 2010 at the earliest.

Microsoft credited customer and government demand for its new found ODF love, but we also saw indications it may also involve difficulties in backward compatibility with OOXML. As ZDNet’s Tom Espiner points out, ‘The company now says OOXML support would require substantially more work.’ This comes as no surprise to many open source software users who have come to the same conclusion over the years. In fact, the inability of Microsoft to support different versions of its own Office and format software has fueled many OpenOffice.org downloads over the last few years, including my own.

Still, customer demand as the reasoning behind Microsoft’s ODF support was reinforced by yet another development in the ongoing format saga: findings from the State of New York. While the state’s officials indicated it would be a mistake to name ODF or OOXML as the standard of choice, New York’s format wonks did indicate that openness is the path to the future. That does not necessarily mean ODF, but it certainly makes it more likely given the controversy, uncertainty and drama still surrounding OOXML.

Microsoft’s increased and improved support for ODF is real and it reinforces the idea that Redmond is moving to support open source, open standards and interoperability in response to customers, rather than contentions from critics or requirements from antitrust regulators. Microsoft will certainly continue to work to support and promulgate OOXML and the format has a friend in the broad use of Microsoft’s Office software. However, as OOXML faces continued skepticism, ISO appeals and an EU investigation, ODF (ISO approved in 2006 without controversy) stands ready for use with broad vendor support, growing adoption and, after this week, momentum.