Project Yamina: Encouraging the next generation

This is a guest post from Hunter from Project Yamina, one of the student-led projects that won a place in the Jisc Student Innovation programme. Here at OSS Watch we’re supporting the programme over the summer and advising students on their projects.

Hi, my name is Hunter and I’m responsible for a new website called “Project Yamina”. This summer, I’m part of the JISC Student of Summer Innovation. JISC wanted new ideas – from students – that would show how technology can improve students’ life. Their hope is, with the assistance of funding, the twenty successful projects will create something worthwhile by November.

Project Yamina Logo

Project Yamina started as a first year university design project. Based on the workplace, we had to come up with something that would change the work environment for the better. Looking at research, I saw there was a large volume of careers that people viewed as being more suited for men; jobs that people imagined few women worked in. For example Free Software and Open Source communities - women are very under-represented. I thought that this was crazy, and came up with the idea of changing the workplace  – and these attitudes – by finding a way to encourage more girls to enter some of these jobs.

The idea of Project Yamina is for it to be an online magazine. Something full of interesting profiles (on both women and careers), personal essays, helpful facts and tips, alongside news items. Then, I hope girls will look at the site, and discover a woman who is a (for example) scientist, coder, police officer or sniper. Perhaps she’ll think it sounds interesting, and it’s a career she would like to do too.

I’m looking for people to be featured as profiles – this means answering a handful of questions for me, or writing a short essay on any topic to do with your work and experiences. Don’t worry, it doesn’t have to be anything  too formal – I want the website to be fun for everyone involved. Of course, you’re welcome to write an essay and be a profile too! I’m extremely keen to have people from all backgrounds involved, especially those who would like to talk about how they overcame adversity, even if you’d like to stay anonymous.

To find out more, Visit the website: http://projectyamina.strikingly.com or blog: http://projectyamina.tumblr.com

I can be contacted at: http://projectyamina.strikingly.com/#become-involved

VALS Semester of Code open for project idea submissions

As we’ve mentioned before, OSS Watch is working as part of the VALS Project to run a Semester of Code, engaging students with FOSS projects as part of their studies.  This week, our Virtual Placement System went live, allowing projects to register and submit ideas for student projects.

If you’re part of a FOSS project and would like to participate, make sure you’re signed up to the mailing list, then head over to http://vps.semesterofcode.com and follow these steps:

Firstly, a member of your organisation to sign up as an Organisation Administrator and register your organisation;

  • Go to http://vps.semesterofcode.com/ and click “Create New account” under the login form
  • Fill in your basic details and select “Organisation Administrator” as your role
  • Enter the following sign-up key: AHGLL765OW
  • Click “Create New Account”
  • You will recieve and email with a one-time login link. Log in and set your password.
  • Click on the “Dashboard” link
  • Click “Managed Organisations” and complete the form.

You will now see your organisation’s details with 2 codes: One to allow your mentors to sign up, and one to allow additional administrators for your organisation to sign up.

Once registered, you and your mentors can submit ideas;

  • Log in and click the Dashboard link
  • Click “Manage your project ideas”
  • Fill the form (You may have to click the “Add” tab if you have already submitted ideas”
  • When entering the description, please consider the following guidance:
    At a minimum, please include the expected outcome of the project, a  potential mentor, the skills and/or languages required to  complete the project, and a general “difficulty” level.

    The project should take about 3 months to complete. Please bear in mind that it’s better to start with a smaller project that can be extended if your student proves to be capable rather than have an over-ambitious idea which can’t be completed in time.

  • Include a link to a bug tracker issue or somewhere in your project’s workflow system that this project will be tracked

If you have any questions or feedback about the Virtual Placement System or the Semester of Code programme, please get in touch on the mailing list.

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!

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 in education: where does the change need to happen?

In our recent survey on free and open source software in the UK education sectors, we asked colleges and universities for their main reasons for not selecting an open source solution according to 12 criteria. Below you can see how important each of the criteria were rated for software running on servers:

Interoperability and migration problems 80
Lack of support 71
Poor quality software 60
Not what users want 51
Lack of staff expertise, training needs 49
There is no open source solution for our needs 43
Legal issues including licensing 30
Time costs of identifying relevant software 29
Migration costs 25
Existing contractual obligations 18
Poor documentation 15
Solution does not scale 14

The question I’d like to pose today is – if we were to consider these as representing the barriers to greater adoption of free and open source software in education, are the barriers to be found within institutions, or are there issues with the available supply of software and services to the sectors?

To answer this I’ve split the criteria into two groups – supply-side and demand-side. Lets look at the supply-side first of all.

Supply Side Factors

Supply-side factors

Three of the top four criteria are supply-side considerations: lack of support, poor quality software, and not offering what users want.

We could also consider “There is no open source solution for our needs” as being largely the same thing as not offering what users want, which would place it as the top concern.

This would imply that, from the perspective of colleges and universities, the open source software community just isn’t offering the kind of software products the sectors need.

From our experience in compiling the Open Source Options for Education list, this would seem a bit curious. Perhaps the issue is one of awareness and marketing? Or are there significant niches in education where there really are no open source options? We also know that the procurement processes in many institutions would likely exclude open source from consideration – is this also a factor in this lack of awareness?

The second major issue on the supply side would then be the provision of services and support. As we’ve seen in the public sector, having commercial partners is a crucial factor in getting solutions adopted. (There is a chicken-and-egg issue here is that there has to be adoption to support a services market, but lack of services hampers adoption.)

Finally there is the quality issue – are open source solutions aimed at education really poor quality? Or is it that the kinds of solutions being considered are not mature?

Now lets look at the demand side.

Demand Side Factors

Demand side factors

The top issue is interoperability and migration problems – if we also add in the respondents who considered migration costs, then it is by far the most cited reason why open source isn’t selected.

We’ve noted before that there is no simple relationship between open source, open standards, and interoperability; while in principle open source affords the adoption of open standards and greater interoperability, the practice is a lot less clear cut.

However, what we haven’t untangled here is whether the issue is with open source options lacking interoperability features or standards compliance, or whether the issue lies with the incumbent systems they would replace.

The next ranked issue is lack of staff expertise; again we haven’t untangled whether this is a lack of expertise amongst the potential users of the software, the IT operations staff, or the staff involved in the procurement so its hard to interpret precisely. Given the question relates to server software it could be any of these groups.

It may also be the case that this issue goes hand-in-glove with that of lack of support from the supply side; often for server-side software the complexity of configuration and operations can be overcome by contracting a supplier to deal with it on your behalf. For  open source options, if there are no suppliers of services available then its up to the institution’s staff to figure it out.

Finally, the rest of the issues here fall under the category of contractual, legal and procedural issues with procurement itself. While each individual item is not ranked highly, taken together they suggest there are significant barriers still in place in procurement. This is something we’ve been looking into recently in more depth, for example in our Decision Factors for Procurement briefing.

Conclusions?

Taken altogether, the demand side and supply side issues of open source adoption in education carry pretty much equal weight from the viewpoint of the institutions themselves. But what are we to make of it?

I think we can distill it into five challenges:

1. We need to tackle the interoperability question. Is lock-in a problem? Is lack of standards a problem? This is something our friends at CETIS could take a lead on.

2. We need to improve awareness of existing open source solutions available within the sector;  lists like our Open Source Options for Education are useful here, but projects also need to be more proactive in raising awareness, and may need a higher profile at events such as the UCISA and ALT conferences.

3. Institutions need to improve software procurement processes so that they can consider open source solutions effectively and equally with closed source.

4. We need to build up the open source services market for education. ULCC have been very effective with their Moodle hosting, but companies supporting other major open source software solutions don’t seem to have much of a presence in the education sector. (As I mentioned earlier though, this is a bit of a chicken-and-egg problem)

5. Bootstrap projects in areas where there are no existing open source solutions. Of course there are well known problems with funded projects, but there are alternative approaches, for example the Jisc Co-Design programme could play a role here.

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.