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.

Overlooked Open Source Tools for Libraries

This guest post has been contributed by Nicole C. Engard, author of Practical Open Source Software for Libraries.

I’ve been teaching and researching open source software for what seems like ages, so sometimes I forget that other librarians don’t necessarily know about all of the great open source tools I do. There are a few must have applications for every library (and a few more specialized tools) that I’d like to share with you all.

Continue reading

OSS Watch releases Open Source Options for Education

We’ve written several times recently about the UK Cabinet Office’s Open Source Procurement Toolkit, and the Open Source Options document that forms part of it.

The original document lists open source alternatives for common proprietary solutions that might be used in government and public sector organisations.  The types of software solutions listed are mostly generic packages such as operating systems and office productivity suites that would be of use to most organisations.  While it contains some software for specialist areas, the document is designed to be broad so doesn’t go into the detailed needs of each area.

With OSS Watch’s focus on open source within education, we’ve produced a document entitled Open Source Options for Education to complement the cabinet office’s which focuses solely on open source alternatives to proprietary solutions used in educational establishments.

Working with the educational community and with the communities around many of the featured projects, we have compiled a list covering various areas of administration and content production that are specific to education, as well as tools that may be used for teaching specific subjects.  Where possible, we’ve included real-world examples of their usage.

As the document has the same goals as the cabinet office’s, the guidance we wrote on making use of theirs applies here too.

While some of the tools we’ve included may be generic packages that are included as such in the cabinet office’s document, we’ve looked at them specifically in the context of their application to an educational situation, such as using an office package to author e-books.

OSS Watch would like to thank all of those who contributed to this first version of this document.  If you feel that you have a contribution to add, be it an open source alternative to a common piece of proprietary educational software, or an example of one of those pieces of software listed being used in an educational context, you can add your contribution on the publicly editable version of the document, or get in touch with us directly.

Bad API design: 3 deadly sins

Building APIs into your software, especially when they’re exposed as a web service, is a fantastic way to broaden engagement with your open source software project. APIs allow people to extend and integrate with your software without having to touch your core codebase, which is good for maintainability and for uptake.

Moodle is a fantastic example of this.  As well as providing a wealth of internal APIs for writing plug-ins, it exposes functionality via web services which has allowed the community to develop mobile apps which use Moodle’s data and features without requiring special hooks in the core code.

When designing an API, it’s important that you do so in a way that people will be able to use it easily. PHP aficionado Lorna Jane Mitchell‘s been gathering examples of how not to do it, and has identified 3 deadly sins of API design, to steer you in the right direction:

  1. Using incorrect error codes.
    Many APIs exposed through web services use a convention called Representational State Transfer, or REST.  The idea of REST is to use HTTP as your API’s protocol, keeping your overheads to a minimum. HTTP already has a well defined vocabulary of methods and return codes, so doesn’t need extra data being sent back and forth to provide this information.  If you’re going to write an API that uses REST, don’t return a 200 code (OK) and then send back an error message in the response’s body.  There’s an error code to cover pretty much any eventuality, so make use of them.  This allows developers to write code that identifies the type of error and handles it appropriately.
  2. Being Inconsistent.
    Developers want an easy life.  When they call your API, they want to be able to predict what will happen.  Follow consistent conventions in your vocabulary (especially regarding singular and plural nouns), and don’t change the type of data returned depending on the result of the query.
  3. Documenting Poorly.
    This applies throughout your project, but especially for external APIs as these will be the first point of call for someone looking at integrating or extending your software.  Expecting people to read through your code to work out how to use your API isn’t going to win you any friends or contributors.  Worse than this is letting your documentation be incomplete, incorrect or out of date, leaving people to find the mistakes and work around them by trial-and-error.

Ring ring ring ring ring ring ring, Ubuntu Phone

Yesterday evening Canonical posted a much-hyped “virtual keynote” (video of Mark Shuttleworth) announcing Ubuntu for phones. This heralds a new open source phone OS entering the scene, and I’d like to take a look at some of the points from the 20 minute video that I found interesting, as well as how it’s been received by the wider technology community.

The first thing that interests me about Ubuntu for phones is that it’s build on an Android base. Rather than trying to reinvent the wheel, Canonical built on the work that the Android Open Source Project has already done to support mobile hardware on Linux. For Canonical, this means a lot less development for them to worry about. For users and manufacturers, it means a phone that can run a vanilla open source Android ROM (such as Google’s Nexus phones) can also run Ubuntu.

Despite this, it will not run Android apps, or as TechCrunch pejoratively put it: “Android apps can’t even run on the Ubuntu Phone OS”. This makes sense to me, however.

Ubuntu’s offering to developers is twofold: firstly, first-class citizenship for web apps using the Unity Web API that landed in Ubuntu 12.10 – the same code used to integrate with the Unity desktop will allow apps to integrate with the phone’s interface (it’s not clear if this is also called “Unity”). Secondly, native apps written in QML are supported, a great framework for building interfaces with the Qt toolkit (again, Canonical aren’t reinventing the wheel, which is good). As such, the business of the apps will be written in C++ (with OpenGL supported for graphical flair), and Javascript for interface “glue”.

Adding a Java/Dalvik VM to support Android apps would be a big drain on resources, and as Mark Shuttleworth said recently, would cause more problems than it solves for the Ubuntu ecosystem.

In the video, Mark also mentions your Ubuntu Phone being your PC. Whether this means a blown up version of the touch UI when attached to a screen and keyboard, or a full-blown desktop environment a la Ubuntu for Android isn’t clear. It’s quite a compelling feature though, especially for businesses, who would have less devices to manage and be able to do so through Canonical’s Landscape product.

Towards the end of the video, Mark mentions that “a few lucky members of community have had early private access” to some parts of the system. Presumably this is the first of the “Skunkworks” projects that Mark announced recently on his blog, where Canonical are bringing in contributors from the community to projects that would otherwise be completely behind closed doors. Hopefully we’ll hear more about the work these community members have been doing in due course.

I could go on about this, but I’ll leave it there for now. I’m sure we’ll be discussing Ubuntu for Phones at length on the next series of the Ubuntu UK Podcast. If you’ve got any thoughts you’d like to share, leave them in the comments below!

e-Book authoring platform Pressbooks going open source

Pressbooks, a popular platform for creating and distributing e-books, have announced they will be making the code for their platform open source. Pressbooks builds on top of the open-source blogging platform WordPress. If done right, this could be very good news for the education sector, which has shown keen interest in e-books recently.

Tablet and Print Books side by side. Image by remiforall @ flickr

e-Books have been one of the big topics in education this year, with the California “open source textbooks” initiative, the launch of Apple’s iBooks, and the popularity of e-book readers such as Kindle and Nook  - not to mention the rise of tablets such as the iPad as e-book readers. Earlier this year a preview of Preparing for Effective Adoption and Use of eBooks in Education by James Clay was released which is well worth taking a look at.

Pressbooks builds on WordPress to deliver a web-based authoring and production environment for e-books including visual editing, as well as distribution on popular platforms such as  Kindle, Nook and Apple iBooks.

The open source announcement was made fairly quietly in a presentation by Pressbooks founder Hugh McGuire in a talk last month.

There are already other open source e-book editors available such as Sigil and BookType; BookType and Pressbooks share a lot of features in common – both are web based with distribution and collaboration features, and support the same range of e-Book formats – so it will be interesting to see how they compare when both are available as open source.

According to Pressbooks, the platform will be made open source in Q1 2013; however they are already reaching out to development partners for early access to the code. For more information, visit pressbooks.com.

 

Image credit: remiforall, CC-BY

 

Are you SaaSing me?

In the final of my trio of posts deconstructing the “cloud”, I’m going to be looking at Software-as-a-Service, or SaaS. SaaS is the next layer of the “cloud” stack that sits atop Platform-as-a-Service (PaaS) (when it’s been built using such a platform), and/or Infrastructure-as-a-Service (IaaS).

Software-as-a-Service is usually presented to the user as a web application. It is distinct from a standalone web application in that each customer has their own instance of the software, rather than just having an account on a larger system.

For example, LinkedIn wouldn’t be considered SaaS since you’re not getting an instance of the LinkedIn software, just a user account. However, signing up for a blog on WordPress.com gives you your own WordPress instance, on its own subdomain, with its own set of users. This would be considered SaaS.

There are more complex examples such as Sourceforge, which gives you an account within their system, but also instances of software for your project such as bug trackers and wikis. Google Docs also blurs this definition.

SaaS providers will usually offer a multiple tiers of service, ranging from a highly limited free account to a well provisioned or even “unlimited” paid account.

There are 2 key advantages of SaaS. Firstly, it completely removes the administrative overhead of deploying software. Usually a few clicks of a web interface is all it takes to “install” your SaaS instance, and the provider takes care of the computing and storage resources required. Secondly, you can access the software from anywhere. As long as a machine has an Internet connection and a web browser, no further setup is usually required for end users.

There are of course potential issues to be aware of. Unlike having software deployed locally, or a web application deployed in-house, you’re unlikely to have direct access to your data (and depending on the terms of service, you might not even own it). All data will be stored by your SaaS provider and presented through the application. This makes backing up or archiving data locally difficult if not impossible, and requires absolute trust and confidence in your provider and their security policies.

While having your software available from any machine with a web browser and Internet connection is very convenient, this can be a double-edged sword in a situation where one of these isn’t available.

Open source software appears in the SaaS world in several guises, as Scott discussed in this week’s post. Some SaaS products may be built using permissively-licenced components, but with some proprietary code sticking it all together.

Of course, a complete open source software product may be offered as a service. WordPress is released under the GNU General Public Licence (GPL), but is offered as both a free and commercial service at WordPress.com and other providers. ownCloud is released under the Affero General Public Licence (APGL) and available as a service from owncloud.com and other providers. The terms of the AGPL, unlike those of the GPL, mean that even when provided as a service the service provider must allow you to download the source code.

The benefits of choosing an open source product when selecting SaaS isn’t as clear-cut as for lower layers of the “cloud” stack. If the product isn’t released under AGPL, the service provider doesn’t have to distribute the source code. If the software is released under a different open source licence, you will probably be able to download the software elsewhere and run your own instance locally as a contingency. However, without access to your data, the utility of this contingency is limited.

SaaS solutions using a combination of open source and proprietary components, as far as the customer is concerned, may as well be entirely proprietary. The provider may be developing and releasing the open source components, and these may be useful in other systems. However, in terms of the service being provided, the fact that some parts are open source doesn’t directly benefit the customer, only the provider.

When considering open source SaaS solutions, the key factor to look for is the portability of data. WordPress can publish your data in standard RSS formats. Some products will have an “export” feature, allowing your to download a copy of your data. In these cases, you realise the benefits of choosing an open source product, as you can easily move your data to another provider or an in-house copy of the software.

Open Sankoré: Open source whiteboard software

Interactive whiteboards are something you find in pretty much every school, college and university these days. Mostly these come from one of two companies, Smart and Promethean, both of which also supply the main software application that typically teachers and students interact with. This application is closed source and runs on Windows and does some basic things like allowing the teacher or student to draw on the board using drawing tools, import presentations and documents, and include some interactive content.

Open Sankoré is an open source whiteboard application, and it does basically the same kinds of thing the Smart and Promethean software does.

Whats also surprising about it is that it also implements the W3C Widgets specification for its interactive content. Which means as well as scribbling notes on documents, and doing drawings, you can also drag in widgets developed for Apache Wookie or created using Widgat or MyCocktail and use those on the whiteboard.

Both Promethean and Smart have also been working on adopting W3C Widgets for a common interactive content standard – Smart even integrated Apache Wookie in prototypes for the ITEC project – but seemed to have problems bringing that innovation to market.

I had a play around with the application and it looks like a very good drop-in replacement for standard whiteboard software, and also works on other kinds of devices. In the screen capture below, I’ve added my Monster Math game widget and a Venn Diagram widget I created – you can also see some of the built-in ones in the palette on the right-hand side of the screen:

You can also record your activity live and publish it directly to YouTube, which is a nice touch allowing you to easily create and distribute tutorials as open educational resources.

I’m particularly keen to give it a try with a homebrew interactive whiteboard using a projector and a wii remote using the instructions from Johnny Lee:

YouTube Preview Image

Smart and Promethean have been having issues recently with declining revenues, which has prompted Promethean to start making some noises about going open source lately so it will be interesting to see how this story plays out. If it continues to improve and to match the features of the main closed-source offerings, Open Sankoré definitely has the potential to disrupt the market – imagine partnerships with commodity hardware manufacturers, for example.

Open Sankoré can be downloaded from http://open-sankore.org/ and the source code can be accessed from the developer site.

The project uses a GPL license, and according to its governance information it appears to operate using a meritocratic governance model.

Monetising Ubuntu

Ubuntu is one of if not the most popular Linux-based operating systems aimed at the desktop market.  Ubuntu’s development is primarily sponsored by Canonical, a UK-based company founded by South African entrepreneur Mark Shuttleworth.  Shuttleworth funded the launch of both Canonical and Ubuntu from his personal fortune, raised from the sale of his company Thawte Consulting to VeriSign in 1999.  Since then, he’s continued to provide financial support for the project, and retained his position as the project’s “Self-Appointed Benevolent Dictator For Life“.

Canonical makes money from the often-seen model of providing paid support for its free product.  These products are attractive to businesses who want the peace of mind that experts are available to help out should anything go wrong.  However, if a home user is downloading a free operating system with great community support channels, are they likely to pay $100 per machine for a support contact?  I suspect not, which makes the home market harder to monetise in this way.

For this reason, we’re now seeing moves to make money from Ubuntu users in other ways.  Over the past few years we’ve seen the introduction of Ubuntu One, Canonical’s Dropbox alternative, with free and paid options.  Alongside this we’ve seen the Ubuntu One Music Store, where users can buy music within the bundled music player, a portion of the money going to Canonical.

The next release of Ubuntu, codenamed Quantal Quetzel and due for release this month, sees the introduction of some new channels for Canonical to make money.  The first is integration with Amazon.  The “Dash”, which can be summoned from the desktop to provide a universal search, will now include results for products for sale on Amazon (and possibly other sources depending on the user’s location).  In addition, an icon for Amazon will be among the applications in the desktop’s launcher by default.  Through Amazon’s Associates programme, this allows Canonical to raise money via referral fees for purchases made by Ubuntu users.

Having seen the success of pay-what-you-want schemes like the Humble Bundle, this week Canonical added an extra screen to the download process for the Ubuntu Desktop CD image.  Met with some controversy but generally welcomed, the screen is shown before the download starts, and allows you to contribute some money for your download, if you choose to.  You can also use this to “put your money where you mouth is”, and tell Canonical what to use your money for.  Options include support for games, improving the desktop environment, or just giving Canonical a tip.

It’s always going to be a delicate process working to monetise a well-established free product without upsetting users.  However, for a project like Ubuntu, it’s a necessity.  As Canonical is a private company we have no way of knowing exactly where it gets its money from, but I think it’s a safe bet that home desktop users don’t pay for themselves from the usual paid support model.  Of course, Mark Shuttleworth has plenty of money, but it’s not a sustainable model to rely on the benevolence of one very rich man who can afford to do whatever the hell he likes.  We’re talking about a man who went into space because he felt like it.  If he woke up one day and decided that he’d had enough contributing to Ubuntu, the community had better hope that Canonical was making enough money on it’s own to continue employing great people that make Ubuntu possible.  Finding new and innovative ways to monetise a free product is vital to Ubuntu’s future, and sets a great example to other Open Source projects.

Google releases online education software

Over to Peter Norvig, Google’s Director of Research:

YouTube Preview Image

Course Builder is in fact a means of building dynamic online teaching materials that must be hosted on Google’s Cloud Platform-as-a-Service App Engine. So although the code itself is open source, it is closely linked with a paid service provided by the code’s authors. While there is a partial open source implementation of App Engine  which might potentially allow institutions to host their own courses built using this software, it is not clear at the moment whether Course Builder is compatible with it. Certainly this thread in the Course Builder forums seems to imply that, for the moment at least, Google’s App Engine platform is a necessary component.

This provides an interesting example of open source code being used to leverage uptake of an associated service. App Engine’s charging model involves a free tier of resource usage below which users are not charged. Go above that level, and you will start getting bills.

Also of interest is the fact that Google are positively encouraging users to share the materials and courses they create using the software, with discussion groups dedicated to code and to content side by side. If this invitation to collaborate is accepted by the educational community, it could provide another impetus for institutions to take up App Engine use, as a key to using third party materials. Overall it’s a generous contribution to the corpus of educational software by Google, and one that may well help them drive custom to their services.