OSS Watch team blog
fOSSa 2014 will be in Rennes, France, on 19, 20 and 21 November 2014.
This year the event has three themes:
- Crypto Currencies in context & let’s look under the hood
- Open knowledge creation : Crowdsourcing scientific research
- The new hardware bazaar
For more information and to register visit the fOSSa website.
Sadly I won’t be able to make it this year, which is a shame as its a great event with lots of interesting topics.
This week saw the launch of KAIYUANSHE (开源社), an association comprising both companies and universities with the aim of providing developers in China with education, tools and services to foster a healthy and robust open source ecosystem.
KAIYUANSHE from the outset is working through two core programs. The first, Open Source Star, helps software developers apply an open source license to their projects, and specifically recognize those that use one of the several available OSI-approved licenses.
The second program is called Open Source Ambassadors. Through this program, the alliance aims to recognize individuals and organizations who are actively engaged in community efforts, for their work to champion best practices and collaboration.
At OSS Watch here at the University of Oxford we’ve also been collaborating with the new initiative, providing access to our content and tools so that they can be localised and translated. You can find Chinese versions of some of our briefing notes on the KAIYUANSHE website already, and I’m sure more will soon follow.
Initial members of the association include Ubuntu Kylin, Microsoft Open Technologies, GitCafe, CSDN and Mozilla. For more information visit the KAIYUANSHE website.
Last weekend I organised the first OggCamp to be held in Oxford. OggCamp is an annual free culture unconference, where 300 people with a variety of interests related to open source, open hardware, creative commons and more meet up to share projects, ideas and experience.
As an unconference, the vast majority of the scheudle is decided on the day. This means that we never really know what’s going to happen, but we always have a great range of interesting talks, and this year was no different. Talks this year included a demo of a hydrogen-powered Raspberry Pi, the beginnings of a project to create an open source wireless presentation dongle, software-defined radio, and several live podcast recordings.
Alongside our 3 presentation tracks, we had a fantastic exhibition hosting stands from the events sponsors as well as a number of local hackspaces. Projects being showed off included a vintage teletype connected to Twitter, an open source CNC router, a home heating automation system, and a persistance-of-vision display using a bike wheel.
The result of all of this was a fantastic weekend full of fun an inspiration. Next year’s event isn’t in the works yet, but I’m already excited for next time.
Back in August Wikimania came to London and I heard some interesting discussion there of Wikipedia’s approach to open access materials and the tools they are developing to support that approach. This github repo contains some interesting open source projects designed mainly to automate the process of identifying cited external resources that can be copied into Wikipedia’s repositories of supporting material wikisource (for texts) and upload.wikimedia.org (for pictures, video and sound).
open-access-media-importer for example is a tool which searches the online repository of academic biology papers PubMed for media files licensed under the Creative Commons attribution licence and copies them into the wikimedia repository. Where the files are in media formats that are encumbered by patents, the script also attempts to convert them to the patent free ogg format framework.
In the same github repo is the OA-Signalling project presents a developing framework for flagging open access academic papers using standardised metadata, perhaps integrated in future with the systems being developed by DOAJ and CrossRef. This wikipedia project page explains further:
Some automated tools which work with open access articles are already created. They impose nothing upon anyone who does not wish to use them. For those who wish to use them, they would automate some parts of the citation process and make an odd Wikipedia-specific citation which, contrary to academic tradition, notes whether a work is free to read rather than subscription only. The tools also rip everything usable out of open access works, including the text of the article, pictures or media used, and some metadata, then places this content in multiple Wikimedia projects including Wikimedia Commons, Wikisource, and Wikidata, as well as generating the citation on Wikipedia.
During the sessions in which open access and these tools were discussed, many participants expressed strong dislike for academic publishers and their current closed practices. Clearly for many the idea that Wikipedia could become the de facto platform for academic publication was a charming idea, and more open access was seen as the best route to achieving this.
Many years ago I worked in a digital archive, and one of the problems we faced was that academics who were depositing their databases and papers wanted to be able to revise them and effectively remove the earlier, unrevised versions. Naturally this made our jobs more challenging, and to a certain extent seemed to be opposed to the preservation role of the archive. My experiences there make me wonder how the same academics would react to their papers being hoovered up by Wikipedia, potentially to become unalterable ‘source’ copies attached to articles in the world’s most used reference work. On the one hand it is a great practical application of the freedoms that this particular kind of open access provides. On the other hand, it perhaps risks scaring authors into more conservative forms of open access publication in the future. Personally I hope that academics will engage with the tools and communities that Wikipedia provides, and handle any potential friction through communication and personal engagement. And in the end, as these tools are open source, they could always build their own hoover.
We’ve decided to change the way we publish our newsletter, so instead of having a separate site over at http://newsletter.oss-watch.ac.uk, from now on we’ll be posting a monthly round-up of our activities on this blog. If you’re only interested in these round-ups, you can subscribe to the feed for the Newsletter category. We’ll still be publishing event reports, analysis and opinion pieces on this blog as before.
This month is a bumper edition covering what we’ve been up to over the summer. With Kuali announcing its move to a company-based governance model, Scott has looked at whether this means the end of “community-source”, and whether its choice of an AGPL license poses a risk of vendor lock-in.
We’ve also continued our work with the VALS project, helping over 60 FOSS organisations submit over 250 project ideas. The participating universities have now signed up for the programme, and students are submitting their project proposals.
Finally for this month, Mark attended the first AGM of the Research Software Engineers UK group, who are seeking to champion and support software developers working with researchers.
Last Monday I attended the first (hopefully of many!) AGM of The UK Community of Research Software Engineers. The group has been formed to champion the cause of software engineers producing software of research, be they developers who are embedded in research groups, or academics who have found themselves developing and maintaining software. Throughout the day, there were a number of issues debated by the group.
While the career path for academics hinges on them publishing papers, developers contributing to research through their work often find that they dont get the opportunity to publish. One of the problems that RSE seeks to address is finding an alternative way of universities giving recognition to the contribution of software engineers to research.
Should universities seek to support development of research software centrally, or is it better done in departments? At UCL, they’ve formed a central group of developers, partly from core funding and partly from project funding, who can provide development effort to research projects. While this provides a useful core of development expertise, a central service can’t provide the same level of domain-specific knowledge that some research groups will require, and some institutions simply don’t have the skills base in central IT to provide the development support that researchers would find valuable.
Another approach for central support for research software engineers is to provide training and tools to support good software engineering practice. Version control, continuous integration and other common tools can be instilled in researchers’ workflows through collaboration with experienced developers, or through training initiatives such as Software Carpentry. Provisioning systems like GitLab and Jenkins centrally provides easy access to infrastructure which supports these practices.
These issues and more were discussed in groups over the day, and will continue to be discussed by the RSE community. If you’re a research software engineer, or just want to help champion their cause, you can visit the website and join the discussion group.
Today Jisc announced the beta G4HE website. The site pulls data from the BIS-funded RCUK Gateway to Research API and provides an interface to allow searching and visualising data on research in the UK.
For example, you can see at a glance the councils funding research at the University of Oxford, as well as the key collaboration partners in joint research work
There are several interesting “open” angles to this project.
First, its ‘open’ in the sense that the site is opening up access to information about research spending.
Second, the site is using crowdsourcing to clean up the available data to make it more meaningful – for example by asking visitors to help identify duplicates and naming mistakes from the original data.
Chuck Severance recently published a post entitled How to Achieve Vendor Lock-in with a Legit Open Source License – Affero GPL where he criticises the use of AGPL licenses, particularly its use – or at least, intended use – by Kuali. Chuck’s post is well worth reading – especially if you have an interest in the Kuali education ERP system. What I’m going to discuss here are some of the details and implications of AGPL, in particular where there are differences between my take on things and the views that Chuck expresses in his post.
Copyleft licenses such as GPL and AGPL are more restrictive than the so-called permissive licenses such as the Apache Software License and MIT-style licenses. The intent behind the additional restrictions is, from the point of view of the Free Software movement, to ensure the continuation of Free Software. The GPL license requires any modifications of code it covers to also be GPL if distributed.
With the advent of the web and cloud services, the nature of software distribution has changed; GPL software can – and is – used to run web services. However, using a web service is not considered distributing the software, and so companies and organisations using GPL-licensed code to run their site are not required to distribute any modified source code.
Today, most cloud services operate what might be described as the “secret source” model. This uses a combination of Open Source, Free Software and proprietary code to deliver services. Sometimes the service provider will contribute back to the software projects they make use of, as this helps improve the quality of the software and helps build a sustainable community – but they are under no obligation to do so unless they actually choose to distribute code rather than use it to run a service.
The AGPL license, on the other hand, treats deployment of websites and services as “distribution”, and compels anyone using the software to run a service to also distribute the modified source code.
AGPL has been used by projects such as Diaspora, StatusNet (the software originally behind Identi.ca – it now uses pump.io), the CKAN public data portal software developed by the Open Knowledge Foundation, and MIT’s EdX software.
[UPDATE 20 September 2014: EdX has since relicensed its AGPL component under the Apache License]
We’ve also discussed before on this blog the proposition – made quite forcefully by Eben Moglen – that the cloud needs more copyleft. Moglen has also spoken in defence of the AGPL as one of the means whereby Free Software works with cloud services.
So where is the problem?
The problem is that the restrictions of AGPL, like GPL before it, can give rise to bad business practice as well as good practice.
In a talk at Open World Forum in 2012, Bradley Kuhn, one of the original authors of AGPL, reflected that, at that time, some of the most popular uses of AGPL were effectively “shakedown practices” (in his words). In a similar manner to how GPL is sometimes used in a “bait and switch” business model, AGPL can be used to discourage use of code by competitors.
For example, as a service provider you can release the code to your service as AGPL, knowing that no-one else can run a competing service without sharing their modifications with you. In this way you can ensure that all services based on the code have effectively the same level of capabilities. This makes sense when thinking about the distributed social networking projects I mentioned earlier, as there is greater benefit in having a consistent distributed social network than having feature differentiation among hosts.
However, in many other applications, differentiation in services is a good thing for users. For an ERP system like Kuali, there is little likelihood of anyone adopting such a system without needing to make modifications – and releasing them back under AGPL. It would certainly be difficult for another SaaS provider to offer something that competes with Kuali using their software based on extra features, as any improvements they could make would automatically need to be shared back with Kuali anyway. They would need to compete on other areas, such as price or support options.
But back to Chuck’s post – what do we make of the arguments he makes against AGPL?
If we look back at the four principles of open source that I used to start this article, we quickly can see how AGPL3 has allowed clever commercial companies to subvert the goals of Open Source to their own ends:
- Access to the source of any given work – By encouraging companies to only open source a subset of their overall software, AGPL3 ensures that we will never see the source of the part (b) of their work and that we will only see the part (a) code until the company sells itself or goes public.
- Free Remix and Redistribution of Any Given Work – This is true unless the remixing includes enhancing the AGPL work with proprietary value-add. But the owner of the AGPL-licensed software is completely free to mix in proprietary goodness – but no other company is allowed to do so.
- End to Predatory Vendor Lock-In – Properly used, AGPL3 is the perfect tool to enable predatory vendor lock-in. Clueless consumers think they are purchasing an “open source” product with an exit strategy – but they are not.
- Higher Degree of Cooperation – AGPL3 ensures that the copyright holder has complete and total control of how a cooperative community builds around software that they hold the copyright to. Those that contribute improvements to AGPL3-licensed software line the pockets of commercial company that owns the copyright on the software.
On the first point, access to source code, I don’t think there is anything special about AGPL. Companies like Twitter and Facebook already use this model, opening some parts of their code as Open Source, while keeping other parts proprietary. Making the open parts AGPL makes a difference in that competitors also need to release source code, so I think overall this isn’t a valid point.
On the second point, mixing in other code, Chuck is making the point that the copyright owner has more rights than third parties, which is unarguably true. Its also true of other licenses too. I think its certainly the case that, for a service provider, AGPL offers some competitive advantage.
Chuck’s third point, that AGPL enables predatory lock-in, is an interesting one. There is nothing to prevent anyone from forking an AGPL project – it just has to remain AGPL. However, the copyright owner is the only party that is able to create proprietary extensions to the code without releasing them, which can be used to give an advantage.
However, this is a two-edged sword, as we’ve seen already with MySQL and MariaDB; Oracle adding proprietary components to MySQL is one of the practices that led to the MariaDB fork. Likewise, if Kuali uses its code ownership prerogative to add proprietary components to its SaaS offering, that may precipitate a fork. Such a fork would not have the ability to add improvements without distributing source code, but would instead have to differentiate itself in other ways – such as customer trust.
Finally, Chuck argues that AGPL discourages cooperation. I don’t think AGPL does this any more than GPL already does for Linux or desktop applications; what is new is extending that model to web services. However, it certainly does offer less freedom to its developer community than MIT or ASL – which is the point.
In the end customers do make choices between proprietary, Open Source, and Free Software, and companies have a range of business models they can operate when it comes to using and distributing code as part of their service offerings.
As Chuck writes:
It never bothers me when corporations try to make money – that is their purpose and I am glad they do it. But it bothers me when someone plays a shell game to suppress or eliminate an open source community. But frankly – even with that – corporations will and should take advantage of every trick in the book – and AGPL3 is the “new trick”.
As we’ve seen before, there are models that companies can use that take advantage of the characteristics of copyleft licenses and use them in a very non-open fashion.
There are also other routes to take in managing a project to ensure that this doesn’t happen; for example, adopting a meritocratic governance model and using open development practices mitigates the risk of the copyright owners acting against the interests of the user and developer community. However, as a private company there is nothing holding Kuali to operate in a way that respects Free Software principles other than the terms of the license itself – which of course as copyright owner it is free to change.
In summary, there is nothing inherently anti-open in the AGPL license itself, but combined with a closed governance model it can support business practices that are antithetical to what we would normally consider “open”.
Choosing the AGPL doesn’t automatically mean that Kuali is about to engage in bad business practices, but it does mean that the governance structure the company chooses needs to be scrutinised carefully.
As we’ve mentioned before, OSS Watch is involved in the VALS Semester of Code project, enabling university students to participate in open source projects as part of their degree course. There’s a week left for FOSS projects to sign up and submit their mentored projects for the pilot, before the students can sign up and submit their proposals. As reported on the Semester of Code website, there’s been a fantastic response so far:
Organisations that Semester of Code students will have the opportunity to work with include the NASA Jet Propulsion Laboratory, Moodle, OpenMandriva and Lime Survey. The project ideas submitted so far cover topics such as audio processing, HTML parsing, API design, web development and many more.
You can read the full announcement on the Semster of Code site.
For quite some time now at OSS Watch we’ve struggled with the model of “Community Source” promoted by some projects within the Higher Education sector. Originating with Sakai, and then continuing with Kuali, the term always seemed confusing, given that it simply meant a consortium-governed project that released code under an open-source license.
As a governance model, a consortium differs from both a meritocracy (as practised by the Apache Software Foundation) or a benevolent dictatorship, or a single-company driven model. It prioritises agreement amongst managers rather than developers, for example.
We produced several resources (Community Source vs. Open Source and The Community Source Development Model) to try to disambiguate both the term and the practices that go along with it, although these were never particularly popular, especially with some of the people involved in the projects themselves. If anything I believe we erred on the side of being too generous.
However, all this is about to become, well, academic. Sakai merged with JaSig to form the Apereo Foundation, which is taking a more meritocratic route, and the most high-profile project using the Community Source model – the education ERP project Kuali – has announced a move to a company-based governance model instead.
I think my colleague Wilbert Kraan summed up Community Source quite nicely in a tweet:
‘Community source’ probably reassured nervous suits when OSS was new to HE, but may not have had much purpose since
Michael Feldstein also provides a more in-depth analysis in his post Community Source Is Dead.
There’s good coverage elsewhere of the Kuali decision, so I won’t reiterate it here:
- Collaborative that once criticised software companies becomes one [Chronicle]
- Kuali For-Profit: Change is an indicator of bigger issues [e-Literate]
A few months ago we had a conversation with Jisc about its prospect to alumnus challenge, where the topic of Kuali came up. Back then we were concerned that its governance model made it difficult to assess the degree of influence that UK institutions or Jisc might exercise without making a significant financial contribution (rather than, as in a meritocracy, making a commitment to use and develop the software).
Its hard to say right now whether the move to a for-profit will make things easier or more difficult – as Michael points out in his post,
Shifting the main stakeholders in the project from consortium partners to company investors and board members does not require a change in … mindset
We’ll have to see how the changes pan out in Kuali. But for now we can at least stop talking about Community Source. I never liked the term anyway.
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 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.
I can be contacted at: http://projectyamina.strikingly.com/#become-involved
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.
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.
Since Black Duck bought the site back in 2010 there haven’t been any obvious changes.
Until now that is:
Dear Ohloh user,
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!
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.