Adobe's open source font experience

The fifteenth annual TypeCon conference was held in Portland, Oregon on August 21–25, featuring a mix of session topics that encompassed type design, letterpress printing, and modern font software. Open source and open font licensing have become hot topics in recent years—largely due to the rise of CSS web fonts. But the signs are that open source is gaining even broader acceptance, as evidenced by Paul Hunt and Miguel Sousa's presentation on the Adobe Source Sans Pro and Source Code Pro fonts—and the ripple effects they triggered within the company.

Hunt and Sousa are both part of Adobe's Type Team, which produces both software tools and typefaces. Historically, both categories of work have been proprietary, which is part of what made the 2012 debut of its open font families significant. The pair spoke about the development of the project, from the company's internal motivations to how interacting with the community affected the team's workflow and technical decisions.

After giving a general overview of open source concepts and development processes, Hunt discussed the decision to create an open font in the first place. The company is a type foundry (selling its own fonts), and it runs the web font subscription service TypeKit. But, as Hunt explained it, Adobe created the Source Sans Pro font because the company has been developing more open source software in recent years, and it needed fonts that it could incorporate into its releases. In fact, he said, Source Sans Pro was first used in Strobe Media Playback, an open source web video-player project. Since then, the fonts have also been central to Adobe's Brackets, an open source, browser-based HTML editor, and have been deployed in several other projects.

Initially, Hunt said, the company had considered taking one of its existing commercial typefaces and releasing it under open source terms, but the team eventually decided to create something new. Source Sans Pro was inspired by Morris Fuller Benton's venerable News Gothic and several of its contemporaries, he said, and was optimized to be used in software user interfaces, while still being readable in long blocks on continuous text. The initial release was made in early August 2012, in 12 styles across six weights. In September, a second typeface was added: Source Code Pro, which is a monospaced font family designed for use in coding.

Tooling and retooling

As Sousa explained, the fonts were developed in the (proprietary) FontLab Studio font editor, using Adobe's Multiple Master format (which greatly simplifies adding new font weights), and built with the help of Adobe Font Development Kit for OpenType (AFDKO), which is a suite of scripts and command-line utilities. Internally, the team managed the font sources with the company installation of the Perforce revision control system.

The team initially released the fonts on its SourceForge.net page, providing TrueType and OpenType binaries plus the FontLab Studio source files, together in one downloadable .ZIP archive. The fonts were also made available through a number of font services, including TypeKit and Google Fonts. The reaction was overwhelmingly positive; Hunt commented that the release announcement remains the most-viewed post on the team's blog to this day, and there were a number of stories about the project in the general tech press.

Users even began reporting bugs quite early on in the process. But there were other comments, too—most notably criticism of the location and structure of the releases themselves. Or, as Hunt put it, there were comments of the form "you fools; open source development takes place on GitHub." But that characterization was tongue-in-cheek; such comments were not reprimands, but encouragements. One cited the benefits of moving to GitHub: attracting new users who would report bugs, public forks that tested outside contributions, and the ability to accept or deny pull requests from outsiders.

Those benefits evidently sounded good to the team, because it did indeed migrate from .ZIP file releases on SourceForge.net to a fully hosted repository on GitHub. It took a bit of time to get used to Git's syntax and its differences from Perforce, but the team soon found Git more useful. In addition, because FontLab Studio's native source file format is closed and binary, the team also switched over to using the XML-based Unified Font Object (UFO) format. The text-based nature of UFO worked better with Git, but it also made the sources editable by a wide variety of applications and third-party scripts.

In short order, the team discovered several side benefits to the new workflow. Not only was UFO's format better suited to GitHub's revision control, but its human-readability made visual inspection of changes simple. Likewise, although the team was already well versed in version control, Hunt said that the distributed nature of Git made collaboration much easier—between internal team members as well as with the community. Reports also came in that seeing the document hierarchy in public proved educational for users and contributors, both for how the fonts were designed and for how AFDKO is used.

Contributions

Hunt and Sousa then discussed several types of feedback they had seen from the public project. There were bug reports—including requests for additional character sets—changes to glyphs, comments, and everything down to simple "+1"s, which Hunt told the audience were the least helpful type of feedback. Hunt said that the team had anticipated a significant number of design contributions, based on what the community had said about moving to GitHub, but in reality there have been very few. He chalked this up to a number of factors, starting with the small number of people working in type design, but also including the difficulty of rebuilding and testing fonts. He also speculated that there might be a lot of people who would be interested in contributing but do not know where to begin, and encouraged the open source font community to help educate people.

But there have been other forms of contribution, he said. Logos Bible Software commissioned the addition of small capitals, subscripts, and superscripts to Source Sans Pro. There have also been significantly more bug reports and feedback comments on the open source typefaces than on Adobe's commercial offerings, which Hunt said has led to improvements in the commercial products as well. But perhaps the most fundamental change to come from the project was the rethinking of the font development workflow and toolchain, he said. The team has become more transparent and collaborative in all of its projects, both internal and external. And it has continued to use Git for version control, both on its open source and its proprietary projects.

Sousa and Hunt ended the talk by encouraging everyone to contribute to the fonts. "Although these were started by Adobe, they belong to the community." In the Q&A period, an audience member asked what contributions would be the best to work on; Hunt replied that anything was welcome—there is a roadmap, including several new character sets, but all improvements benefit everyone. Indeed, in one particularly amusing example (perhaps because it incorporated a considerable amount of ASCII art), fellow Adobe employee Frank Grießhammer set out to add the Unicode box-drawing characters to the fonts, an effort about which he delivered his own rather detailed talk later in the conference.

Another audience member asked what the Adobe open font project had learned that had not already been proven by Google Fonts. Hunt responded that the primary drawback of Google Fonts is that it only provides downloadable products. One can get the source files, but the service is not set up to contribute back or collaborate. The same audience member also asked if the team's experience with open source development meant that AFDKO would be released as open source. Sousa replied that they were working toward that goal, but that they still had more internal work to do before an open source release could be made. However, he also commented that AFDKO is free to download and use, and hoped that people would not let the EULA be an excuse to not get involved.

To longtime free software supporters, some of the Adobe Type Team's observations about open source development will come as no surprise. Nevertheless, it was still refreshing to see that the company was willing to listen to the feedback of community members, even in the project's earliest days and even when that feedback recommended a nearly complete overhaul of the project's tool set and workflow. After all, one does not need to look very hard to find examples of proprietary software vendors announcing that they will do open source their way whether the community likes it or not. Those companies usually reap frustration and disappointment, whereas the Adobe Type Team not only found a good user community, but several beneficial changes it can incorporate into its other projects as well.