451 CAOS Theory 
A blog for the enterprise open source community
Open source – the ultimate globalization tool
Jay Lyman, December 12, 2008 @ 3:25 pm ETI’ve been hearing a lot from open source software vendors about internationalization and more specifically, localization of their software by, logically, local community members and contributors that take the code and run with it in Japanese, Russian, Spanish and a variety of other languages in places all over the globe.
I think there is a good degree of recognition that open source gives a project or organization an instant global reach given developers and users from anywhere in the world can get involved using the Internet. What may be less obvious is the trust that a project or organization can gain with a locale and community that is a world away, but is at the same time welcomed and empowered by the Internet and free and open source software. With open source, foreign communities are not limited to the code and licensing provided by the vendor, which if it is a U.S.-based vendor, will likely encounter skepticism or disdain. With open source, the code is available and those foreign communities are able to participate and to prove their market viability, which typically leads to further partnership and investment from the vendor.
One example is GroundWork, which recently saw a community form around its open source systems management and monitoring software in Japan. GroundWork is now working with partners Fujitsu and Praesentia to offer both its Community and supported Professional version software in Japan, complete with local UI, Japanese documentation, Japanese version of Nagios and local support. As we cover in a recent report, this is an increasingly common example of enterprise expansion through open source without any additional investment up front.
Movial, a Finnish mobile device development vendor focused on mobile Linux and open source, is an interesting example of a non-U.S. company that stresses the ability of open source to deliver international reach. Essentially, once you are open source, you are global by nature, as Movial sees it. Given the potential for developer and community participation from literally anywhere there is Internet access, as well as the increasing trend of vendor investment and involvement in those foreign communities and markets, it’s hard to argue against that. Movial also cites a cross-border trust that is inherent in open source, but often lacking in proprietary software.
Another good example of open source’s internationalization powers came out of a recent discussion with Fedora Project Leader Paul Frields, who highlighted the increasing number of languages and localities supported in the Linux distribution. Frields reported that while there were only two or three languages supported in Fedora Core 4 a few years ago, the latest Fedora 10 supports 16 languages. Further reinforcing that, Frields said the foreign ‘ambassador roles’ working to follow up on foreign participation is more than doubling every year and is now at about 600.
It’s clear that open source delivers significant advantages when considered from a global market perspective, but it is also worth noting that vendors may be able to shed negative image or national biases or resentments through open source software, something the proprietary model cannot easily match, particularly without significant investment.
Comments (13) Categories: Software
I agree with many of your points Jay. Whether you are an organic open source project or a commercial open source vendor the open source distribution model enables participation from geographies and locales that are not possible any other way.
For instance at Pentaho we have registered community members in over 150 countries. By contrast most proprietary BI vendors have operations in 20 or so countries. Pentaho (the commercial entity) has no expectation that we will ever sell products or services into most of these countries. However Pentaho (the software) gains from the use-cases and feedback that we get from these community members.
It does take a small amount of investment and trust on behalf of the project to enable this participation. For example your forum / wiki software might need an upgrade or patch (or replacement) to be fully compliant with the requirements of double byte languages.
James
Thanks for posting, James. Good point on the investment AND trust required from the project/vendor in their response to this grassroots globalization.
JL
[...] Open source – the ultimate globalization tool [...]
Jay, I don’t believe software has a nationality. And the concept of a “U.S.-based vendor” of software is meaningful only to tax accountants and immigration lawyers.
But just for the sake of discussion, why not publish your list of disdained American software.
I don’t find anything in open source terms and conditions and the open source development culture that differ from conventionally licensed and developed software from a “global market perspective.” The Fujitsu/Groundwork deal is no different than a hundred other Fujitsu partnerships and Red Hat making a “significant investment” on localization is no different than IBM or Oracle making such investments.
Dennis
Hi Dennis,
The concept of a “U.S.-based vendor” of software might be meaningless if you are in the US, but it means a huge amount if you are trying to get a business up and running in, for example, Eastern Europe. In that position would you rather feed off the scraps left by the dominant US vendors or try and build expertise based around open source software?
Some will choose the former – that is where the volume is after all, but others will choose the latter based on their ability to engage in the collaborative process and attempt to build a sustainable local economy. Those that choose the latter option are being actively supported by the EC and, in many countries, their national and regional government.
When software is tied to a vendor it does have a nationality in the eyes of many users. The fact that the code is open helps to break down the boundaries. In fact this is one of the few areas in which the open source development and distribution model does make a difference, in my opinion.
Hi Denis,
Thanks for posting. I think Matt summarizes pretty well the way I meant that traditional software and its vendors DO have nationality, particularly outside of their nation of origin. Open source, which is an enabler for local communities and businesses, does not have as much of a ‘country of origin’ since the code is developed and used by people all over the world, including in your town.
I’d also like to make the point that from a sheer economic/business perspective, a proprietary vendor must research and invest where in the world its greatest international opportunities are if it wants to grow a presence or revenue there. Open source vendors, by contrast, are told which international opportunities are greatest by their presence and participation and then given the option of following up on development and use in a particular locale, all for absolutely zero investment (other than making the code available as open source). It may sound too good to be true, but it is the effect of open source software development and distribution when it is working properly.
JL
The usability of software depends on usability and the combination Internationalisation/Localisation. A lack of primary usability kills off potential buy in from people new to your environment. When software of documentation for that matter has not been localised, you will lose a percentage of buy in even when one of the supported languages is known.
In order to localise, you have to be well grounded in Iternationalisation. It is only by experience that you learn that Welsh for instance has six forms of plural, that gender is not just male, female none of your business.
Betawiki is the project where the MediaWiki localisation is done. It aims to support over 300 languages and the quality of many localisations is also reflected in the viability of the projects in that language. Betawiki is slowly but surely growing the number of applications it supports.
What makes Betawiki special is that it actively grows its community and this benefits the projects that are new to Betawiki. It is cooperation that benefits all.
Thanks.
GerardM
[...] Read more at 451 CAOS Theory [...]
Do you have recommendations for specific software libraries and coding best practices to help open source projects be localized? I’m not talking about general principles, I’m talking about specific coding practices and routines that are widely usable. Thanks.
Bob
Hello Bob,
Sorry for the delay in response, but I passed your query onto Fedora’s Paul Frields, with whom I discussed this topic recently. Here’s his detailed response. Thanks for the question, and thanks again to Paul for his input:
“The venerable but incredibly widely-used GNU gettext libraries provide
internationalization and localization (i18n and l10n) capabilities for
a wide variety of software:
http://www.gnu.org/software/gettext/
Originally written for C, they have since been ported to a wide
variety of other languages, including C++, Perl, Python, Ruby, OCaml,
and so forth. Programmers can use a simple syntax for marking strings
of text in programs, or use any of a number of utilities freely
available for detecting strings of text in regular markup such as
XML.
Since we write a lot of documentation in XML formats, and produce a
lot of code in languages that have gettext support, it’s very easy to
produce translatable content. The procedures for doing so are fairly
standard, and typically programmers simply use the conventions long
established in the open source community. By way of example, the vast
majority of programmers use a “_” marker to establish translatable
content in a number of languages and content dialects.”
Paul also writes about an example using Python, and refers to a tool for file distribution and translation:
“Not to get too technical, but for instance, in a Python program I
would have something like this:
= = = = =
import gettext
_ = lambda x: gettext.ldgettext(“anaconda”, x)
# … blah blah, more code here …
mymsg = _(‘This string will be extracted for translation.’)
print mymsg
# … blah blah, more code here …
= = = = =
The gettext library transfers these strings into a specially formatted
file that can be distributed to translators or teams. The translators
can use any of a wide variety of tools to translate the strings of
text into their native language, and resubmit them to the project
developers for inclusion in the official release.
There are now also a number of tools that offer web-based distribution
of translation files, and/or web-based interfaces for actually doing
translation through a browser. One example is Transifex:
http://transifex.org/
The Fedora Project uses this specific capability to provide
translations for those codebases for which we are the upstream, such
as hosted projects originating with our contributors and our
distribution-specific system configuration tools.”
[...] also previously discussed how open source software development and business only perpetuates the global nature of the Internet and participation and collaboration from all around the world. [...]
Also previously discussed how open source software development and business only perpetuates the global nature of the Internet and participation and collaboration from all around the world..
Hi Dennis,
The concept of a “U.S.-based vendor” of software might be meaningless if you are in the US, but it means a huge amount if you are trying to get a business up and running in, for example, Eastern Europe. In that position would you rather feed off the scraps left by the dominant US vendors or try and build expertise based around open source software?
Some will choose the former – that is where the volume is after all, but others will choose the latter based on their ability to engage in the collaborative process and attempt to build a sustainable local economy. Those that choose the latter option are being actively supported by the EC and, in many countries, their national and regional government.
have a nice day.