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.