8 Lessons Learned From Open Source Development

When Harvard kicked off OpenScholar six years ago, little did it realize the impact the website creation project would have on the university — and the academic world at large.

• By Dian Schaffhauser
• 01/12/17

Each website built on OpenScholar has the same underlying infrastructure, but can be customized with its own look and feel.

The story of the creation of OpenScholar would be familiar to anybody who's ever tried to fix a specific problem by addressing the broader underlying need. Gary King, director of Harvard's Institute for Quantitative Social Science, would get requests from faculty and staff for help to build websites, which would end up costing thousands of dollars—"sort of ridiculous," he said.

So members of King's team began studying scholarly websites. What they learned was that the websites were "structurally identical," even if they did have unique looks. "They all have a CV; they all have a list of classes; they have a list of papers; they have a picture and a bio. They're all exactly the same," King explained. Yet every faculty member would want his or her own look and feel, graphic design and URL.

At the same time, he noted, website proposals from outside companies would describe how the project would require building "the entire stack, from the hardware to the operating system to the content management system all the way on up to the graphic design." And every "slice" in that stack "was identical for everybody."

That's when it struck the team: Why not build one system that had the same set of website operations for everybody, but would allow each faculty member to overlay a different graphic design like a "veneer"? That approach would allow people to gain their customized looks while allowing IQSS to save a fortune, said King.

When the application was done, IQSS also realized it could work across the whole university, "or pretty much all of academia," King recalled. And just like that, OpenScholar was made available for free to any Harvard department, center, academic project and group on campus. It has served a diverse array of website needs, such as the university police department, the Harvard-Radcliffe Choruses and the soft robotics toolkit project.

The endeavor has created "well more than $100 million in value" for the university, according to King. And because OpenScholar also has been picked up by other institutions too — among them, Princeton, the University of California, Berkeley, the University of Massachusetts Amherst and the University of Waterloo — the value-add just keeps growing.

Keep Track of the Momentum

King's $100 million estimate of OpenScholar's value may seem pie-in-the-sky, but he is quite clear about how he calculated that amount.

OpenScholar shares its metrics, which are updated in near real time. If you go to the website home page, you can view continually changing counts of how many sites have been created that day and how many active websites are online in total, among many other numbers. For example, as of Jan. 12, a total of 7,287 websites were fully running on OpenScholar — for free. (That total doesn't include those sites built and abandoned for the purpose of experimentation.)

King contrasts that with the typical cost of a hiring a third-party firm to build those websites. "Web development firms still come to our door, and they still say, 'Hey, let's sell us your services,' and we still see these proposals for $200,000 or $300,000,'" he noted. So the team compiled a list of web development firms pitching to the university and called them to find out their pricing for creating "the least expensive" versions of the websites being developed with OpenScholar. "Then we just multiplied [that] by how many we created ourselves."

King won't say that OpenScholar has saved the university that much money, because some of those websites may never have been created in the first place. Still, use of the platform has propagated in unexpected ways. Early in the introduction of OpenScholar, King's team would work with various faculty members, staff and project coordinators to set up the sites. "We allocated money so we could create 10 sites over the next two months," he recalled. What ended up happening was that "various student organizations got together and created the most beautiful sites that were far better than the ones our staff was creating. And they'd do it overnight without speaking to anyone."

Reach Out for Help

Like many universities, Harvard is highly decentralized. By the time OpenScholar launched, numerous departments and projects had set up websites, thereby individually forming the "public face" of the institution in dozens and dozens of guises. The result, according to King, was an ecosystem that was "completely incoherent. You didn't know when you were on a Harvard website."

To remedy that, IQSS quickly brought in the Harvard University IT organization, HUIT, as well as the university's Public Affairs and Communications department, to create a cross-departmental team focused on digital communication, web development and service delivery.

Harvard Web Publishing, as it's known, now operates OpenScholar and also works with institutional clients to develop or redesign websites. The communications group oversees style standards, such as making sure the distinctive Harvard crimson is coherent across websites. IT figures out the infrastructure aspects, such as where to host the sites, which currently lay claim to about 235 gigabytes of disk space.

Pursue Simplicity (It's Difficult)

OpenScholar provides a collection of default or "pre-set" website structures for different purposes — labs and research groups, projects and centers, administrative departments and so on — that are themselves customized through "themes" and the use of widgets to define color sets, layout and functionality. The upshot is that people don't have to know programming to work with OpenScholar. They go in and fill out forms and pick choices from menus. "What you see is what you get, basically," said King.

But the site also offers a lot of documentation — an almost overwhelming amount, King admitted, suggesting that he'd like the technology "to be like a refrigerator. You plug the darn thing in and you use it." Then again, he noted, "Your refrigerator is solving a task that is massively simpler than a faculty website." That means the user has more to learn. "But we're working really hard on making it so [that] on more and more parts you don't ever need to go read the documentation."

"Open" Means Total Transparency

While IQSS still oversees development of OpenScholar, King emphasized that oversight doesn't equate to control. "It's not really control," he said. "We're all trying to achieve the same thing."

As an open source project, OpenScholar also needs to accommodate the input and influence of all the other stakeholders, including other universities that have chosen to adopt the application for their own purposes.

Facilitating decision-making and maintaining a reputation for openness takes a two-prong approach. First, OpenScholar tries to "make all of our processes and decisions completely open," said King. It publishes a publicly available roadmap that shares new features, bug fixes and current initiatives.

Second, it runs a community site that allows people to vote ideas under consideration up or down. Visitors can view the voting of a given item by community member and even drill into a change log to see when and why a given vote may have been changed.

People at outside universities "can't call us and say, 'You have to do this,' because we don't work for them. But they can ask," noted King. "And it's great when they do because they often have great suggestions."

Minimize Disputes but Don't Bury Them

Because OpenScholar is backed by Harvard's money, internal users need to have a say too, said King. "How do you manage all these people to do different things? We make everything completely visible." Then users can drill down into the roadmap and figure out what constraints the development team is under. "If they have suggestions at that point and they've figured out that all the detail stuff, and they tell us that in their considered opinion we should do this thing rather than that thing, fine, we'll probably do it."

More importantly, however, the roadmap and community processes encourage people to trust the OpenScholar team, said King. "We all want the same great product. It's a much better approach than keeping everything secret."

When hard decisions need to be made that might "get people upset," there's no governance council or stakeholder vote that takes place. It comes down to the human element, and particularly King himself. "That's my job," he acknowledged. "If the faculty member wants to have a big screaming match, that's fine. I go visit them."

Although the roadmap minimizes the fighting, it doesn't eliminate the feature begging altogether. In those situations where "people really want something," King added, "We have to see how many people will that improve the lives of and what other things we have going on."

Protect the Dev Team

Within the development team, King makes sure that openness on the feature set doesn't turn into a hamster wheel of never-ending deadlines for his coders.

"The usual strategy in universities is to keep your budget secret and what you're going to do secret. Then, of course, you wouldn't give a plan for development, because if there's a plan, then there's a deadline. And if there's a deadline, you might not meet it. And if you don't meet it, then you could get embarrassed. You might lose budget," he explained. "So I tell the team, 'That's OK. Sometimes people don't make their deadlines. It's not going to be a deadline anyway. It's going to be a goal. And if you can't make the goal, that's going to be for some reason. We're going to deal with the reason. But we're going to make it open.'"

It took a long time before the staff believed him. "I explained that it's actually in their interest. They will have more latitude to make rational decisions rather than furiously running around trying to deal with some screaming client. It seems to actually work pretty well."

Distinguish Change by Impact

OpenScholar, built on Drupal, includes all the bells and whistles of a website: search, custom domains, the ability to add apps and widgets, social media integration, built-in site analytics, drag-and-drop layout. Since every site is unique in some regard, changes to the underlying components could have dramatic impact on the public-facing sites — or not.

Handling changes is a balancing act with several maneuvers. Some types of changes affect aspects behind the scenes in the administrative operations, such as what editor is being used by the website creator to type in and manipulate text.

Other changes affect some small aspect of the website for the greater good, such as upping the resolution of the icon representing a PDF file. That kind of change was made by the development team and rippled throughout all of the sites. "If you didn't really want that, that's a bummer," said King, not at all sounding like he'd lose sleep over it.

A third category affects website behavior or appearance, and those types of changes are strictly opt-in. For example, a new feature will be created that allows the website author to download citations from a bibliography in different formats. "If you don't want that, don't add it. That's fine," said King. "But if you want it, it's now available."

Push for Openness to Promote Quality

When the OpenScholar group decided to make the code available to other institutions, there was a bit of resistance among some members of the development team. After all, now other people would be looking at the code and, presumably, judging its quality for themselves.

"I pushed them on that very hard," King stated. The reason: He believed the development process would be improved. "If you make it open source and other people are going to look at it, then you're going to make it better. You're going to document things. You're not going to put bugs out there because you know they're going to call you. You're going to ruin your day if there's something out there that doesn't work. By giving things away it actually raises the standards."

Besides, King noted, by allowing as many people as possible to set up their own websites, the mission of the university — and all universities — is being served. "The purpose of the university, in a sense, is the creation, preservation and distribution of knowledge," he noted. "What better way in the modern era to distribute knowledge than to have a website? What better way to preserve it than to make it public? And what better way to create knowledge than by distributing the results of your prior work and interacting with the people who see it?"

King still hears about vendor proposals to build institutional websites that come in at several hundred thousand dollars. Because Harvard is a highly decentralized university that's well funded, he pointed out, people may go third-party "out of ignorance." But, he asserted, "It's a stupid thing to do. You're literally wasting money."

When he finds out there's a proposal on the table, he'll kick into action and make his own pitch: "Hey, if you want to do this, that's fine. However, there's another way. And by the way it's free." Typically, he added, "They'll keep their $250,000."