Method 3: Single Worldwide Source

Single worldwide source products have no code forks. One product group develops a single source for all anticipated targets.

Advantages of single worldwide source are as follows:

• The binary size can be optimized for major language regions without resorting to completely separate teams and separate source. Code that is not required by all users is conditionally compiled out based on geographic target.

• You have less duplication of headcount by having one group accountable for worldwide-enabled product.

• The single-source model works well with some localization tools. The assumption is that code should not need to be retouched for a UI language.

• Testing for functionality that is unaffected by #ifdef branches can be combined into one team. Those bugs can be reported and fixed once.

• Ship deltas are reduced to time lag for actual translation instead of engineering delay.

Single worldwide source has disadvantages, also:

• Maintenance of #ifdefs can get messy, especially with complex or text-intensive products.

• You need to test separately for the consequence of each #ifdef. You could manage this as one team, but often this becomes a reason to continue maintaining separate testing staff. Anytime international testing is separated, bugs run a risk of missing core code.

• Resulting product SKUs are still geographically dependent, just as with other approaches listed earlier. You still need headcount to manage separate product delivery for each target locale. The original engineering team might never see or care about the resulting international product.

• File format interoperability still is probably not thought through. The international "split" has been moved out into or beyond the compile step, but it is still a split. Explosive growth in the Internet accelerates users' expectation of language interoperability.

Although single worldwide source is better than the first two methods, it can be troublesome because your code is difficult to manage.