Challenges Encountered & Solutions Adopted in Developing the JDS

Challenges Encountered & Solutions Adopted in Developing the JDS

Damien DonlonSoftware EngineerSun Microsystems Inc.

Sun Proprietary/Confidential: Internal Use Only

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


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!


Available Source Code != Open SourceUnder 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.


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.


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.


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!


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


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.


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.


Localisation Specific Challenges & Solutions in Open Source Work


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


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.


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


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.


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.


Excerpt from a Multilingual Desktop File :


Solution to the Multilingual Content Issue :

?

Challenges Encountered & Solutions Adopted in Developing the JDS

[email protected]

Documents

Challenges Encountered & Solutions Adopted in Developing the JDS