No doubt, Open Source is essentially an international business. Open Source vendors who solely focus on one region that might not even be an English-speaking one, will struggle. They will be forced off the road by competitors with an international focus who benefit from economies and communities of scale.
Being an international company does not mean that English is supposed to be the only language throughout your business. It rather means that picking the right language is critical to reaching your target audience. Of course, your target audience and regions depend on your business goals.
International Mindset
First of all, Open Source vendors should always adopt an international mindset, no matter where they are located. One major business goal for them is to reach maximum product distribution and adoption on a global scale through community development efforts, marketing, PR, etc. It’s a prerequisite for effective Open Source sales. Someone in Brazil will very unlikely try out your software if all relevant information is available in French only. Even less likely will someone in Brazil buy 24/7 support in French (unless it is a French corporation with subsidiaries in Brazil). English is the lingua franca to reach a global audience.
Businesses starting in the U.S., can much easier communicate to an international audience because English is not an issue for most employees. Quite the opposite for companies headquartered for example in France, Spain or Germany. If an international focus is not in their genes, they will have to change corporate culture and communications accordingly to adopt an international mindset. One major drawback for them is: They might be very successful in their home territory – so why think global? On the other hand, U.S.-based Open Source vendors should never underestimate the importance of setting up a subsidiary speaking a region’s language, especially in marketing, sales and support.
The tricky issue is to draw a line between international and regional communications within all communication channels.
Core Software Development
Core software development should always communicate in English externally. The reason being that the benefits of Open Source as the best software development model can only be fully leveraged by attracting a global developer community. Not only does this increase the likelihood of third-party bug reports, patches and code contributions. It also allows a vendor to recruit the best people from the community. That’s how MySQL was able to steadily grow a team of excellent software developers who themselves live and breath Open Source. Most likely, your core team will already converse in English internally anyway, because today’s development teams are spread across the globe with units in Bangalore, Russia or other places where labor costs are relatively low (could also be Finnish companies outsourcing to Germany). English is not an issue for programmers, at least to read and understand it.
Community Development
The primary language of Community Development is English. You want to attract some enthusiastic community members from various regions who can easily read and write English. They will act as multipliers and spread the word into their home region by speaking the local language. Such early adopters will also contribute by enhancing international community assets (e.g. maintain the community Wiki, moderate forums, etc.).
Life is not that easy though. As I have written in a comment to a previous post:
You might have a strong community in Germany for example, but of course want bugs to be reported in English to be useful for your development staff and your international developers community. There might be people within your German community who feel uncomfortable writing in English. Here again, you need to invest time and e.g. ask them to first post the bug in a German-speaking forum so that you can translate it and turn it into an English bug report. Later, there might be community members who can help you with that.
Communication Channels
Roughly speaking, the following communication channels, collateral, etc. should focus on an international and/or regional audience:
- developer mailing list: international
- bug tracker: international
- feature requests: international
- documentation and tutorials: international
- release notes: international
- Twitter: international and optionally regional
- Weblog: international and optionally regional
- Forums: international and optionally regional
- … you get the idea.
PlanetMySQL Voting:
Vote UP /
Vote DOWN
DIGITAL JUICE
No comments:
Post a Comment
Thank's!