Developers/Projects

From OLPC
< Developers
Revision as of 00:54, 22 May 2011 by JZA (talk | contribs) (Added translation templates)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
  Please copy/paste "{{Translationlist | xx | origlang=en | translated={{{translated}}}}}" (where xx is ISO 639 language code for your translation) to Developers/Projects/translations HowTo [ID# 256296]  +/-  

Previous Next

This section tries to help you answer the question "Where should I start?" The OLPC is a huge project with thousands of people working on it, either directly, or on projects which feed into it. Since you are reading this document, we'll assume you want to work directly on the OLPC project, rather than on one of the projects that feed into it.

Most new developers are probably wanting to work on an Activity (a stand-alone application) for deployment to end-users (normally children). We are always, however, looking for help on the core systems (e.g. Sugar, Journal, Bitfrost, School Server), particularly from advanced Python coders and people interested in doing documentation and translation.

Existing Projects

Software projects describes the currently active projects that may need help. Note that the list there is maintained by the project owners, so while we say "active", some of the projects may be hanging in limbo. If you attempt to contact the owner and they do not respond or indicate they are no longer working on the project, speak up on the Devel list and we will attempt to figure out how to move the project forward.

If you are looking for a mature project to join, the various Activities already available on/for the XO may need help. While Software projects includes many projects that have barely started, Activities are the projects which already have public (child) facing releases. Bug fixing, testing, documentation, translations and the like are always highly sought-after contributions in these mature projects.

New Projects

If you are looking to start your own project, there are lots of as-yet-unmet requests to be filled. Or maybe you already have an idea of what you want to do. Either way, read this section for a discussion of how to integrate your project into the OLPC project.

Core Projects

There is only so much room on an OLPC-XO (or any similar laptop), and the choice of what Activities should be included in the base image is involved. The targets for an activity which will become part of the core set delivered to all children should be as follows:

  1. Epistemological impact—to what degree does this activity positively impact learning? (This is of course the most important criteria.)
  2. Fun—is it fun? engaging?
  3. Quality—is the activity sufficiently robust in its implementation that it will not compromise the integrity or supportability of the system? Is the overall quality of the implementation adequate to meet our standards? Can the community be engaged in the process of testing and "certifying" and maintaining the activity?
  4. Sugarized—to what extent has the activity been integrated into Sugar, including UI, Journal, security, internationalization, etc.? Does the activity require the folding in of additional libraries and resources? (This has impact on robustness—positive and negative—support, bloat, and the overall usability, aesthetics, and perception of quality of the machine.)
  5. FOSS—is the activity and all of its dependencies free and open?
  6. Extensible—is the activity something the community can extend? Does it span multiple needs? (And does it have—or the potential of having—an upstream community of support?)
  7. Uniqueness—does the activity add a unique feature to the core?
  8. Expectations—does the activity meet the expectations of (children, teachers, parents, G1G1 audience, etc.)?
  9. Discoverable—is the core activity discoverable? (This is not to say that it shouldn't be hard work to fully exploit the power of an activity, but it should have a low barrier to entry.)

If you are interested in eventually making your activity a core component of the OLPC, you should keep these targets in mind throughout your development process.

See: Original Thread

Recording the Idea

If you have a great idea for a new project, please add it to the Software ideas or Hardware ideas page so that it is not lost. Consider adding contact information so that people can contact you to ask questions about the idea.

Try to keep the entry to a line or two. If you need more space, create a new wiki page to describe the idea in detail. If you intend to work on the project yourself, this can become the homepage for your project eventually.

By recording the idea before you begin work, we can ensure that a great idea isn't lost because "life got in the way".

Finding Ideas

The obvious result of recording a great new project idea on the Software ideas page is that if you are looking for a new project idea, there are lots of them.

If you find an idea on the software ideas page, remember that lots of other people have probably read that page and may also be intending to work on that project. Be sure to advertise your intention to work on the project loudly so that you can flush anyone working on it silently out of the woodwork.

If the requirements are not clear, consider contacting the person who posted the request to get more information about what they were intending. Even if the requirements seem clear, consider contacting the person. Even if you wrote the requirements, consider discussing the requirements in public so that you can get input and feedback on what/how/whether the project should or could be done.

Choosing/Refining Your Idea

OLPC is not just a fancy hardware platform for kids to use — it is also a rethinking about how to use a computer as an educational tool. To that end, there are several design principles to keep in mind as you think about your activity. In particular, activities should include:

  • Discoverability — Is the activity intuitive to learn? Long instruction manuals are boring to read and hard to translate. The more intuitive you can make your activity's interface, the better. That means using an interaction model that encourages experimentation, using evocative images on buttons rather than text, etc.
  • Extensibility — Can the activity be easily edited by teachers and kids to expand its use? For example, does your quiz activity give teachers the ability to change the questions, so that they can use it for any type of quiz question, not just the ones you thought of?
  • Collaboration — Can your activity be used by more than one child at a time? Great activities should have both a single-user mode and a multi-user mode, if that makes sense with the activity. Is your game multiplayer? Does your word processor let two people write the same document?

These are core principles in the XO's Sugar user interface; it is worth looking at the OLPC human interface guidelines and the educational activity guidelines for more detailed discussions of what type of activity we are looking for.

Also, look at existing activities to find out what is already going on and what type of software is being developed.

Starting A Project

There are some basic steps you should take to start your new project and get it to the point where children are using it on their laptops:

  • Announce your project before you even start work
    • So that people know what you are working on and can potentially help you out
    • In case someone else is already working on a similar project
  • Add your project to Software projects
    • Add your contact information so that potential collaborators can reach you
    • Homepage (e.g. a page on the wiki with a full description of the project)
  • Write a few lines of Code (say 10)
  • Set up Source Code Control and Bug Tracker (See: #Project Hosting below)
    • Be sure you have a public bug tracker available somewhere, think millions of users, there will be bug reports!
  • Code
    • Remember to use source control, lost work sucks
  • Distribute under these licenses (where possible)
  • Test your application in an official image (preferably on a physical laptop) before publishing broadly
    • People will often test new code on their OLPC-XO if you don't have one
  • When ready to face real users (children) add your activity to the Activities page to allow for easy download and installation

Project Hosting

The OLPC Developers Program can provide Project hosting for OLPC-compatible projects, especially XO-specific projects. These services allow you to run your entire OLPC development project off of the OLPC servers.

For more general Sugar-based projects, see the resources at http://wiki.sugarlabs.org/Activity_Team and http://git.sugarlabs.org.

You are not required to use the OLPC's project hosting services, there are numerous other hosting services, such as:

or you can host your code on your own or your project's servers. Please keep in mind, though, that having your source code and ticket tracking engines publicly available is very important.

Note the OLPC servers are public and anyone can see anything you put on them. Do not put anything into your project repository (or the wiki, or the ticket tracker) which is proprietary, security-sensitive, or for which you do not hold the rights required to release publicly!

Wiki Space

The main OLPC Wiki can be used to set up your project's home page. This allows you to collaborate on the layout and setup of your project with both other members of your team and the wider OLPC community.

Source Code Control

Source Code Control (SCC) is critically important for any software project. The Developer's Program can provide you with GIT-based SCC. While GIT is neither familiar nor particularly friendly, it is used heavily by the Linux kernel developers, and is correspondingly robust. It allows for a distributed repository (similar to the Linux Kernel) or a central tree (like traditional SCC systems).

Users familiar with more traditional SCC systems should read the Git-SVN crash course, do not expect to be able to "work it out" just by trying to do things, GIT does not try to be user-friendly and does a very good job of not being intuitive.

Ticket Tracking

Ticket Tracking is similarly important in any software project. You need a way for users to report problems in a way that prevents issues from being lost or ignored. The Developer's Program provides a Trac-based ticket-tracking system which is reasonably straightforward to use.

See: Importing your project for a detailed description of how to use the Project hosting facilities

Previous Next