Open Advice/Free Software in Public Administrations

Free Software in Public Administrations

by Till Adam

in: Open Advice

This text is available under the CC-BY-SA license. (see also: Open Advice/Info)

Contents 1 Introduction 2 People 3 Priorities 4 Procurement 4.1 Licenses, not Services 4.2 Legal Traps 5 Price 6 Conclusion 7 about the author

Introduction

Like, I imagine, many of the other authors in this collection of essays I started contributing to Free Software when I was a student. I had decided relatively late in life to pursue a degree in Computer Science (having failed to become rich and famous as a musician) and was expecting to be quite a bit older than my peers when I graduated. So I thought it would be good to teach myself programming, which I was not getting much of at school, to become more attractive to future employers, despite my age. After some forays into various smaller communities I eventually found my way into KDE and started working on the email application. Thanks to the extremely helpful and technically brilliant group of people I met there I was able to learn quickly and contribute meaningfully to the code base, getting sucked more and more into both the social circle and the fascinating technical problem space of personal information management.

When KDAB, a company full of KDE people, asked me whether I wanted to help out with some commercial work that was being done, as a student job, I was of course thrilled to be able to combine making a living with my hobby of hacking on KDE software. Over the years I then witnessed the adoption of KDE’s personal information management frameworks and applications by the public sector, particularly in Germany, first hand and saw KDAB’s business in this area grow. As I transitioned into more coordinative roles it eventually became part of my job to effectively sell and deliver services based on Free Software including KDE’s products to large organizations, particularly in the public sector.

It should be noted that much of the project work this text reflects upon was done in cooperation with other Free Software businesses, namely g10code, the maintainers of GNUPG and cryptography specialists, and Intevation, a consultancy focused entirely on Free Software and its strategic challenges and opportunities. Especially Bernhard Reiter, one of Intevation’s founders, was instrumental to the selling and running of many of these projects and whatever morsels of wisdom this text might contain are likely products of his analysis and my many conversations with him over the years.

So if Bernhard and I could travel back in time and share insights with our younger, more naïve selves, what would those insights be? Well, it turns out they all start with the letter ’P’.

People

As things stand today it is still harder for IT operations people and decision makers to use Free Software than it is to use proprietary alternatives. Even in Germany, where Free Software has relatively strong political backing, it is easier and safer to suggest the use of something that is perceived as “industry standard” or “what everyone else does”; proprietary solutions, in other words. Someone who proposes a Free Software solution will likely face opposition by less adventurous (or more short-sighted) colleagues, close scrutiny by superiors, higher expectations with respect to the results and unrealistic budget pressure. It thus requires a special breed of person willing to take personal risks, go out on a limb, potentially jeopardize career progress and fight an uphill battle. This is of course true in any organization, but in a public administration special persistence is required because things move generally more slowly and an inflexible organizational hierarchy and limited career options amplify the issue.

Without an ally on the inside it can be prohibitively difficult to get Free Software options seriously considered. If there is such a person, it is important to support them in their internal struggles as much as possible. This means providing them with timely, reliable and verifiable information about what goes on in the community the organization intends to interface with, including enough detail to provide a full picture but reducing the complexity of the communication and planing chaos that is part of the Free Software way of working, at times, such that it becomes more manageable and less threatening. Honesty and reliability help to build strong relationships with these key people, the basis of longer term success. As their interface to the wondrous and somewhat frightening world of Free Software communities they rely on you to find the paths that will carry them and their organization to their goals and they make decisions largely based on personal trusts. That trust has to be earned and maintained.

In order to achieve this, it is important to focus not only on achieving the technical results of projects, but also keep in mind the broader personal and organizational goals of those one is dealing with. Success or failure of the current project might not depend on whether an agency’s project manager can show off only marginally related functionality to superiors at seemingly random points in the schedule, but whether the next project happens or not might. When you have few friends, helping them be successful is a good investment.

Priorities

As technologists, Free Software people tend to focus on the things that are new, exciting and seemingly important at a technology level. Consequently we put less emphasis on things that are more important in the context of an (often large) public administration. But consider someone wanting to roll out a set of technologies in an organization that intends to stick with it for a long time. Since disruptive change it difficult and expensive, it is far more important to have documentation of the things that will not work, so they can be avoided or worked around, than it is to know that some future version will behave much better. It is unlikely that that new version will ever be practically available to the users currently under consideration, and it is far easier to deal with known issues pro-actively than to be forced to react to surprises. Today’s documented bug is, ironically, often preferable to tomorrow’s fix with unforeseeable side effects.

In a large organization that uses software for a long time, the cost of acquiring the software, be it via licenses or as part of contracted custom development of Free Software, pales in comparison to the cost of maintaining and supporting it. This leads to the thinking that fewer, more stable features, which cause less load on the support organization and are more reliable and less maintenance intensive are better than new, complex and likely less mature bells and whistles.

While both of these sentiments run counter to the instincts of Free Software developers, it is these same aspects that make it very attractive for the public sector to contract the development of Free Software, rather than spending the money on licenses for off-the-shelf products. Starting from a large pool of freely available software, the organization can invest the budgets it has into maturing exactly those parts that are relevant for its own operations. It thus does not have to pay (via license costs) for the development of market driven, fancy features it will not need. By submitting all of that work back upstream into the community, the longer term maintenance of these improvements and of the base software is shared amongst many. Additionally, because all of the improvements become publicly available, other organizations with similar needs can benefit from them with no additional cost, thus maximizing the impact of tax payer money, something any public administration is (or should be) keen to do.

Procurement

So, if it is so clearly better use of IT budgets for government agencies to invest into the improvement of Free Software and into the tailoring of it to its needs, why is it so rarely done? Feature parity for many of the most important kinds of software has long been reached, usability is comparable, robustness and total cost of ownership as well. Mindshare and knowledge are of course still problems, but the key practical obstacle for procurement of Free Software services lies in the legal and administrative conditions under which it must happen. Changing these conditions requires work on a political and lobby level. In the context of an individual project it is rarely possible. Thankfully organizations like the Free Software Foundation Europe and its sister organization in the US are lobbying on our behalf and slowly effecting change. Let’s look at two central, structural problems.

Licenses, not Services

Many IT budgets are structured such that part of the money is set aside for the purchase of new software or the continued payment for the use of software in the form of licenses. Since it was unimaginable to those who structured these budgets that software could ever be anything but a purchasable good, represented by a proprietary license, it is often difficult or impossible for the IT decision makers to spend that same money on services. Managerial accounting will simply not hear of it. This can lead to the unhappy situation that an organization has the will and the money to improve a piece of Free Software to exactly suit its needs, deploy and run it for years and contribute the changes back to community, yet the plan can not go forward unless the whole affair is wrapped in an artificial and unnecessary sale and purchase of an imaginary product based on the Free Software license.

Legal Traps

Contractual frameworks for software providers often assume that whoever signs up to provide the software fully controls all of the involved copyrights, trademarks and patents. The buying organization expects to be indemnified against various risks by the provider. In the case of a company or an individual providing a solution or service based on Free Software that is often impossible since there are other rights holders that can not reasonably be involved in the contractual arrangement. This problem appears most pointedly in the context of software patents. It is practically impossible for a service provider to insure against patent litigation risks which makes it very risky to take on the full responsibility.

Price

Historically, the key selling point of Free Software that has been communicated to the wider public has been its potential to save money. Free Software has indeed made large scale cost saving possible in many organizations and for many years now. The GNU/Linux operating system has spearheaded this development. Because of its free availability for download was perceived in stark contrast to the expensive licenses of its main competitor, Microsoft Windows. For something as widely used and useful as an operating system, the structural cost benefit of development cost put onto many shoulders is undeniable. Unfortunately the expectation that this holds true for all Free Software products has led to the unrealistic view that using it will always, immediately and greatly reduce cost. In our experience, this is not true. As we have seen in earlier sections it does make a lot of sense to get more out of the money spent using Free Software and it is likely that over time and across multiple organizations money can be saved, but for the individual agency looking to deploy a piece of Free Software there will be an upfront investment and cost associated with getting it to the point of maturity and robustness required.

While this seems entirely reasonable to IT operations professionals it is often harder to convince their superiors with budget power of this truth. Especially when potential cost saving has been used as an argument to get Free Software in the door initially it can prove very challenging to effectively manage expectations down the road. The earlier the true cost and nature of the investment is made transparent to decision makers, the more likely they are to commit to it for the long haul. High value for money is still attractive and a software services provider that will not continue to be available because the high price pressure does not yield sufficient economic success is as unattractive in Free Software as it is in proprietary license based business models. It is thus also in the interest of the customers that cost estimations are realistic and the economic conditions of the work being done are sustainable.

Conclusion

Our experience shows that it is possible to convince organizations in the public sector to spend money on Free Software based services. It is an attractive proposition that provides good value and makes political sense. Unfortunately structural barriers still exist, but with the help of pioneers in the public sector they can be worked around. Given sufficient support by us all, those working for Free Software on a political level will eventually overcome them. Honest and clear communication of the technical and economic realities can foster effective partnerships that yield benefits for the Free Software community, the public administrations using the software and those providing them with the necessary services in an economically viable, sustainable way.

about the author

Originally from a liberal arts and music background, Till Adam has spent the last decade or so in software. He works at KDAB where he directs services, including the company’s Free Software activities. Till also serves on the board of directors of Kolab Systems AG, a company with a pure Free Software business model. He lives with his wife and daughter in Berlin.