Help wanted - programming

BOINC always needs volunteers to help with software development. A list of contributors is here.

BOINC consists of several areas, each with some required technical skills:

Area	Skills needed
Client	C++, system programming
Manager	C++, WxWidgets, GUI and graphical design, usability
Server programs	C++, system programming, database design, MySQL
Web features	HTML, CSS, PHP, web design, usability, database design, MySQL
Unix build system	autoconf, automake, other GNU tools

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.

Finding tasks

There are several ways to get tasks to work on:

• Scan the BOINC bug database for unresolved bugs or feature requests.
• Read the list of proposed features on this page.
• Scan the BOINC message boards for ideas.

Coordinating and submitting your work

Once you pick out a task:

• Look at the source code and think about how you would implement the task.
• Read about the BOINC software and development process.
• Communicate with the area owner or David Anderson, and reach agreement on exactly what you're going to do and how. Don't start coding until you do this.

Submit your work (as diffs or files) to the area owner, so that they can evaluate it and possibly check it in.

Proposed features

The following development projects are available (Note: please do not add items to these lists. Suggest new items in the boinc_dev email list.)

High priority

1. Change the GPU framework. Currently BOINC requires that all GPUs of a given vendor (NVIDIA, ATI, Intel) be similar, and it treats them as a single pool (i.e. jobs are not associated with a particular GPU instance). This model has a number of drawbacks on machines with multiple different GPUs. Change the model so that each GPU is treated separately. This will require major changes to the client, scheduler, and RPC protocol.
2. The client's job scheduler has several O(N^{2) algorithms, where N is the number of jobs queued on the client. Change these to Nlog(N).}
3. The scheduler's logic for selecting app versions is clumsy. Replace it with logic that, at the start, selects a version for each (app, resource type) and stores these in an array.

Web features

1. Document the HTML classes and IDs used by the PHP code. Simplify where possible. Document the "standard" stylesheets, main.css and white.css. Finish black.css, and maybe make another style.
2. Change the sample project-specific prefs code (html/project/project_specific.prefs.inc) to use the object-oriented structure used for general prefs (html/inc/prefs.inc).
3. Add a Reset button to prefs (both general and project)

The following need to be evaluated:

1. Remodel the preferences system
2. Change default Q&A page to refer BOINC-specific questions to BOINC web site. #603
3. Convert team name HTML and team description to BBcode. #604
4. Add new profile features: #609
   • list of recent posts and threads this person created, on this and other projects.
   • other features from social networking sites, e.g. recent posts by your friends.
5. 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.
6. Use a WYSIWYG bbcode editor such as ​http://wysiwygbbcode.codeplex.com/releases/view/49836

Applications

1. Create Makefiles and project files to build the sample applications using MinGW and Dev-C++.
2. Write example FORTRAN application and Makefiles/ project files.
3. Investigate the crlibm library for generating identical results across processors (or at least reducing the number of cases for HR).

Runtime system

1. Implement a mechanism where the client can ask apps to checkpoint.
2. Use modern process-grouping mechanisms (e.g. Unix process groups).

Client

1. Keep track of the statistics of how long it takes to upload files, and to report results. Use that info to improve compute deadlines (e.g., subtract the 2 sigma point for both).
2. Client monitors total CPU usage, limits its own CPU usage so that total is < 100%.
3. Monitor working-set size of non-BOINC apps; don't allow total to exceed physical RAM. This could eliminate the need for memory-usage preferences. Note: this might be tricky because parts of a process's working set is shared with other processes. Some study is needed to figure out the best approach.
4. Use multiple disks. This would increase available space, and (if slot dirs spread across disks) would allow I/O-intensive apps to run more efficiently. Would have to remove assumption that project dir is ../../projects/X relative to slot.
5. Have the core client sense CPU temperature and throttle CPU if it goes too high. ​Open-source software for collecting sensor data (on Linux) is available.
6. Windows: get proxy config info directly from the OS.
7. Integrate BitTorrent (or ​libtorrent) with the core client.
8. Log result start/ends (for use by 3rd-party software like BoincView).
9. Vista: if get 'about to shut down' msg from OS, stop apps immediately (don't tell them to checkpoint). Investigate.

Installer

1. Check if host is configured to go into Standby mode after X idle minutes. If so, ask user if they want to let BOINC run for X minutes, then go into standby right after that.
2. Make it easy for teams to offer a client download that features their skin, and pre-register the user on that team for any projects he attaches to. #610

BOINC Manager

1. Show credit numbers (especially totals) with thousands-groups separators (e.g., commas)
2. If using an AMS, put link to AMS (or user page) in sys tray popup, elsewhere.
3. Reimplement the BOINC Manager so that it is:
   • Configurable via an XML file
   • Skinnable via CSS
   • nicer-looking than the WxWidgets? version
4. Show weekly/monthly transfer totals.

Server and Back End

1. Add support for parallel applications: try to schedule all the jobs in a batch more or less simultaneously. NOTE: being done by Volpex project from U. of Houston.
2. Implement a mechanism so that server software detects incompatible database format. (related to #715)
3. XML stats: add lat/long to user record?