• Get BOINC source code
• Building server software
• Building applications
• Building BOINC client software

BOINC development

• Personnel and contributors
• Development information flow
• BOINC/Trac (bug database, source code browsing)
• boinc_dev, an email list for BOINC developers.
• Implementation notes
• BOINC coding style
• The BOINC testing framework

BOINC is free software, distributed under the Lesser General Public License (LGPL). We need volunteers to help with software testing and development. If you have one or more of the relevant technical skills (C++ system programming, PHP/MySQL web development, WxWidgets programming, autoconf/automake expertise, etc.) you may be able to help us maintain and enhance BOINC.

The University of California holds the copyright on all BOINC source code. By submitting contributions to the BOINC code, you irrevocably assign all right, title, and interest, including copyright and all copyright rights, in such contributions to The Regents of the University of California, who may then use the code for any purpose that it desires.

In any case, you are welcome to browse the source code and give us feedback. You should understand how BOINC works (for both participants and projects) before getting into the source code.

To get started, find a small bug fix or enhancement to do (look at the BOINC bug database, the email lists, or message boards for ideas). Look at the source code and think about how you would implement it. Then communicate with the area owner, sketching what you want to do and how. Work the the area owner to carry out and check in the work.

Development projects

The following medium-to-large development projects are available:

• Applications
  • Write an example compound application (and suggest API revisions to make this easier).
  • Create Makefiles and project files to build the sample applications using MinGW and DevC++.
  • Extend wrapper application handle multiple tasks, and test/debug it.
  • Investigate the crlibm library for generating identical results across processors (or at least reducing the number of cases for HR).
  • Graphics in separate program.
  • Java support: core client checks for the existence of JVM, reports version to scheduler. Write Java wrapper (runs JVM, gives it jar files). Note: Szataki has already done some part of this.
  • Same, .NET
  • Distributed Python: Borrow or invent a notation for master/slave execution in Python. Develop a system that implements this on BOINC, i.e., creates WUs and applications, and harvests the results.
  • Write example FORTRAN application and Makefiles/ project files
• Core client:
  • Add a preferences for total download and upload in a month (many Australian ISPs have monthly limits)
  • Have the core client sense CPU temperature and throttle CPU if it goes too high. Open-source software for this (on Linux) is at http://www.lm-sensors.org/.
  • Windows: get proxy config info directly from the OS
  • After an applications exits or is killed (for whatever reason) make sure (after a few second delay) that its subprocesses are gone too. Don't restart the job until this happens. Unix: use process groups and killpg().
  • More generally: make a better state machine for shutting down apps: tell them to checkpoint, wait a little, tell them to quit, clean up straggler processes.
  • Integrate BitTorrent with the core client.
  • Do potentially slow RPCs and other tasks (such as computing disk usage) in a separate thread.
  • Don't enforce RAM limits unless free RAM is low
  • Extend general preferences to allow users to specify different time-of-day restrictions for different days of the week.
  • Write a simulator for the CPU scheduler and work fetch policies (Derrick Kondo is working on this).
  • Log result start/ends (for use by 3rd-party software like BoincView).
  • Prevent disk space usage from exceeding user preferences, and enforce resource shares, with file deletion according to project policy.
  • Make messages of class MSG_USER_ERROR translatable.
  • GUI RPC to tell apps to checkpoint and quit.
  • Vista: if get 'about to shut down' msg from OS, stop apps immediately (don't tell them to checkpoint). Investigate.
• BOINC Manager:
  • Make simple GUI accessible to visually impaired.
  • Properties pages for projects, jobs
  • Project list (Rom's working on this)
  • Turn off alerts (Rom's working on this)
  • Have the Manager do RPCs in a separate thread.
    (The following are currently in progress by Frank Weiler)
  • Advanced prefs dialog
  • Show progress bars for file transfers and in-progress results (this requires changing the container class from Spreadsheet to Grid).
  • Sortable columns in the Work tab.
• Server/Back End:
  • Add a 'validity' field to host. Exponential average of fraction of valid results. Demand more replicas if some are from suspect hosts.
  • Allow the scheduler to take a list of platforms (not just one). E.g. a Win64 machine could send Win64 and Win32.
  • When using HR, if the scheduler has sent one result of a WU using a particular app version, it should use the same app version for other results from that WU. Need to change protocol to specify version num; need to change client to use this.
  • Implement a mechanism so that server software detects incompatible database format
  • Scheduler: implement mechanisms so that server:
    • Sends only results likely to finish by their deadline
    • Sends commands to abort results that can't get credit
    • Sends commands to recommend abort of results that may get credit, but are not useful (i.e. canonical result already found)
    • Attempts to send results from the same WU to hosts with similar speed, so that a fast host doesn't have to wait weeks to get credit.
  • Implement a 'benchmark result' mechanism: every host runs a benchmark result per app version, and the CPU time determines credit/CPU for future results
• Web features:
  • Propagate profiles between projects. When create or edit profile, if attached to other projects, show 'propagate changes' page, with checkboxes for other projects (must have same password on other projects). Add web RPCs for updating profile (args: user ID, profile, password hash) Implement this so that page doesn't block waiting for replies from RPCs.
  • Same for forum preferences
  • Combine user page and profile
  • Add new profile features:
    • 'Buddy lists'
    • personal messages
    • list of recent posts and threads this person created, on this and other projects
    • other features from networking sites?
  • Change the ops/ web pages to require login by a user with admin privileges.
  • Add 'referral' mechanism: new user creates account, enters email of 'referrer' (or goes to URL that has it embedded). Give referrer a fraction of credit (or a 1-time bonus). List referrals on user page (show only those still active). Add new referral table to DB.

Writing add-on software

BOINC's architecture is 'open'; documented interfaces making it possible to develop various types of applications and web sites that interact with BOINC components. Examples include: "; list_start(); list_item("Client GUIs", "Application that control a local or remote core client." ); list_item("Credit statistics web sites", "Web sites showing credit information (project totals, user/team/country leaderboards) based on daily XML feeds of statistics data from BOINC projects." ); list_item("Account managers", "Web sites that let BOINC users create and manage accounts on multiple projects." ); list_item("Server status web sites", "Web sites showing the server status of BOINC projects." ); list_item("Web RPCs", "These interfaces let a program or web site obtain information about users and hosts from projects." ); list_item("Local editing of preferences", "This mechanism lets you write programs for local editing of preferences." ); list_end(); echo "

Check the index of add-on software before writing anything (it may already exist). The index has instructions for submitting new add-ons. "; page_tail(); ?>