Midway through the meeting, just before we took a break, I shifted my role. I believe this phenomenon is common in all policy meetings. You enter as a participant, determined to speak truth to power and to advocate for a better use of technology. At some point, you realized that you have spoken all the truth that the meeting can fathom and so you become an observer. You sit in your chair and try to interpret the signs and symbols in the cross-talk. You examine every little bit of evidence and ask if the discussion will really influence the use of technology.
This meeting dealt with the subject of open source software and involved about a dozen people in total. Half of them were young, energetic policy-makers from the Open Government Project, a small group within the Office of Management and Budget. The remainder of us were software experts, though more than a few seemed to be experts in government procurement of software rather than the software itself.
After a quick round of introductions, we began with a problem. The Open Government Project was drafting a policy to encourage the procurement of open source software. They wanted to know how our communities would respond to such an idea. It was a practical question that called for a practical answer. The response was lively, as almost everyone had some perspective on the question. We offered ideas of our own, and built on the comments of others. In the process, we argued about the issues with open source, and rambled through a couple of examples.
After an hour, we began to repeat ourselves. A few of us realized that we were adding nothing new to the meeting and tried to bring some focus to the conversation. We asked if the representatives of Open Government Project might identify the purpose of their proposed policy. Was it merely an attempt to reduce the costs of software, we asked, or was the project attempting to restructure the nature of government? Instead of answering the question directly, the representatives of the administration said that it was time for us to take a break and that we would address their goals in the second half of the meeting.
By asking for the goals of the project, we were behaving like engineers and we were expecting that the policy-makers would behave like engineers in return. We were trying to build the best solution by identifying the goal and eliminating ideas that did not support that goal. However, policy-makers don’t work that way. In general, policy-makers want to keep open as many options as they possibly can. They don’t want to commit to any idea prematurely if there is any chance that some group might reject or thwart the policy because of that commitment.
When we returned, the conveners launched into another round of questions that sparked a new discussion. When a few of us tried to return to the issue of identifying the purpose of the policy, again, the policy-makers danced on their verbal feet, ducking questions and weaving past ideas in order to keep the conversation moving in a different direction.
By this point, I was firmly an observer and was trying to determine the underlying purpose of the meeting. Furthermore, I had become convinced that the policy-makers were conflating several aspects of open source software. They seemed to be confusing the open source licenses with the organizations that created the software, and they were certainly confusing software development with software configuration.
I know from experience that the technical community places too much value in the power of accurate technical knowledge. Good policy has been built on foundations that contain only the slightest concentrations of accuracy. However, in this case, by misapprehending a key aspect of open source software, the group was missing the transformative power of this kind of software.
Fundamentally, open source software shifts attention from development to configuration, from the process of creating the software to that of customizing the installation for each customer. Ultimately, the most sophisticated open source projects treat software development as a sunk cost and try to minimize that cost by assigning it to a volunteer community. Admittedly, this community is not always a pool of free labor. It is often supported by companies that make their money by installing software, developing configurations for customers, and by training users. In this environment, a single open source project supports many companies that ultimately compete for business.
Of course, many open source projects don’t follow this model. Github is filled with projects that are the product of a single company and are handled by a single team of developers. These projects can be little different from conventional products offered by conventional firms. However, in its best form, open source tries to make software talent more effective by moving expertise from the center to the periphery. It is a new step in a process begun nearly 50 years ago with the start of the software industry.
In the late 1960s, the nascent software industry made technical talent more efficient by creating generic software products that could be used at many sites and by moving away from custom products that were used at a single site. Open source further improves the efficiency of technical talent by opening the development process and using development as a way of pushing expertise closer to the customer of the software.
As our meeting on open source slid towards its conclusion, I tried to return to the role of participant and make a few points about the nature of configuration and the transformative possibilities of open source. By moving expertise to the customer, the open source web development package, WordPress, singlehandedly changed the nature of custom web page design. It gave individuals the chance to control their web presence and ended the reign of the job known as webmaster. The representatives of the Open Government Project acknowledged these ideas, but gave little evidence that they completely grasped their import. We had had a long discussion and everyone needed time to reflect on what we had heard.
The meeting dissolved slowly, though we were pressured by the group that had reserved the conference room for the next time slot. The policy-makers returned to their offices in the White House complex. The rest of us moved into the early evening air. We were participants no longer, just observers. All we could do was wait. Only when the Open Government Project circulated its draft policy would we be able to see what goals policy-makers might have had and what lessons they took from our discussions.
David Alan Grier is a former president of the IEEE Computer Society and writes the column/podcast “Errant Hashtag” for IEEE Computer. He is an associate professor of International Science & Technology Policy at George Washington University.
