OLPC/Projects

OLPC project development streams

The OLPC platform development effort covers a very broader range of issues & technologies so no matter what your technical skillset there is certain to be an area where you can get involved in design/development of the project. At this time the work can probably be classified into a handful of sub-projects

• OS image tools - focuses on creation of tools for building the OS 'firmware' images from a Fedora OLPC yum repository.
• Software development kit - focuses on bundling of a set of tools to facilitate application development on the OLPC platform
• Simulator - although it could be considered a part of the SDK, it is more broadly applicable to both those creating & testing the base OS images.
• Optimization - considering ways in which the OS platform and basic applications can be optimized for the hardware constraints.
• Kernel - optimizing the kernel for the unique hardware constraints, such as limited RAM (no swap), development of MTD device drivers, ensuring flawless ACPI suspend/resume and much more
• OS Changes - Changes that need to be made to the base operating system utilities to host the OLPC operating system.
• Interaction - defining the mode/style of interaction for the desktop experiance.
• Localization/globalization - fonts, input maps, character sets, translations, graphics, and much more

Getting involved

All the Fedora OLPC projects are maintained using the Mercurial source control tool. With a distributed SCM tool, such as Mercurial, anybody can get anonymous access to the master repository, download the complete repository history, work on their local repository copy & then periodically submit bundles of changes back upstream, preserving repository history at all times. For further information on getting the source read about the OLPC source repository setup .

If you have ideas for work to be done in any of these projects the best first step is to make a suggestion on the mailing lists , then work off a local copy of the repository. Those who get heavily involved in the development process can also be given direct repository access via SSH, although as noted above with a distributed SCM tool, those with anonymous access have near identical SCM capabilities to those with direct repository access. The only difference is the mechanism by which changes are pushed upstream - anonymous users export changelist bundles & submit via email for review, while authenticated users can push straight to the repository.