Ohloh to be renamed Black Duck Open Hub

Here at OSS Watch we’re big fans – and users – of Ohloh, the site that helps you analyze open source software repositories, for example when evaluating the sustainability of projects.

Since Black Duck bought the site back in 2010 there haven’t been any obvious changes.

Until now that is:

Dear Ohloh user, 

 

We would like you to be the first to know of an exciting update to Ohloh.net. This week, Ohloh will be changing its name to the Black Duck Open Hub.

Since 2010, we have supported the Ohloh community, now consisting of over 250,000 users, with a stream of new features and functions – all to remain freely available. The name change to Black Duck Open Hub reflects an increasing commitment on our part to the developer community, as well as anyone who wants to learn about the world of open source.

So, goodbye Ohloh, hello Black Duck Open Hub!

I have to admit it doesn’t exactly roll off the tongue that easily, and I’m not looking forward to correcting all the mentions of it in various OSS Watch publications either, but hey, things move on!

Open Source Phones at MWC

Mobile World Congress is running this week in Barcelona.  While it’s predicable that we’ve seen lots of Android phones, including the big unveiling of the Galaxy S5 from Samsung, I’ve found it interesting to see the coverage of the other devices powered by open source technologies.

Mozilla announced their plans for a smartphone that could retail for as little as $25. It’s based on a new system-on-chip platform that integrates a 1GHz processor, 1GB of RAM and 2GB of flash memory, and will of course be running the open source Firefox OS.  It’s very much an entry level smartphone, but the $25 price point gives real weight to Mozilla’s ambition to target the “next billion” web users in developing countries.

Ubuntu Touch is finally seeing the light of day on 2 phones, one from Chinese manufacturer Meizu and one from Spanish manufacturer Bq.  Both phones are currently sold running Android, but will ship with Ubuntu later this year.  The phones’ internals have high-end performance in mind, with the Meizu sporting an 8-core processor and 2GB of RAM, clearly chosen to deliver Ubuntu’s fabled “convergence story”.

There’s been rumours abound this year that Nokia have been planning to release an Android smartphone, and they confirmed the rumours were true at MWC, sort of.  “Nokia X” will be a fork of Android with its own app store (as well as third-party ones) and a custom interface that borrows elements from Nokia’s Asha platform and Windows Phone.  Questions were raised at the rumour mill over whether Microsoft’s takeover of Nokia’s smartphone business would prevent an Android-based Nokia being possible.  However, Microsoft’s vice-president for operating systems Joe Belfiore said “Whatever they do, we’re very supportive of them,” while Nokia’s Stephen Elop maintains that the Windows-based Lumia range is still their primary smartphone product.

A slightly more left-field offering comes in the shape of Samsung’s Gear 2 “smartwatch” running Tizen, the apparently-not-dead-after-all successor to Maemo, Meego, LiMo, and all those other Linux-based mobile operating systems that never quite made it.  The device is designed to link up to the Samsung Galaxy range of Android phones, but with the dropping of “Galaxy” from the Gear’s branding, perhaps we’ll be seeing a new brand of Tizen powered smartphones from Samsung in the future.

Leveling the playing field for open source in education and public sector

Last week I presented at ALT-C in Nottingham on the topic of open source in education and the public sector.

This was partly to invite people to participate in Open Source Options for Education, and partly to open up discussions around software procurement policies and processes in the sector.

The discussion tended to confirm our survey findings that the practice of procurement including open source options varies a lot within institutions, resulting in different biases (both for and against FOSS). So the degree to which FOSS is considered for procurement in education can be quite different depending on who you’re dealing with. To get a more balanced approach to closed and open source software would therefore require engagement with all of the different groups engaged in software procurement to develop their understanding and practices.

Here’s the slides:



BBC creates HTML5 TV appliance

The BBC R&D labs have recently been busy working on a TV prototyping appliance called the egBox. The idea behind it is to create a minimum viable product of a HTML5-based TV as the base platform for experimenting with new features.

The appliance uses HTML 5, the WebM video codec, runs services using Node.js, and is being used as the basis for various technology experiments at the BBC. The  set of components used by the egBox is one that many developers will be familiar with – node, redis, socket.io, backbone.js – on top of which the developers are working on areas such as TV authentication.

What is interesting is that, while the idea is to create a minimum viable TV product as the basis of other prototypes, the nature of the egBox stack suggests lots of interesting ways to extend it. For example, as it uses Node.js, you might make use of the Webinos platform to offer apps.

At the time of writing the egBox code is not open source; however, that is the eventual plan.

The usual sticking point for any foray into TV using open source is actually working with TV services themselves. The “Smart TV” space not only has a whole raft of competing and conflicting standards, but most of the consortia operate on a paid membership basis, some even requiring signing NDAs to read the documentation; this is something I covered in a post a few years ago.

Things have improved since then, but there is still a long way to go. Ironically, a W3C standard for encrypted media content might actually be a good thing – or at least, a less-bad-thing – for open source TV, as W3C standards are royalty-free and publicly available unlike many of the specifications developed within the TV industry.

The upshot is that any open source project looking to work with a good range of TV services is likely to have to pony up some membership fees, and potentially keep some important parts of the codebase closed source to avoid issues with partners and consortia.

Still, its going to be interesting to see whats possible with the egBox.

You can find out more on the egBox over at the BBC’s R&D blog.

How “open source” is the Minnowboard?

This week, Intel announced the Minnowboard, a small embedded development board akin to the RaspberryPi, BeagleBoard and similar devices. The point that grabbed my attention is that it’s being touted as an “open source computer”. The device is shipped running Ångström and is compatible with the Yocto project for building custom embedded Linux systems, but while there are many devices available that run Linux, the term “open source computer” is seldom bandied about. So just how “open source” is the Minnowboard?

The minnowboard viewed from above, with labelled external interfaces

The Minnowboard from above

For a start, the board uses Intel chips, which is usually a good sign that the drivers required will be open source, without requiring any binary blobs in the Linux kernel. Furthermore, the UEFI system is open source. This is the code which executes when the computer first powers up and launches the operating system’s boot loader, and making this open source allows hackers to write their own pre-OS applications and utilities for the Intel platform, an opportunity we don’t often see on consumer devices.

Update: Scott Garman’s comment below clarifies the situation regarding graphics drivers and initialisation code.  A proprietary driver is required for hardware accelerated graphics.

However, moving away from the software, there’s a clear message that the Minnowboard is meant to be “open source hardware”. There are of course competing definitions from groups like OHANDA and OSHWA as to what qualifies as “open hardware” and “open source hardware” – one we heard at Open Source Junction included that all components should be available from multiple sources which is never going to be the case here – but a reasonable metric in this case would be, “is one free to modify the design and make a similar device?”.

The language on the site certainly seems to suggest that this is the intention. The Minnowboard Design Goals page clearly states:

Our goal was to create a customizable developer board that uses Intel® Architecture and can be easily replicated. It is a simple board layout that lends itself to customization. The hardware design is open. We used open source software as much as possible. We used standard (not cutting edge) components that are in stock and affordable, to keep the cost down.

Also, the introductory video explicitly says that the technical documentation will be available under Creative Commons licenses allowing people to modify the designs without signing an NDA.
That said, this documentation isn’t currently on the website, the only reference is a notice saying that “By August 2013 we will post all board documentation, software releases, links to Google Group forums, where to buy, and information of interest to the community.” We’ll just have to be patient.

Update: The schematics, design files and bill of materials are now available on the Technical Features page of the Minnowboard website.

Minnowboard with a type-C lure expansion template attached.

There are 3 formats for “lure” expansion boards – the Type C template here shows the smallest.

Another vector to openness for the Minnowboard is the opportunity to create daughter boards dubbed lures. These are akin to Arudino shields and allow additional components to be plugged in to the main board to expand its capabilities. There’s already several designs taking shape, and there’s certainly the potential for a community to arise around creation of these lures.

What Intel have produced is an open platform with standard components and interfaces for prototyping and developing embedded systems. Unlike the RaspberryPi which is designed as a learning device, the Minnowboard’s design (once released) could represent a starting point for both hobbyist projects and commercial products, without any royalties to be paid to its original designers (except, of course, that you’ll need to buy your chips from Intel). From Intel’s point of view, this is clearly a move to gain traction in the ARM-dominated market of embedded systems. As far as calling it an “open source computer” goes, once the designs are published, I think they’ll have done a pretty good job to justify the term.

Images from Minnowboard Wiki users Jayneil and Prpplague, used under CC-BY-SA.

Running open source virtual machines… on Microsoft Windows Azure? Welcome to the VM Depot

Last week I gave a talk on open source as part of a Microsoft Azure for Education day at UCL in London. I was sharing the stage with Stephen Lamb from Microsoft, who gave a great overview of the various open source projects that Microsoft are engaged in, including Node.js and PHP for Windows. But the main highlight was VM Depot.

cloud

VM Depot is a way to upload, share, and deploy virtual machine images on Microsoft’s Windows Azure cloud platform. For example, you can easily find common open source packages such as Drupal and WordPress on various Linux operating systems available as VMs, so that you can create and run your own instances.

This makes it very easy to get started with open source packages, as all the dependencies and related components and configuration are all set up and ready to use – for many packages this means just doing your customisation for things like your own web domain and personalising the user interface.

As well as the usual suspects such as Drupal, the VM Depot can host all kinds of other software; for example, you can deploy the Open Data portal platform CKAN. This opens up possibilities for using the service for more niche requirements, for example you could create a VM image of your research software and dataset to make it easier for reviewers to run your experiments. Or you can modify an existing image to include extensions and enhancements that may target a more specialist audience, for example you could create a WordPress image with templates and add-ons to run as an overlay journal rather than a regular blog.

So why is Microsoft doing this?

Well, it seems to fit as part of the drive towards Microsoft being less of a software company and more of a device manufacturer and cloud services provider. When it comes to offering  cloud services, its less important what your customers choose to run on them, so much as making sure they can run whatever they need. For most organisations that usually means a mixture of closed source and open source packages; by offering the VM Depot, Microsoft can serve these customers as part of an existing relationship, rather than force them to go with other service providers for running open source products.

Microsoft have certainly come a long way since the infamous “cancer” remark.

For more on Microsoft and Open Source, check out Microsoft Open Technologies.

Is MariaDB replacing MySQL?

Over the past month there has been a steady trickle of announcements from organisations switching from MySQL to MariaDB.

Seal vs Dolphin!

From next month, MariaDB will replace MySQL as the default database in Fedora.  And now RedHat has announced its doing the same. Even Wikimedia started using it.

So what is MariaDB, why is the switch happening, and what are the implications?

MariaDB is a fork of MySQL intended to be, as much as possible, a drop-in replacement for MySQL in most cases. It has pretty much the same features, with some extras and claims performance improvements over the original.

However, I don’t think its really the pros and cons of the technology that matters so much as the backstory.

MySQL was acquired by Sun Microsystems in 2009. However, one of the original developers of MySQL, ‘Monty’ Widenius, was unhappy with the way things were working out at Sun, and left to start his own company, and his own fork of MySQL, MariaDB. The later acquisition of Sun by Oracle was also viewed negatively by Widenius, who issued a call to arms to “save MySQL”.

However, Widenius wasn’t the only one concerned about the future of MySQL, and other forks appeared such as the Facebook MySQL fork and Drizzle.

When comparing MariaDB and MySQL, we’re comparing cultures of development as well as feature sets.

Oracle is perceived – rightly or wrongly – as having a conflict of interest as the owners of MySQL and also suppliers of its major closed-source competitor, leading people to suspect that the company is being slow to develop the database further.

It is also seen as being less open in its development process, and losing the trust of the community. For example, where Oracle have added major new capabilities to MySQL, these are often closed-source extensions. Oracle also stopped using a public bug tracker and instead switched to it internal system. These moves – and others – are cited as examples of Oracle moving away from the open development model that made MySQL successful in the first place.

However, is MariaDB, any more “open” than Oracle?

MariaDB is managed by the MariaDb Foundation, and has been developing its community governance model. The board of MariaDB includes some well-known figures from the Open Source world including Simon Phipps of the Open Source Initiative, and Andrew Katz of Moorcrofts; in April, Phipps was elected as the MariaDB Foundation CEO. On the commercial side, MariaDB service providers include Monty Program, the company founded by Widenius, and SkySQL, founded by other former MySQL employees.

This separation in governance between service providers and the development community counters the perception of “conflict of interest” found with Oracle and MySQL, and also means that the Foundation can implement policies and practices that support openness and transparency in the running of the project.

Is openness and transparency reason enough to switch?

One of the claims made by MariaDB is that it applies community patches and implements new features much more rapidly than Oracle. If MariaDB is iterating faster than MySQL, fixing bugs and implementing new technologies, without sacrificing stability and quality, then this is a key product differentiator.

So for some, switching to MariaDb may mean they are more comfortable with the governance and management of the community. For others, it’s the benefits that stem from that openness that will drive them to switch.

(It’s difficult to determine which is the prime motivator, as even where companies switch out of a concern over Oracle’s stewardship of MySQL they are more likely to couch this in terms of the technical advantages of MariaDB rather than blatantly come out and say it.)

What this story also shows is how the strategic use of forking – the “nuclear option” of open source – can be a viable strategy once a project becomes perceived by its community as going down the wrong path. And probably a better option than waiting until the company discontinues the product, and then attempting to resurrect it.

Will MariaDB replace MySQL in the long run? Widenius certainly thinks so. However, as Daniel Bartholemew points out, “the competition between MariaDB and MySQL can only be good.”

And whatever happens at least we won’t need to stop using the acronym LAMP.

Are you looking to switch to MariaDB? If so, why? Let us know in the comments.

Photo by by bnorwood used under a CC-BY Creative Commons License

Shallow versus Deep Differentiation: Do we need more copyleft in the cloud?

In a previous post I discussed two different models for open source services; the “secret source” model, which is based on providing a differentiated offering on top of an open source stack, and a copyleft model using licenses that address the “ASP loophole” such as AGPL.

Another way of looking at these two models is in terms of the level and characteristics of differentiation that they afford.

Shallow versus Deep

Sea and clouds

If a service offering – and this applied whether its a SaaS solution or infrastructure virtualization or anything in between – uses a copyleft license such as AGPL, then this tends to encourage shallow differentiation. By this I mean that the service offered to users by different providers is differentiated in a way that does not involve significant changes to the core codebase. For example, service providers may differentiate on price points, service packages, location, and reputation, while offering the same solution.

There can also be differentiation at the technology level including custom configurations, styling and so on, or added features; however under an AGPL-style license these are also typically distributed under AGPL, so if service providers do want to extend and enhance the codebase, this is contributed back to the community. If a provider really did want to provide deep differentiation, it would effectively have to create a fork.

If a service offering instead builds on top of an open source stack using a permissive license such as the Apache license, then it becomes possible for providers to offer deep differentiation in the services they provide; they are at liberty to make significant changes to the software without contributing this back to the community developing the core codebase. This is because, under the terms of most open source licenses, providing an online service using software is not considered “distribution” of the software.

What does this all mean?

For service providers this presents something of a quandary. On the one hand, a common software base represents a significant cost saving as development effort is pooled, reducing waste. On the other, there is a clear business case for greater differentiation to compete as the market becomes more crowded.

How this is resolved is something of a philosophical question.

It may be that, acting out of self-interest, service providers will over time balance out the issues of differentiation and pooled development regardless of any kind of licensing constraint; the cost savings and reduced risk offered by pooling development effort for the core codebase will be clear and significant, and providers will apply deep differentiation only where there is very clear benefit in doing so, while contributing back to the core codebase for everything else.

Alternatively, service providers may rush to differentiate deeply from the outset, leaving the core codebase starved of resources while each provider focusses on their own enhancements. In this scenario, copyleft licensing would be needed to sustain a critical mass of contributions to the core.

Which is it to be?

Given that OpenStack and Apache CloudStack, two of the main cloud infrastructure-as-a-service projects, are both licensed under the Apache license, we can observe over the coming year or two which seems to be the likely scenario. Under the first model, we should see the developer community and contributions for these projects continue to grow, irrespective of how deeply providers differentiate services based on the software.

Under the second scenario, we should see something rather different, in that the viability of the project should suffer even as the number of providers building services on them grows.

As of now, both projects seem to be growing in terms of contributors; here’s OpenStack (source: Ohloh):

OpenStack contributors per month; rising from 50 in 2011 to 250 in 2013

… and here is CloudStack (source: Ohloh):

CloudStack contributors per month; around 25 over 2011-2012, rising steeply to 60 in 2013

(Both projects have slightly lower numbers of commits, though that can simply reflect greater maturity of codebases rather than reduced viability, which is why I’ve focussed on the number of contributors)

If the concerns over “deep differentiation” turn out to be justified, then community engagement in these two projects should suffer as effort is diverted into differentiated offerings built on them, rather than channelled into contributions back to the core projects.

Is deep differentiation really an issue for cloud?

Deep and shallow differentiation is a concept borrowed from marketing, and is sometimes used to refer to how easy it is for a competitor to copy a service offering. One example of this is the Domino’s Pizza “hot in 30 minutes or its free” service promise – it would be difficult for a competitor to copy this offering without actually changing the nature of its operation to match – it can’t just copy the tagline without risking giving away free pizza and going out of business.

In cloud services, its arguable how much differentiation will be in terms of software functionalities and capabilities, and how much on the operational and marketing aspects of the services: things like pricing, reliability, support, speed, ease of use, ease of payment and so on.

If the key to success in cloud is in amongst the latter, then it really doesn’t matter that most providers use basically the same software, and providers will want to take advantage of having a common, high quality software platform with pooled development costs.

A further problem with deep differentiation in the software stack is that this could impact portability and interoperability – having extra features is great, but cloud customers also value the ability to choose providers and to switch when they need to. Providers focussing on a few popular open source cloud offerings are another kind of standardisation, complementing interoperability standards such as OVF, and one that gives customers confidence that they aren’t being locked in; as well as being able to move to another provider, they also get the option to in-source the solution if they so wish.

Are there better reasons for copyleft?

It remains to be seen whether there really is a problem with the open cloud, and whether copyleft is an answer. Personally I’m not convinced there is.

However, that doesn’t mean copyleft on services isn’t important; on the contrary I think that licenses such as AGPL offer organisations a useful option when looking to make their services open.

Recent examples such as EdX highlight that AGPL is a viable alternative for licensing software that runs services, and that perhaps with greater awareness among service providers we may see more usage of it in future. For example, for the public sector it may offer an appropriate approach for making government shared services open source.

(Sea and cloud photo by Michiel Jelijs licensed under CC-BY 2.0)

MOOC provider EdX goes open source – with an interesting choice of licence

Earlier this month EdX, the nonprofit organisation set up by MIT and Harvard to provide a MOOC platform, released part of its code under an open source licence – the Affero GPL.

MOOCs – “Massive Online Open Courses” – have been hitting the headlines frequently in 2013, with high profile proponents and some big name backers. (For a good overview of the subject, I’d recommend reading MOOCs and Open Education: Implications for Higher Education, a white paper published by CETIS.)

The meaning of “Open” in MOOCs has been variously argued; however the prevailing model is one of open access to higher education, but not necessarily provided using an open platform.

The earliest MOOCs, and those operated by individuals or collectives rather than companies, have tended to operate using combinations of free of charge – though not necessarily open – services such as those offered by Google, WordPress, and Twitter, coordinated using open source course management platforms such as Moodle.

However, most of the high-profile commercially-oriented MOOCs have operated a bespoke online service based on either proprietary software, or solutions built using open source software but not necessarily available for others to replicate due to the so-called privacy loophole; that is, the modifications made to the software to deliver the service are not themselves required to be distributed to users.

The EdX announcement is interesting for two reasons – firstly that they are the first high profile MOOC provider to release open source – and secondly that they are doing so under the AGPL, one of a small number of open source licenses that specifically address the “privacy loophole”. This means that if you create your own MOOC service using EdX’s XBlock software, you must make the source code for the service – include your modifications – available to download under the AGPL. This is a form of “service provider copyleft” that ensures that EdX will have access to any improvements on their platform used by third parties.

This can be seen as a very cautious move – using the AGPL will ensure no other services can improve on the codebase without EdX getting access. However its also quite a bold one as it makes a clear distinction between how EdX sees “open” in contrast with Coursera, Udacity and others. (It remains to be seen what direction the UK’s FutureLearn initiative will take). It will also be interesting to see if other components of EdX will be released, and if so whether they will also use AGPL.

For more information on how online services use open source licenses, see How Can Services Be Open Source? 

The EdX XBlock code is available on Github.

O̶p̶e̶n̶ ̶S̶o̶u̶r̶c̶e̶ Software Policies

If you make decisions regarding software procurement in your institution or business, I’d highly recommend you read this article from Opensource.com. In it, Gunnar Hellekson of Red Hat shows that an “open source software policy” can be easily re-written to apply to all software, in a lot of cases by simple removing the phrase “open source”.

There’s always been a lot of FUD surrounding open source software, often produced by the marketing teams of its competitors. Taking the USA’s IRS open source policy as an example, Hellekson, rather than trying to debunk or gloss over the potential risks associated with adopting open source, shows that these risks apply to proprietary software in exactly the same way.

I’ll just take one of his examples from the document mentioned above:

Open source software, while it can be useful in many instances and appear to be cost effective, may present a security risk because open source developers don’t typically follow security best practices when developing their software.

It’s laughable to think that this should be exclusive to open source software. Assuming that it’s true the open source developers don’t typically follow the best security practices (Hellekson argues it’s not, as would I), the licence applied to a piece of software make no difference to the security practice of its developers.

If your developer isn’t security conscious, the fact that no-one outside the company can read the source code isn’t going to change that. When procuring any software, you should always be prepared to mitigate the risk that the software’s not secure.

I was going to finish this post by giving the UK Government’s open source guidelines the same treatment that Hellekson gave to the IRS’s, but it would be unwarranted. Reading though the guidelines, they serve to educate the reader that open source and proprietary software should be treated as one and the same when assessing systems. A flaky open source system shouldn’t be chosen over a robust and secure proprietary system, nor should a robust and secure proprietary system be chosen over a robust and secure open source system purely on the basis of the licence.

While it’s easy to see that the proprietary or open source licence applied to a solution shouldn’t affect whether or not you choose it, at OSS Watch we know it can be hard to assess open source solutions on a level playing field with proprietary ones. Proprietary software is often presented as a single package for you to assess, while an open source solution may consist of several parts from different commercial and community sources. If you’d like help assessing software solutions in an unbiased way, send us an email to info@oss-watch.ac.uk.