From the beginning, it was clear that the CUNY Academic Commons would be built on free software. For reasons both practical and ideological, the WordPress, BuddyPress, and MediaWiki platforms were the right fit for an upstart project aimed at connecting people across the campuses of CUNY. The Commons is not unusual in this respect; universities and other non-profit organizations often turn to free software when they’re looking for tools that are flexible, economical, and respectful of the local control over content that their core missions require.
The Commons is unusual in that it quickly moved beyond being a mere user of free software, and into being a creator of free software. The move is important because of what it means not just for the Commons, but for CUNY and for universities more generally.
First, a few words on “free software”. In English, the word ‘free’ is ambiguous between at least two meanings. There’s ‘free’ as in free beer, which is beer you didn’t have to pay for (gratis). And there’s ‘free’ as in free speech, which is speech that is (within certain parameters) unrestricted (libre). Free software is free in the latter sense. The software in use on the Commons is available under the GNU General Public Licence, or GPL. The GPL is explicitly unconcerned with cost; software need not be gratis to meet its definition of ‘free’. Instead, the focus is on user freedom, the idea that the creators of a piece of software should not be able to dictate how the software is used or modified. You can read much more about this conception of free software at the Free Software Foundation’s Free Software Definition.
A byproduct of the libre notion of freedom, and in particular the user’s freedom to modify the software as she sees fit, is that free software must also be open source – that is, each distributed copy of the software must be accompanied by the source code, so that users can see how the software works, and change it as they please. This inherent “hackability” was the catalyst for the Commons to become involved for the first time in free software development. We had a specific need (in our case, to customize the way that BuddyPress profile fields turn into links), and the open, extensible nature of BP allowed us to fulfill the need with a custom plugin.
The practical benefit of using hackable software drove our initial forays into free software development, and has continued to motivate us as we’ve developed dozens more plugins over the last few years. But practical benefits are not the end of the story. Our team has consistently made a point of not keeping our customizations to ourselves. We took the extra time to package our work in such a way that it could be used by others. We shared our WordPress plugins in the official repository. We contributed back to the parent projects. And we wrote frequently about our work, in a place where we knew others would find it.
This kind of very intentional sharing is not free (as in beer); writing software that is usable by others, releasing it, supporting it, writing about it – all of these things require a considerable devotion of resources beyond what it would take to keep our bespoke development to ourselves. From a purely practical point of view, though, the initial outlay of dev resources has been returned many times over. For one thing, being publicly involved means having a say in the trajectory of the larger software projects that we depend on here at the Commons. There have been indirect benefits, too. The public nature of our work has given us a reputation that appeals to our funders, both actual and potential, helping to ensure a bright future for the project.
But even more important than the practical benefits of free software development are the philosophical motivators. Much like the Commons itself – with its goal of challenging traditional distinctions between public and private, professional and social, work and play – the Commons dev process is all about rethinking boundaries. In our case, our focus has been on the role of software development within the academic enterprise. There is a de facto division on college campuses between those who write and control software (a power generally seated in IT departments) and those who use the software (the academic community at large). The Commons model of open, iterative development, driven and carried out in a collective fashion by faculty members, graduate students, staff, and outside consultants, points to a more integrated approach, where users and developers are on an unbroken continuum rather than separated by physical and bureaucratic walls.
Rethinking the distinctions between software use and development, through the lens of free software, is more than just a rhetorical move; it’s central to the work that we do on the Commons, and in the public university. The software that we use shapes the way we interact with each other and with our work. In this way, taking control of our software – by choosing to use free tools, and choosing to play an active role in the way those tools are developed – is a crucial step toward establishing a broader kind of freedom in our community. CUNY is publicly funded and is charged with helping to shape the next generation of citizens of New York City. It is right, then, that the tools we use, and the way we engage with the tools, should foster the kind of agency that is required for true citizenship. What’s more, the fact that we are able to contribute, in our small way, to providing free, flexible, powerful tools for everyone – not just members of the CUNY community – is of a piece with our mission to engage meaningfully with a larger public.