Thoughts on TYPO3

Last month, OSS Watch delivered a series of sessions on communication and participation with open source communities at the TYPO3 Developer Days event in Eindoven.

One of the sessions in our series looked at the theory of communities, the varieties of the communities we form and the motivations involved in each.  The core message of the session is that a FOSS community should be a community of interest, with the interest being the problem solved by the community’s outputs.  While many people in a FOSS community are developers, it’s wrong to view it as a community of practice, since other skills are required for a sustainable community.

What’s unusual about the TYPO3 community, is that while it is presented to the world as a single group, the brand actually encompasses 2 distinct groups. One group produces the TYPO3 CMS system, while the other produces the TYPO3 Flow framework and the TYPO3 Neos CMS.

The original development of Flow/Neos was funded by the TYPO3 Association as the “next generation” of the TYPO3 CMS. Indeed, it was originally called TYPO3 v5.  However, after the initial development of v5, TYPO3 v4 usage and development continued.  When it became clear that v4 wasn’t going away v5 became TYPO3 Neos, and the next version based on the v4 codebase became TYPO3 CMS v6.

The situation now stands that the TYPO3 brand is used by 2 distinct projects which have different development teams, different stated values and different cultures.  While the TYPO3.org website makes the history of the project and the branding guidelines clear, I feel that the TYPO3 community as a whole still has an issue to address.

The Sakai community (now part of the Apereo foundation) experienced a similar situation not long ago.  A sub-group of the Sakai 2 community decided it was time to produce a next-generation system, and called it Sakai 3.  However, it soon became clear that many  institutions funding Sakai didn’t agree with the goals of the Sakai 3 project, which created a rift in the community.

Several key partners withdrew their funding for Sakai 3 (which was rebranded Sakai Open Academic Environment, now called Apereo OAE) and continued to use and develop Sakai 2 (rebranded Sakai Collaboration and Learning Environment, now just Sakai).  The 2 projects now co-exist within the Apereo Foundation, a foundation created to foster software projects which support the goals of higher education.  While the projects have survived, the community suffered.

When a community moves from being a single-project to a multi-project community, as both Sakai/Apereo and TYPO3 have, it’s important that the resulting community identify what key commonality make them a single group.  A FOSS community should be a community of interest, and if projects are to share a community, they should have a shared interest.

Apereo has identified its shared interest in software that supports higher education, within which Sakai and Apereo OAE can now co-exist. With this identity, they’ve now taken on additional projects such as Matterhorn and uPortal, with an incubation programme foster new projects in the future.

If the TYPO3 community doesn’t identify the shared interest of TYPO3 CMS and Neos/Flow, they risk suffering further turbulences as Sakai’s community experienced several years ago.

Fortunately, the TYPO3 community are not blind to these issues. Members of the TYPO3 projects have formed a Community Working Group to look into the issues discussed here and steer the community towards a positive future.

It’s my hope that by learning from Apereo and similar multi-project communities, TYPO3 could become a successful umbrella organisation in its own right.

For more on the history of Sakai and the Apereo OAE, check out the “Sakai” tag in Michael Feldstien’s blog archives from 2010 onwards.

Linux Voice launches Moodle hacking competition

The latest issue of Linux Voice included a cover feature on common security flaws in web applications and how they can be exploited.  Alongside this, they are running a competition to win a Linux Voice t-shirt.  To win the competition, you need to be the person who finds the most security vulnerabilities in one of my favorite open source projects, Moodle.

I’ve got a lot of experience of working with Moodle’s codebase, and I know that its developers have taken security seriously.  There’s APIs in there to protect against SQL injection, cross-site scripting and the other common attack vectors.  This is vital in a system like Moodle which might hold a wealth of personal data about students, as well as assignments and assessment systems.

While these APIs exist, Moodle has a huge codebase maintained by a large community of contributors.  You can write a query using the database API which will be protected against attacks, but a lazy or less experienced programmer might have written vulnerable code which hasn’t been replaced.  Equally, you might be able to think of an attack that no-one thought to defend against.  In the wake of Heartbleed and similar high-profile vulnerabilities, it great to see a competition like this encouraging scrutiny of a popular project’s security.

The prizes in the competition will go to whoever has the most security issues verified on the Moodle tracker, whoever can successfully access a specific file in the site’s web root, and whoever can successfully access a specific file outside the site’s web root.  The competition runs until 8th July (unless the server gets destroyed before then), and you can find out the full details on the competition’s website. Happy hacking!

Why you need to evaluate sustainability

When you’re considering free and open source software, whether for procurement or as a basis for developing new software, you need to take account of sustainability. This means evaluating whether the project is capable of delivering improvements and fixing problems with its products in a timely manner, and that the project itself has a reasonable prospect of continuing into the future.

We’ve posted on this subject many times here at OSS Watch, but this graphic from the folks at Black Duck is a good visual reminder of why this is important:

Pie chart showing project demographics

Source: Ohloh project demographics, via Open Source Delivers blog

 

This shows that a whopping 61.9% of FOSS projects tracked by Ohloh are considered “inactive”, while a further 28.4% have “very low” activity. Only 0.7% and 0.4% are rated as having “High” or “Very High” activity.

As a caveat, its worth noting that Ohloh doesn’t track all project activity, so its possible that there are some false negatives. Also, some projects have low activity because they are highly stable and mature. Its also pretty open to debate what constitutes “low” or “high” activity.

However, in general I think this is useful to highlight the importance of sustainability when considering FOSS.

For more information on how to go about evaluating sustainability, read our briefing note, How To Evaluate The Sustainability Of An Open Source Project.

An OSS Watch for your wrist!

At OSS Watch, our name means we get a lot of spam offering to sell us watches, so I decided to find out if there really is an “OSS Watch”. It turns out there is, or at least, an “OS Watch” since it’s more about the watch being open than the software it runs.

The Open Source Watch website provides details of the components to buy, the tools you’ll need, and schematics for 3D-printing the casing. It then has detailed step-by-step guides with photos showing assembly of your own homebrew smartwatch.

The device as built on the site features a 1.3″ OLED screen (the site also suggests other options), bluetooth connectivity, vibration and LEDs for notifications. The whole thing is powered by an Arduino-compaitble microduino (underclocked to save power), and runs off a 500mAh battery with micro USB charging. You get 3 tactile push buttons, a power switch and a port for programming the arduino.

The site doesn’t provide dimensions for the finished device, but by my esimates the face is 40x60mm, and the casing is about 30mm deep. So it’s fairly chunky as you’d expect from a smartwatch, but doesn’t look over the top considering it’s a DIY job.

The software to run on the watch is in development and available on Github. There’s currently some code to display the “watch face” using the arduino, and the beginnings of an iOS app which will presumably send notifications and data via bluetooth.

VALS Semester of Code – FOSS Projects Wanted

The VALS Semester of Code is an upcoming project that will work with universities and FOSS communities to give students real-world experience working in software projects.  Unlike Google Summer of Code, Semester of Code students will be participating for academic credit as part of their degree courses, and we hope that after completion of their project will go on to be effective contributors to the FOSS community.

The VALS initiative is a partership of European universities and SMEs who have been working for several months to plan the pilot of Semester of Code, which will run during the next academic year.  We have now reached the stage where we are signing up FOSS projects who are willing to provide mentored projects of students. We have already seen interest from smaller, single-company projects to larger software foundations, and would like to see more.

If you are part of a FOSS project, large or small, that would be willing to provide one or more mentored projects, we’d love to talk to you about joining Semester of Code.  In return, you’ll get an enthusiastic student providing a valuable contribution to your project.  The VALS team will be on hand throughout the project to answer any questions and help unblock communication issues between mentors, students and academic supervisors.

If you’re interested in taking part, you can email me on mark.johnson@it.ox.ac.uk, or you can sign up to our mailing list directly using this form.

More details about the Semester of Code are available on our FAQ page. If you have any other questions, don’t hesitate to ask on the mailing list, and one of the VALS team will get back to you!

Open source lecture capture at The University of Manchester

We received an excellent contribution to our Open Source Options for Education list this week, in the shape of a real-world usage example of Opencast Matterhorn at the University of Manchester.  The previous examples of Matterhorn usage we’ve had on the list have been documentation of pilot projects, so it’s great to have such an in-depth look at a full scale deployment to refer to.

Cervino (Matterhorn) by Eider Palmou (CC-By)

Cervino (Matterhorn) by Eider Palmou. CC-BY

The case study looks at the University’s movement from a pilot project, with 10 machines and the proprietary Podcast Producer 2 software, to a deployment across 120 rooms using Opencast Matterhorn.  During the roll-out, the University adopted an opt-out policy meaning all lectures are captured by default, collecting around 1000 hours of media per week.

The University has no policy to preferentially select open source or proprietary software.   However, Matterhorn gave the University some specific advantages.  The lack of licensing or compulsory support costs kept the costs down, and combined with the system’s modularity allowed them to scale the solution from an initial roll-out to institution wide solution in a flexible way.  The open nature also allowed for customisations (such as connecting to the University timetable system) to be added and modified as requirements developed, without additional permissions being sought.  These advantages combined to provide a cost-effective solution within a tight timescale.

If your institution uses an open source solution for an educational application or service, let us know about it and we’ll include it in the Open Source Options for Education list.

If all bugs are shallow, why was Heartbleed only just fixed?

This week the Internet’s been ablaze with news of another security flaw in a widely used open source project, this time a bug in OpenSSL dubbed “Heartbleed”.

This is the third high-profile security issue in as many months. In each case the code was not only open but being used by thousands of people including some of the world’s largest technology companies, and had been in place for a significant length of time.

heartbleedIn his 1999 essay The Cathedral and The Bazaar, Eric Raymond stated that “Given enough eyeballs, all bugs are shallow.”  If this rule (dubbed Linus’s Law by Raymond, for Linus Torvalds) still holds true, then how can these flaws exist for such a long time before being fixed?

Let’s start by looking at what we mean by a “bug”.  Generally speaking the term “bug” refers to any defect in the code of a program, whereby it doesn’t function as required.  That definition certainly applies in all these cases, but for a bug to be reported, it has to affect people in a noticeable way.  The particular variety of bugs we’re talking about here, security flaws in encryption libraries, don’t affect the general population of users, even where we’re talking about users on the scale we see here.  It’s only when people try and use the software in a way other than it’s intended, or specifically audit code looking for such issues, that these bugs become apparent.

When Raymond talks about bugs being shallow, he’s really talking about how many people looking at a given problem will find the cause and solution more quickly than one person looking at that problem.  In the essay, Raymond quotes Torvalds saying “I’ll go on record as saying that finding [the bug] is the bigger challenge.”

So the problem we’ve been seeing here isn’t the the bugs took a long time to diagnose and fix, instead it’s that their lack of impact on the intended use of the software means they’ve taken a long time to be noticed.  Linus’s Law still holds true, but it’s not a panacea for security. The recent events affirm that neither open or closed code is inherently more secure.

For more about security in open source software, check out our briefing on the subject.

Software Freedom and Frontline Services

There are many reasons why organisations choose open source software. Sometimes Total Cost of Ownership (TCO) is a key factor. Sometimes the FOSS offering is the market leader in its niche (such as Hadoop for Big Data, or WordPress for blogs). Sometimes its the particular features and qualities of the software.

However, one of the other key characteristics of FOSS is freedom, and this is emerging as an important consideration when using software to deliver key user-facing services.

"If you want to achieve greatness, stop asking for permission"

At the Open Source Open Standards conference in London on April 3rd, James Stewart from the UK Government Digital Service (GDS) stressed the importance of the permissionless character of FOSS. This enables GDS to modify government frontline services whenever there is need, or whenever an improvement can be identified. This means that services can innovate and improve continually without requiring cycles of negotiation with suppliers.

Businesses are also identifying the importance of “delivering constant value and incremental improvement” that can be delivered through participation in FOSS projects, and through permissionless modification.

While it may seem at odds with typical procurement and deployment practices, where software is used for delivering key services to customers, organisations can choose to devote resources to continual innovation and improvement (using agile processes and continuous testing) rather than more traditional models of sparse planned service upgrades. This can make the difference in crowded markets; or for public sector, react to public demand. With FOSS, continual service improvement processes can be implemented in an agile manner.

Free and Open Source Software is an enabler of permissionless innovation, so when evaluating software for frontline services, bear this in mind.

Image by Thomas Hawk used under CC-BY-NC. Please note that the NC clause may be incompatible with reuse of the text of this blog post, which is CC-BY-SA. For avoidance of doubt, syndicate this article using another image.

What can we learn from security failures?

After posting on the Apple goto fail bug, it is regrettable to have to talk about another serious, major bug in open source software so soon. This time it is more serious still, in that it has existed for over ten years, and is relied upon by many other pieces of standardly deployed open source software. The bug is strikingly similar to Apple’s, in that it happens as a result of code which is intended to signal an error but which through a subtle programming fault in fact fails to do so. This bug was found as a result of an audit commissioned by commercial Linux provider Red Hat, and the bug was discovered and publicised by its own author. What can we learn from these two failures in security critical open source code? For a start, it might lead us to question the so-called ‘Linus’ Law‘, first recorded by Eric Raymond:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone.

This is sometimes referred to as the ‘many eyes’ principle, and is cited by some open source proponents as a reason why open source should be more secure than closed source. This conclusion is, however, controversial, and this particular bug shows one reason why. In discussing the reasons why this bug slipped through ten years worth of review, the reviewer/author says the following:

As this code was on a critical part of the library it was touched and thus read, very rarely.

A naive view – and certainly one I’ve subscribed to in the past – is that critical code must surely get reviewed more frequently than non-critical code. In practice though, It can be the subject of a lot of assumptions, for example that it must be sound, given its importance, or that it should not be tinkered with idly and so is not worth reviewing.

So must we abandon the idea that source code availability leads to better security? As I said in the previous post, I think not. We just have to accept that source code availability in itself has no effect. It facilitates code review and improvement, if there’s a will to undertake that work. It makes it easy to share exactly what a bug was once it was found, and in turn it makes it easier for maintainers of other code bases to examine their own source for similar issues. Finally it allows anyone who finds a problem to fix it for themselves, and to share that fix. What we must not do is assume that because it is open source someone has already reviewed it, and – if this incident teaches anything at all – we must not assume that old, critical code is necessarily free of dumb errors.

Open Source Open Standards 2014

The Open Source, Open Standards conference is in London on the 3rd of April 2014, and this year OSS Watch has joined the list of supporters for the event.

open source open standards 2014 conference logo

I attended the conference in 2013, which was well attended from across the public sector and from open source companies and organisations. You can read my post on that event here.

Given how closely aligned open standards and open source software are in the view of policy makers (though we do like to point out that its not quite that simple), its perhaps odd that so few events explicitly cover both bases.

The event is also interesting in that there are as many – more perhaps – talks from the customer point of view as from suppliers. This means it is much more about sharing experiences than the sales-oriented events that are commonly targeted at the public sector, and this is why we decided to be associated with the event this year.

Public sector organisations need to share experiences with each other, not just engage with suppliers, if they are to take advantage of the opportunities of open source software and open standards, and events like this are one place to do just that. (Of course, this applies equally to educational institutions such as universities and colleges – and the organisers are keen this year to open up the scope to include them.)

If you attend the event, feel free to say hello – one of us at least will be there on the day.