Overcoming Challenges in the Development of the Java Desktop System (JDS)

1. Challenges Encountered & Solutions Adopted in Developing the JDS • Damien Donlon • Software Engineer • Sun Microsystems Inc.

2. The Java Desktop System (JDS) An Enterprise Desktop based fundamentally on Open Source Software Components written in Java, C, C++ Supported Languages : de es fr it sv ja ko zh_CN zh_TW pt_BR Open Source Components include : Linux Gnome Desktop Evolution Mozilla Web Browser

3. Open Source : Cost of AcquisitionThe Only Consideration? It was a consideration! Millions of lines of free code! A sizable community of actively engaged and expert developers. Over 120 separate applications & libraries Language teams engaged in translation for over 60 languages UI translation completeness sometimes approaching 99% for some languages!

4. Available Source Code != Open Source Under the Open Source Definition, licenses must meet ten conditions in order to be considered open source licenses: 1. Free Redistribution: the software can be freely given away or sold. 2. Source Code: the source code must either be included or freely obtainable. 3. Derived Works: redistribution of modifications must be allowed. 4. Integrity of The Author's Source Code: licenses may require that modifications are redistributed only as patches. 5. No Discrimination Against Persons or Groups: no-one can be locked out. 6. No Discrimination Against Fields of Endeavor: commercial users cannot be excluded. 7. Distribution of License: rights must apply to everyone who receives the program. 8. License Must Not Be Specific to a Product: the program cannot be licensed only as part of a larger distribution. 9. License Must Not Restrict Other Software: the license cannot insist that any other software it is distributed with must also be open source. 10. License Must Be Technology-Neutral: no click-wrap licenses or other medium-specific ways of accepting the license must be required.

5. Open Source Cost of Acquisition :The Only Consideration? At your peril! • Open Source requires a different business and engineering model of a company. • So many other considerations it is difficult to spot them all at the outset. • Solution : Don't expect to! Adaptability & flexibility has to become a part of your mindset. • It can all seem a bit chaotic but it isn't. • You often don't understand a problem until after the first time you implement a solution.

6. Consideration 1 : Is it end-to-end Open Source? Some examples : • Unisys patent on LZW expired in the USA June 2003. Some outside USA will not expire until 2004. • Open Source DVD players & DeCSS decoder. • MP3 : A license is needed for making available revenue generating content encoded in mp3 format or for applications supporting the format. Redhat Fedora – no mp3 codec in XMMS • KDE, the QT Library & Trolltech • SCO versus IBM! I couldn't possibly comment.

7. Open Source : A Fast Moving Train • The Train Model & it's Implications • Applications Maturity. Ready for primetime? • Things can change really fast. How will my customers keep up? • “Everything & the Kitchen Sink”. Do our customers really need 6 different editors and 3 web browsers? • You didn't meet the build deadline? Tough!

8. How to safely get on and off a Fast Moving Train – The JDS • Building to the CVS HEAD : • Probably not a good idea if you need enterprise ready stability and completeness. • No guarantees your proposed changes will be accepted! • How do you brand your version? • JDS : We take an official community release as our codebase and keep it locally. • You need to have a local build environment. • All source code changes done via patches. • Patches then go back to community

9. The Advantages of Using a Community Stable Release as your Codebase. • Freedom to integrate what you want & freedom to take out what you don't want. Direction & Control. • Brand, bugfix & test it to your hearts content • If the maintainer doesn't want it then he or she doesn't have to integrate your patch. • Improve integration with your other components. • You can complete the things that missed the train. • You aren't tied to the communities schedule. • Accountability : if it isn't right then you only have yourself to blame.

10. Using a Community Stable Release as your Codebase : The Drawbacks • The 'Bleeding Edge' of Development : Something to be sacrificed in the interest of stability? • Two codebases means two patches sometimes. Live with it! • The danger of forking from the community codebase completely & “throwing the baby out with the bathwater”. • Work overlap between you and the community. Solution : Get the patches in as early as possible.

11. Localisation Specific Challenges & Solutions in Open Source Work

12. Challenge 1 : The Volume of Content • 120+ separate applications & libraries for the desktop alone i.e excluding the operating system content Solution • Standardize methodology for i18n & l10n • Luckily the tools are mostly readily available : • For i18n : GNU Build system, gettext, PO files, intltoolize, • For l10n : intltools, gettext command set, msgmerge, msgattrib, msgcat commands • Central repository for all component source code • Documentation : A special case

13. Challenge 2 : Community Completeness of Translation for a Language • Some community language teams are better resourced or engaged than others. • Levels of completeness of translation in the community release of the product vary accordingly • Approximately 400,000 words of translatable UI in the JDS. Swedish 98% complete, Irish : 18%. Obvious impact on cost of completion for Irish.

14. Challenge 3 : The Quality of Existing Community Translations • Translation quality varies between languages • Terminological inconsistencies sometimes occur between applications. Improving rapidly. • The community translation teams use & understand the running software. Leads to good contextual correctness. • 'Fuzzy' content tends to be just that! • On the whole translation quality is good

15. Quality of Existing Community Translations. The Solution • Period linguistic review of the content & implement changes in the local build. • All 'fuzzy' content is treated as content for translation. Retranslate where appropriate. • Integrate changes locally and make reviewed/changed content available to the community • Integration of review changes into the community build tends to be labour intensive. • Make new content i.e messages not already translated by the community, available separately • Maintain all reviewed translation in a translation memory for future use.

16. Challenge 4 : Multilingual Files • No clean separation of English and translated UI messages! • Very common in open source projects - suffixes include xml, desktop, schemas, directory files • Their content tends to be quite visible. • The translated content is merged to them at build time. • Implication 1 : It is very difficult to ship language content for a product packaged separately from the product. • Implication 2 : Translation must be complete in the 'base' build for the product GA/FCS.

17. Excerpt from a Multilingual Desktop File :

18. Solution to the Multilingual Content Issue : ?

19. Challenges Encountered & Solutions Adopted in Developing the JDS • damien.donlon@sun.com