The Scholarly Kitchen recently published an article about Open Source and Open Access, and referenced a 2012 blog post by Scholastica justifying why they did not provide access to the source code of their Open Access publishing platform.

As someone who has been involved with Open Source projects since his early teens, I feel that both articles are based on quite a few misconceptions about Open Source. In fact, I would argue that Open Source and Open Access actually go great together.

“Open Source only works at a large scale”

[A] key element in a successful open source environment is scale — there have to be enough people with enough skill and enough time and enough passion deriving enough benefit from the open source solution for it to remain viable.

Yes, software projects can only survive if there are people willing to work on them. However, it is a misconception to believe that this can only be the case for large-scale projects. Both Scholastica and the Scholarly Kitchen mention a raft of successful, well-known open source projects, but fail to mention the long tail of successful projects that are supported by smaller companies or organisations.

In the end, all it takes is a single entity that wants a solution to exist, and that has the ability to make that happen. If Scholastica would have open sourced their code, that does not mean they would have stopped working on it. While their belief that they would not receive many contributions because “most scholars are not Ruby or Python programmers”, the fact is that they have not received any contributions to their closed source code either. In other words, even with few or zero contributions, their software would not have been worse off than it is today had it been open source.

I think the authors would be surprised by how many contributions small open source projects can receive, but one thing they can be sure of: closed source projects receive none.

“Open Source software is inherently different from/worse than closed source software”

The Scholarly Kitchen seems to suggest that Open Source software might be inherently insecure:

[T]he Equifax breach may have been made possible because of a vulnerability in some open source software the company used.

Scholastica, too, repeatedly insinuates Open Source software to be of lower quality:

User experience and design suffer. (…) Difficult to maintain quality. (…) Troubleshooting tech problems relies on the goodwill of the community. (…) If you don’t have a robust community contributing to the code, the project does not improve.

All these points suffer from the association fallacy where they assume that, just because the provided examples happen to be of open source software, those properties hold for all open source software.

However, like Open Access, Open Source is primarily just a license. Software quality is determined more by good project management and development practices than it is by license. Just because your project is open source, that doesn’t mean that you can’t do tech support. It doesn’t mean you should skip UX testing, Quality Assurance, or working on the code. And just like regular software projects, it takes good management to prevent the collision of “egos among the different developers”.

“Open Source is done by volunteers”

[I]ndirect risks around the sustainability of open source efforts are worth considering. A critical factor includes programming person-power, which is dependent on goodwill. Not getting paid while seeing major corporations make hay from your volunteer labor both erode goodwill.

Almost every Open Source project mentioned by either of the two articles has a large number of contributors whose job description includes contributing to open source projects. Even if Scholastica had decided to open source their software, that does not mean their developers would work on their code for free from then on.

There are plenty of examples of successful commercial companies whose primary product is Open Source — for some, this is even their primary selling point. Interestingly, the Scholarly Kitchen mentions GitHub as an example of a successful company that, due to being commercial, “speeds innovation in a more reliable manner”. In fact, however, many of their users found that GitHub had become lacklustre in the innovation department. That is, until they got kicked back into gear by a new company entering its market: GitLab. And most of the code behind GitLab incidentally happens to be open.

So yes, before using a project you have to consider whether a project’s maintainers are able to support it in the long term before adopting it — this holds true for both closed and Open Source software. But an Open Source license does not preclude a project from being backed by a stable and committed organisation.

Why Flockademic is Open Source

There are quite a few other misconceptions in both articles, but since many of them can be debunked along the same lines, I’ll leave that as an exercise for the reader. However, with no reasons left not to to Open Source an (Open Access) project, what arguments are there in favour of Open Sourcing?

Now, I should first mention that I hadn’t initially given this much thought: given Flockademic’s mission, and being a non-profit, it only felt natural to develop the code in public. If you want more people to be able to contribute to the body of scientific knowledge, then allowing more people to contribute to that cause is a logical corollary. In other words: almost every argument in favour of opening up access to research, also applies to opening up access to software.

In addition to the moral argument, however, there are a few other benefits to open source.

First of all, it spares you a lot of effort that comes with hiding code — and this is not to be underestimated. Compare this with the situation in scholarly publishing. Simply making an article available to everybody is relatively easy. However, adhering to the publishers’ restrictions — in terms of embargoes, license, costs and, if Elsevier gets their way, even geography— can be a lot of work. Likewise, I’ve simply made all Flockademic code openly available on existing infrastructure, rather than having had to set up, pay for, secure, and maintain my own.

Another benefit of open source is that it’s easier to stand on the shoulders of giants — a phrase that most academics will be familiar with. If a problem you have has already been solved by someone else, it saves you time and the repetition of mistakes if you can re-use their solution. And conversely, if you’ve solved a problem for yourself, you can help others solve it as well. For example, Janeway is a publishing platform used for the Open Library of Humanities, but it can be freely used by others to set up similar Open Access publishing efforts. And because Janeway, in turn, makes use of Django, they can benefit from contributions to that project.

And finally, it paves the way to new innovations. There is no way for a single person to predict all of the potential ways in which software can be made useful (which is why I’m constantly asking for input), so I try to keep an open mind towards others improving upon what I do.

The takeaway

I agree that Open Source is not a requirement for Open Access projects. In the end, we’re in this game primarily to lower the barriers to participation in the scientific process.

That said, it makes for a very good ideological fit. There are many benefits and little to no drawbacks, which makes it a logical choice.

The important thing to consider is that simply dumping code online is not a guarantee for success. As an example, although Wordpress is open source, but a large number of users choose not to install and run it themselves. Instead, they have the company behind Wordpress manage it for them.

I concur with Scholastica that to be successful, projects should focus on working well and being easy to use. Time and time again, this was what set apart the projects that managed to make a difference.

But why not do so in the Open?

Update January 2018

I’ve launched Flockademic, and of course it’s open source. Read all about it, give it a try, and let me know what you think!