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 non core 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.
Hello, my name is Mohd Azahar. I'm a self-employed Pivrate from the India.
No comments:
Post a Comment