It may not seem like serious business to you, but for Twitter and other social media companies, emoji -- the cute icons that texters include in their messages -- play an important role. That’s why Twitter has devoted significant developer effort to implementing emoji as well as strategic effort to make the resulting work open source and gain co-developers.
The result is an object lesson on doing open source right in your business.
Expressing emoji
Emoji are like your grandfather’s emoticons on steroids. Text emoticons like the classic smiley :-) are rendered as images. For those who know how to enter them into text, a vast library of emoji is available for many applications.
Emoji are so well established that they can incite social controversy. Why were all emoji of saccharine couples holding hands always heterosexual? Why did all the emoji have white-person skin tones? Those sorts of debates can only pop up once a trend has hit the mainstream and can assume universal implementation.
Emoji arose in the dynamic and quirky Japanese mobile market (the word means “picture letter” in Japanese), and each vendor implemented them independently. Probably treating their implementation as a competitive advantage, each one differed both in the catalog of icons available and the precise syntax for invoking them. That independence contributed to the lack of de facto standardization. Emoji support spread quickly, implemented by companies and individuals outside Japan.
In time, the Unicode standard was extended to include a core set of emoji, offering standardization but no graphics for the commons. Steve Klabnick has more of the story, but in a nutshell, the result was a minefield of tricky rights issues, with implementors “borrowing” icons from others without clear rights to do so. The problem was obvious to many, but each time someone encountered it, they either reused earlier work without permission or created more walled gardens.
Twitter does emoji
For a plump litigation target like Twitter, a clean story on rights ownership is essential. The company's team decided that rather than take risks, it would commission a full set of new emoji graphics. For Twitter's Web clients, the company implemented a library for parsing emoji tags and replacing them with read-to-render code strings for various platforms, including HTML. As a result, you can now add hundreds of emoji to your tweets.
Maintaining that sort of library is much easier if you have help. Twitter partnered with Automattic, the company behind WordPress, and this week went further by making the code and graphics open source (using the MIT license for the code and CC-BY for the graphics). The task was simplified by working internally as if the project was already open source, using GitHub as the development repository (the project is called Twemoji).
Programmers everywhere now have a library for implementing emoji, as well as a standard set of graphics, all with permission granted in advance by use of a very undemanding open source license. The market has a clear core of standard emoji to build on, removing the incentive for vendors to attempt to differentiate on that feature. Twitter has an eager and willing community spontaneously forming to maintain their code for them. More subtle but equally as important, Twitter and WordPress have both built their credibility and influence in the open source community – its primary currency.
Lessons learned
Twitter has managed to implement a feature essential for its global market, get it maintained in conjunction with others, and win broad credit. This is a win for everyone – one you can replicate with smart open source strategies for your noncore code.
- Don’t make it yourself if it already exists. Improve what’s already out there and start from scratch only if you face insurmountable problems (probably related to rights ownership). Even then, build with existing open source parts as much as possible and contribute upstream to each project.
- Assume every project you start will end up open source. Use tools, communication strategies, and internal governance as if the project was already open.
- Make sure everything you add to your project has known provenance and can have an open source license applied to it when the time comes.
- Find likely external community members and approach them so that there’s already critical mass when you go public.
- Go public as soon as you can. The longer you leave it, the harder it gets.