July 13, 2016
The EU-FOSSA project is something not only Endocode cares about. You should care about it too. Why? Let’s see what our Open Invention Network representative, European free software activist and CEO (aka the boss boss) Mirko Böhm has to say about it:
The EU-FOSSA project’s mission is to “offer a systematic approach for the EU institutions to ensure that widely used critical software can be trusted”. The project was triggered by recent software security vulnerabilities, especially the Heartbleed issue. An inspired initiative by EU parlamentarians Max Andersson and Julia Reda, the pilot project “Governance and quality of software code – Auditing of free and open source software” became FOSSA. Run under the auspices of DIGIT, the project promised “improved integrity and security of key open source software”. I had been interviewed as a stakeholder by the project during work package 0 (“project charter, stakeholder interviews and business case”), and later worked with the FSFE group that provided input and comments to the project to EC-DIGIT. While I believe that the parliamentary project champions and the people involved in the project at EC-DIGIT are doing great work, I am worried that the deliverables of the project are beginning to fall short of expectations. I also think the free software community needs to get more involved. Here is why.
When I was approached by the project in the early phase to be interviewed as a representative of the Open Invention Network and a European free software activist, I felt very motivated to help get the project off to a good start. Already during the initial interview doubts emerged about the approach and the apparently pre-conceived ideas of the consultants that had been tasked with the project. Essentially, it seemed they intended to audit Drupal, and wanted the European Commission to do code reviews. These doubts became stronger when the project published a survey about which programs to audit that included 7-zip as a critical free software component, and other funny choices like “Linux – selected system library” without any qualifications. Recently the project began publishing it’s deliverables, and the results gave me and others involved a pause. For example, have a look at Matthias’ comments here. The recommendations show a systematic lack of understanding of the free software/open source community process and the nature of the collaborative peer production performed by them.
Here is a highlight, a “conclusion and recommendation” from section 4.1. Project Management in deliverable 1: “FOSS communities should … use a formal methodology based on PMBOK, depending on their possibilities.” PMBOK or the “project managament body of knowledge” (a fat and well-studied volume in my book shelf) is essentially the bible of waterfall project management based on the assumption of working in a large, hierarchical organisation. It is immensely useful in such environments, especially in the public sector. Just not in the wider free software community, which uses mechanisms as self-identification to distribute tasks and depend on voluntary contributions of their participants.
Here is another one, from section 4.2 Software Development Methodology: “FOSS communities should use … agile-based methodologies, according to their resources, so as to make software development more efficient”. Daily scrum anybody, and “the list” of tasks that are allowed to be worked on? Contributors to free software communities, be they individuals or companies, participate voluntarily. They especially do not take assignments or orders from a central coordinating agent, which incidentally does not exist as a role in most relevant communities. Agile methods can be extremely useful and help software teams a lot, but imposing them on a free software project is not an option. The recommendation is also questionable in its premise – that increasing efficiency in community software development is necessary. There are communities with very efficient software development processes (the Linux kernel developers, for example) and others that are not so great. However the efficiency may depend on the number of active contributors, or the complexity of the project goals, or the skill and experience level of the average contributor. Management of development efficiency is a community governance task that defies simplicistic answers like “use this method”. Those are platitudes, and taking them at face value runs the risk of damaging the community development culture.
I could point out more, but as a third example, allow me to highlight a few aspects that did not make it into the report: In deliverable 4, section 4.5 Relevant opinions and advice from interviewees, item 5 says “One possibility is for the European Institutions to do code reviews and share the results with the affected communities.” Sure, however the alternative recommended by FSFE and me and anybody I spoke to about this was for European institutions to not perform code reviews themselves because that is not their area of expertise, and instead to facilitate code reviews in the communities, in cooperation with universities and the national IT security agencies of the member states that already have similar programs in place or are working on them. The pre-conceived idea – the EC should perform the audits – shines through.
In short, the results so far are disappointing, which is sad because the idea behind FOSSA is great, and we should applaud the EU/EC project team for their work and the initiative they took. However the parties performing the research did not hear or fully understand the input and feedback provided by the community. The questionable recommendations are based on a lack of understanding that may in part be caused by tasking generalist research contractors to study the subject. Free software community management is a profession with a difficult subject matter. The fact that everybody can join and participate does not mean that the underlying social process is easy and intuitive to understand for outsiders. We don’t ask painters to recommend medical practises, either.
Because of that, I believe the EC-FOSSA project can still be fixed. The free software community needs to get closer to the project and more involved, study the deliverables and provide feedback and alternative recommendations. The project partners are encouraged to work more directly with the free software communities, and to adopt open and collaborative processes in the project similar to the once used in the communities themselfes. More direct actions to improve the process in the FOSSA project are possible. If this means for EC-DIGIT to step out of the usual procurement routine and set of suppliers of studies, so be it. After all, this is 1 million euro definitely spent for the common good.
Image credit: J. Albert Bowden II, CC-BY, unmodified.
written by: Mirko Böhm