/!\ Students: Please read the notes on the SummerOfCode2008 page to learn how to apply.

/!\ Attention: This list is not exclusive. This means you're free to propose any project you think is worthy.

General Info

It's important to note that this list is not exclusive: if you are a student and have an idea that is not listed in our pool of project ideas, don't hesitate to apply for your project. It's probably a good idea to ask people in the GNOME community if they think your idea is good, though. Also, if the development team is already working on something similar to your idea, they may be less likely to accept your proposal, so ask on the project's mailing list or IRC channel (lots of people lurk on IRC; don't be surprised if it takes an hour for your question to be answered, and don't just leave if nobody answers within five minutes!).

The ideas do not have to be only about modules that are in a GNOME suite. If it's a project on GNOME-related software that can benefit the GNOME community, it's also good to list it here.

When adding a project idea, please try to follow those guidelines:

  • if you're interested in mentoring it, put your name. If not, then just leave it blank.
  • do not list multiple idea with only one item. Use multiple items instead.
  • briefly explain why this would be great for GNOME.
  • do not write lots of text to explain your idea. If this is going to be long, maybe it's worth creating a page for it?
  • make sure students who do not know much about all GNOME modules can understand the proposed idea.

please use this format, as it will be easier to get some information about tasks:

 . '''task title''' (mentor: mentorname)
 * ''Benefits'': describe the benefits of your task
 * ''Requirements'': what should the student know already?
 * Note: one or multiple notes, links, whatever further information
----

/!\ Attention: This list was triaged by SandyArmstrong, AdamSchreiber, DanielSiegel, MarcoBarisione, LucasRocha, VincentUntz on March 24. Some notes about the groups: Rock Stars has the ideas having the highest priority (but don't focus only on those ideas, since we'll get many applications for those ideas!); Alternatives has the ones which are considered useful/cool enough to be proposed; and Underground has the ideas which were considered not well explained, not worthy at this moment, too wide scoped, etc. If you want to add an idea from now on, please add it to the New/not-triaged section. Also note that we support applications for projects that are not strictly GNOME-related, see the Other ideas section. If you really want to discuss the priority of your new idea, please contact BehdadEsfahbod ChristianKellner, LucasRocha and/or VincentUntz.

Rockstar Ideas




  • Reduce the calendar overhead in evolution-data-server

  • Benefits: Evolution-data-server currently uses much more memory than it should. Also, queries to large calendars can get pretty slow. This will make e-d-s both smaller and faster.

  • Requirements: Good C programming skills, familiarity with Valgrind and gdb.

  • Note: SummerOfCode2008/Ideas/EvolutionDataServerCalendar


  • Individual Workspace Wallpapers (mentor: ManuCornet)

  • Benefits: Usability improvements, related code refactoring, support for composite bling

  • Requirements: C programming, gtk+, familiarity with revision control system

  • Note: Based on an open bug aging back to 2001 (https://bugzilla.gnome.org/show_bug.cgi?id=48004)



  • Port Cheese to clutter/gstreamer-gl (mentor: for the cheese part DanielSiegel, for opengl?)

  • Benefits: New effects, faster cheese, more fun

  • Requirements: C programming, opengl knowledge

  • Note: see Cheese/Ideas for further ideas about cheese


  • Integrated printer management (mentor: GheeTeo)

  • Benefits: Properly integrated printer management GUI that works for everyone

  • Requirements: C (or Python) programming, gtk+

  • Note: Currently there is bit-rotting gnome-cups-manager, some distros use system-config-printer, gnome-printer-add and possible other solutions. Combining them into one project using Hal and PolicyKit where available would be a good start.

  • Note from admins: really needed, so rockstar. But we need a good mentor too. We'll find one.


  • Enable compositing in Metacity by default (mentor: Michael Meeks)

  • Benefits: Composited desktops are the future, but until we have ubiquitous compositing, people will not be able to depend on the technology to do cool things. Unfortunately performance problems mean we can't enable compositing by default.

  • Requirements: Good C programming skills, familiarity with X and metacity (preferred)

  • Note: Please contact mmeeks at novell dot com, and lets talk. The basic idea here is to do -highly- conservative re-direction of windows - ie. by default to turn off all the compositing 'bling' (window borders, thumbnails etc.) and only composite where absolutely necessary - leaving other windows (full-screen, un-occluded-by-composited-windows) etc. to be direct rendered (at high speed). This should mean that we have all the speed benefits of direct rendering, until we need compositing.
  • Note from admins: obviously, this also needs discussion with metacity hackers :-)


  • Reduce the addressbook overhead in evolution-data-server

  • Benefits: Evolution-data-servers's local addressbook backend is unindexed and need optimising. This will make e-d-s smaller and faster.

  • Requirements: Good C programming skills, familiarity with Valgrind and gdb.

  • Note: SummerOfCode2008/Ideas/EvolutionDataServerAddressbook


  • Epiphany: Mozilla weave plugin (mentor: *needed*)

  • Benefits: Online-Desktop! Sync bookmarks, history, customizations across computers or even browsers.

  • Requirements: C programming and GTK+/GObject or python and pygtk

  • Note: The current roadmap of weave says there should be a webservice API in the future to store and retrieve the stored data. At the moment webdav is used. Sadly there is not much documentation right now so the student would need to read a lot of source code to figure out how it is working. Also note, we dont need to use Mozilla's web server to store the data. The plan is to keep that open so we could have hosting from GNOME later.
  • Note (links): Weave Introduction


Alternative Ideas

  • Integrate APOC and Sabayon (mentor: AlbertoRuiz)

  • Benefits: ActiveDirectory like configuration administration for GNOME big deployments. Sabayon, the configuration profile creation tool, lacks an easy way to deploy profiles over the network, and APOC depends on some closed source components for the Web UI to work, which means that lacks a way to create profiles with a fully open source stack.

  • Requirements: Python and Java programming.

  • Note: http://www.gnome.org/projects/sabayon/ http://apoc.freedesktop.org


  • Vala plugin for Anjuta (mentors: JohannesSchmid, [JürgBilleter]])

  • Benefits: Vala is an upcoming programming language for the GObject system. It would be great to have an IDE for it.

  • Requirements: C programming, gtk+, familiarity with revision control system

  • Note: It would be great to have things like code completion for vala.


  • Media Integration (mentor: NicolasTrangez)

  • Benefits: easy access for multimedia files all over the GNOME desktop, very visible.

  • Requirements:

  • Note: SummerOfCode2008/Ideas/MediaIntegration

  • Note from admins: with a better description and more details, this could be a rockstar idea. Students will need to be careful to explain the scope of the project and the various steps that will be done.


  • Synchronization and the GNOME Desktop

  • Benefits: Apps like totem or cheese do their own thing when it comes to file export/import. this task would resolve those issues

  • Note: SummerOfCode2008/Ideas/Conduit

  • Note from admins: the scope of the project really needs to be better defined, but since it can bring really great features, we're putting this idea in the Alternative category.




  • One-click touch-ups for f-spot (mentor: StephaneDelcroix)

  • Benefits: More --and better-- one-click automatic touch-ups like "auto contrast" in picasa, "relight" or "instant styles" in LightZone, lens correction (using ptstitcher lens db) and more.

  • Requirements: mostly C#, but some C too, cairo, image processing knowledge

  • Note: there's 2 part in this, one being abstracting the f-spot editing code, the second being implementing touch-ups as addins
  • http://f-spot.org/Soc2008


  • DPAP support in f-spot (mentor: StephaneDelcroix)

  • Benefits: being able to consume f-spot and iPhoto network shares, sharing your collection on the local network

  • Requirements: C#, access to a Mac running iPhoto.

  • Note: this will probably require writing a new d[x]ap, preferably fully managed (or write C# bindings for libdmapsharing, BastienNocera)

  • http://f-spot.org/Soc2008

  • Note from admins: nice, but it'd be better to use libdmapsharing as Bastien suggested, if possible.



  • Google addressbook integration (sync) for Evolution (mentor: ChristianKellner)

  • Benefits: Google Apps integrated office suite

  • Requirements: C programming, Evolution internals

  • Note: I (ChristianKellner) have already started on that, but dont have much time right now to finish it off. We already have libraries in e-d-s for the GData (Google is using the same REST based API for calendars and contacts). It would be great to polish that API and then create a fully function backend. Should be very doable in GSoc Timeframe.


  • Google docs integration for abiword and gnumeric (mentor: ?)

  • Benefits: Google Apps integrated office suite

  • Requirements: C/Python programming

  • Note: As a user i would like to connect to my google docs account and see all the docs from there (maybe even gvfs backend?)
  • Note from admins: a gvfs backend could be an interesting solution (although other ones can be used). This probably means losing the ability to edit collaboratively with people who are still using Google Docs. Potentially rockstar, depending on the student application.


  • WMF/EMF import filter for Dia (mentor: ?)

  • Benefits: it would be nice to support widely used vector file formats in Dia

  • Requirements: C programming, gtk+, GDI could be an asset

  • Note: libwmf could be good starting point for this project, other applications like AbiWord, Gnumeric, and Inkscape could benefit from such an importer too. KOffice also has a GSoC2008 idea to improve support of old MS Office formats, that partially overlaps with this project.

  • Note from admins: could be interesting, but there are probably better improvements to do to dia.


  • Visio VSD/VSS import filter for Dia (mentor: ?)

  • Benefits: it would be nice to support file formats of the 'de-facto standard' application

  • Requirements: C programming, gtk+

  • Note: It could be implemented as an extension for Ian Redfern's VDX importer. WMF/EMF importer is required to make VSD/VSS importer really usable. Ask frob@gnome.org about VSD/VSS format description details, some code snippets etc.

  • Note from admins: could be interesting, but there are probably better improvements to do to dia.


  • Increase integration between GNOME and PulseAudio (mentor: ?)

  • Benefits: PA already works pretty good with GNOME, but could use some work when it comes to integration (PA:s native volume control versus the one in GNOME for example) and making it more useable for less technical users (PA mentions scary stuff like servers, sinks and sources all over).

  • Requirements: ?

  • Note: The PA maintainers take on the volume control.

  • Note from admins: interesting, but needs to be better defined, with a good scope. Nearly rockstar.


  • DBus based Global Menu System (a menter is *needed*)

  • Goal

    • Provide a IPC(DBus since it is the dominate IPC model in GNOME) global menu system for GNOME.
  • Benefits:

    • When GNOME decided to use global menu, there will be some code to pick up.
    • It should be a seperated set of widgets, and can be seamlessly used whenever the old menu system is used.
    • Also helps the gtk-osx port to support native menu system, since osx menu system is basically the same thing on top of a different IPC system.
  • Requirements: C, glib, dbus-glib

  • Proposed by YuFeng, who is also filling an application at Google Soc site (as the user rainwoodman).

  • Note from admins: be careful, it really needs to be well integrated in GTK+ to be useful and accepted.


  • Epiphany: complete last year's bookmark and history integration project (mentor: to be determined)

  • Benefits: The current History functionality in Epiphany is quite limited. It would be great to bring bookmarks and history under the same umbrella, making them available to all of GNOME instead of just the web browser. Could be a perfect use case for Tracker;

  • Requirements: C programming, GTK+/GObject (need not be a pro at the start!), sqlite

  • Note: This was an accepted project in SoC 2007 but it wasn't finished completely. Students will therefore have a head start and last year's work won't go to waste.
  • Note: more info on SummerOfCode2008/Ideas/CompleteBookmarkHistoryIntegration


  • Automated Test Suite for Anjuta using LDTP (mentor: NabaKumar)

  • Benefits: A completly automated test suite for anjuta and its plugins , will help remove regressions at the early stages and very helpful for developers

  • Requirements: Good knowledge of LDTP , python and GTK.

  • Note: Proposed by suren(irc-nick: nuke_serge)
  • SummerOfCode2008/Ideas/LdtpAnjutaTestingSuite

  • Note from admins: in the past, we didn't have a good integration of the result of this kind of tasks. This would be useful if really well integrated (with "make test", eg), though.


  • Firebug for Epiphany (mentor: ?)

  • Benefits: Epiphany is a lot better than Firefox (2, at least), but for web development Firebug is really hard to beat, so it would be great if someone could write an Epiphany extension to include (or reimplement) Firebug

  • Requirements: C (or Python) programming for the Epiphany extension, JavaScript programming, familiarity with web development

  • Note: could be also done using the webkit backend, maybe reusing Drosera and their Web Inspector, which are also listed in their GSoC 2008 page


  • Add code folding to GtkSourceView (mentor: ?)

  • Benefits: GtkSourceview has all major editing features and viewing code is clearer

  • Requirements: Gtk+ knowledge, possibly Pango knowledge

  • Note: There is gnomebug:134610 with a very old patch which could have some ideas



  • Librsvg: Improve text support (mentor: EmmanuelPacaud)

  • Benefits: Librsvg support of text properties is pretty limited. The applicant should try to improve the situation by implementing as much features as he'd think he's able to. Support of text on path or support of SVG fonts would also be great.

  • Requirements: Good C programming skills.

  • SVN repository

  • SVG text specification

  • Text element bugs


Underground Ideas


  • GNOME Color Management (mentor: ?)

  • Benefits: Display/Printer CM in GNOME for semi-/professional use

  • Requirements: C programming, gtk+, familiarity with revision control system

  • Note: Integration of Xcalib/ArgyllCMS with a control-panel applet to manage installed ICC/ICM profiles
  • Question from admins: what does it exactly involve? It doesn't sound big enough for a SoC project right now.



  • Implement LibAccroc, a library for generic OCR in GNOME using OCRopus and other engines (mentor: ÉtienneBersac)

  • Benefits: Finaly integrate OCR in GNOME and GNOME Scan

  • Requirements: Vala/C programming


  • DBus for Cheese (mentor: DanielSiegel)

  • Benefits: Other apps could call cheese to take a picture or a video

  • Requirements: C programming, DBus knowledge

  • Note: develop a dbus interface for cheese, which starts cheese and returns a picture/video on closing. this could be used by gnome apps to get a picture video, e.g. for buddy icons, video editing, ....

  • Note: see Cheese/Ideas for further ideas about cheese

  • Note from admins: would be neat, but it's probably too small for a SoC project. Might make sense to also change applications to use this feature so the project is big enough.


  • Add waf build scripts to the desktop suite modules (mentor: ?, AlbertoRuiz and Thomas Nagy (waf maintainer) for help)

  • Benefits: waf would increase easy of maintenance of the build system and building speed

  • Requirements: Python programming, being able to barely understand an autoconf/automake script

  • Note: Compilation tests included in autogen.sh should be added to the existing Gnome tool, to make the port of other applications easier. Support for Rarian (Scrollkeeper successor) and other Gnome-specific file transformations should be added as well. A tool to half-automatically port autotools projects would be nice too http://code.google.com/p/waf/

  • Note from admins: putting in Underground ideas because there was no consensus on waf last time it was discussed. Providing a migration doc for developers would also be great.
  • VincentUntz: I'd love to see this work done.


  • Bug-Tracking Aid in Evolution (mentor: SvenHerzberg)

  • Benefits: improve developers productivity

  • Requirements: C programming, Corba, Bonobo, E-D-S, Interfacing Bugzilla properly

  • Write a new evolution component for GNOME bug tracking
  • "Add new query" adds queries like folders
  • Bugs displayed as the HTML pages they are (eg. using webkit)
  • Attachments can be downloaded
  • And all with clever caching so bugzilla doesn't get hit too hard (and to provide certain features offline, too)
  • Maybe even integrate "Report Bug" into it
  • I'm pretty sure people can make up really interesting use cases here
    • Why only bugzilla? We have a lot of BTS'es (Bugzilla, Track, RedMine). Maybe it should be bugreport/tickets consumer with different adapters?

      • SvenHerzberg: because we at GNOME use bugzilla; other bug trackers can be implemented later, but it's better to have something that works with bugzilla than nothing working with any bug tracker

  • Note from admins: a native bugzilla client would be great. But our bugzilla infrastructure needs more work (switching to bugzilla 3.0, at least) before it's ready. Also, it seems it'd be better to write a stand-alone application instead of an evolution component.


  • Create git plugin for [gedit] (mentor: ?)

  • Benefits: powerful gedit

  • Requirements: C/Python programming

  • Note: not yet
  • Note from admins: we prefer the GIT plugin for anjuta.


  • Moviestudio for Gnome (mentor: ?)

  • Benefits: Users can create, edit, and share their movies. Build their movie with a few simple drag-and-drops.Then share their movie via the Web, e-mail, or CD

  • Requirements: C/Python programming, gtk+

  • Note: SummerOfCode2008/Ideas/Moviestudio, can be base on PiTiVi

  • Note from admins: this should really be about improving pitivi, and then sharing the movies via something like conduit.


  • Dxf viewer for Gnome (mentor: ?)

  • Benefits: Gnome support for engineers. A lite and fast dxf viewer, browse, view, measure, print DWG, DXF, DWF files.

  • Requirements: Python programming, gtk+

  • Note: SummerOfCode2008/Ideas/GnomeDxfViewer


  • RandR 1.2 support in gnome-display-properties (mentor: ?)

  • Benefits: Easily configure and activate multiple monitors and projectors

  • Requirements: C programming, gtk+

  • Note: Bug 405105 and 406585 requests this functionality. Possibly grandr could be used as a proof of concept. It could be a great idea to implement a d-bus mapping for randr. So we could use this interface to add new cool functionnalities to epiphany (presentation mode), totem (if a projector is present, show the film on it), evince (very useful for presentation), etc. I already thought a bit about, contact me if you want some ideas (Antoine Cailliau)

  • Note from admins: there's already some work being done by Soeren Sandmann on this, that's nearly ready. So it's probably a bad idea to propose a project based on this.


  • Pownce client app. for GNOME Desktop (mentor: You?)

  • Benefits: It'd be good to have it!

  • Requirements: <Please fill in the blanks my mentor>

  • Note: They have already their Windows and Mac OS X client based on Adobe's AIR working and Developer API available; but most important thing of all: I want to hack for GNOME!


  • Record speech as a Tomboy note (mentor: NickolayShmyrev)

  • Benefits Another way to speech-enable the desktop

  • Requirements: C#, gtk+, gstreamer.

  • Optionally this task will include other places where speech could be useful. Also, it would be nice to implement speech search with some form of keyword spotting.
  • https://bugzilla.gnome.org/show_bug.cgi?id=523116

  • Note from admins: probably too small.


  • Color Profile support in f-spot (mentor: ?)

  • Benefits: a fully color managed photo workflow for the GNOME desktop

  • Requirements: C#, color profiles, ICC

  • Support color profiles for sources (cameras), viewing and printing
  • http://f-spot.org/Soc2008

  • Note from admins: project too small.


  • Modern Download Manager for GNOME (mentor: ?)

  • Benefits: Download managers help power users download files easier. There are no updated modern download managers for GNOME.

  • Requirements: Student should be familiar with other GUI download managers like KGet, D4X.

  • Note: Download manager should support multi-source downloads, checksum verification, and maybe integration with Firefox via FlashGot. Maybe Metalink Checker (a Python lib) could be used for the backend.


  • Finish Mathusalem, the long running task manager for GNOME (mentor: ManuCornet)

  • Benefits: A centralised GUI to manage long running tasks from the whole desktop.

  • Requirements: C programming, knowledge of DBUS

  • Note: see http://live.gnome.org/Mathusalem

  • Note from admins: the mathusalem concept is great, but everything needs to be started from scratch (as far as I remember -- VincentUntz), so it's not appropriate for SoC, unfortunately.


  • Enhance Damned Lies and integrate it with open-tran.eu (mentor: OgMaciel)

  • Benefits: Dozens and dozens of translators work on GNOME packages every day, relying on damned lies to keep us up to date with statistical information, as well as emails sent to the i18n mailing list. By adding a RSS feed for changed translations as well as integrating with http://open-tran.eu, translators would be able to keep up with the ever changing state of translations, as well as standardize their vocabularies.

  • Requirements: Python, XML-RPC, web programming and maybe some database knowledge

  • Note: http://l10n.gnome.org http://open-tran.eu

  • Note from admins: it's really not clear how this integration can be done, since damned-lies only provides statistics (so far). But proposals for open-tran.eu integrated usage in gnome are welcome.
  • Note 2: The integration would be in the form of automatically updating the database at said site every time the translation status has changed. But I'd like to stress how usefull a RSS feed would be. :)

  • Note: sounds great and probably will be very useful to improve translated contents for Gnome. Translators deserve as much aid as possible!


  • Write a UPnP MediaCenter plugin for Totem (mentor: FrankScholz)

  • Benefits: Allowing GNOME to serve as media renderer, media server and a streaming client for network MediaCenter devices including modern video consoles.

  • Requirements: C or Python programming, some Gstreamer and UPnP experience

  • Note: quite some parts from the Rhythmbox UPnP plugin can be reused for this
  • Note from admins: totem doesn't manage a library, so it might not be the best place for this feature.


  • GNOME Goals page and schedule (mentor: ?)

  • Benefits: GG are small/easy and documented changes needed to improve GNOME. It leads to good GNOME programming recipes, and help new developers to start contributing. A visible and scheduled GNOME Goal page (gnome.org/goals), with progression timed-graphs, points/rewards?, bugzilla/wiki integration (bug queries, automatic bug creation?..).

  • Requirements: web techno, communication

  • Note: (proposed by MarcAndreLureau)

  • Note from admins: not a coding project, so can't work for SoC.


  • GNOME Web (mentor: MurrayCuming?)

  • Benefits: continue the infamous GnomeWeb revamp, GNOME project marketing and visiblity

  • Requirements: plone skill or strong interest, writing/documenting, filling and updating pages?

  • Note: (proposed by MarcAndreLureau)

  • Note from admins: not enough coding, so not for SoC.


  • Gnome On Rails (mentor: ??)

  • Benefits : To simplify creation of GTK based application and reduce the amount of code to be written to develop applications as in Ruby on Rails

  • Requirements: Python,PyGtk

  • Note : SummerOfCode2008/Ideas/GnomeOnRails

  • Note from admins: we'd prefer to see this work done as part of anjuta.


  • GParts, a Bonobo replacement (applicant: AlexandreFranke, mentor: Éric Bischoff)

  • Benefits: a practical component embedding system

  • Requirements: Bonobo, C, GLib

  • Note: SummerOfCode2008/Ideas/GParts

  • Note from admins: this is really going against what we've been doing in the past few years.
  • Note: Universal Applets allows registering a part of an application as an applet. Anything more than that is probably a bad idea.


  • PHP Platform Bindings for GNOME (mentor: AnantNarayanan)

  • Benefits: This would allow GNOME applications to be written in PHP.

  • Requirements: Strong C skills mandatory, Knowledge of Zend API a plus but not necessary.

  • Note: This idea may be proposed to PHP too.

  • Note from admins: can be nice, but not useful to enough people to be in Alternative ideas..


  • widgets (mentor: ?)

  • Benefits: Vista, OSX, and KDE4 all have widgets/gadgets/Kthingies that are pretty, very easy to use, very easy to develop (since they are web-based), and which display more information when needed while staying hidden when not needed (both unlike our panel applets.) GNOME should catch up with this.

  • Requirements/Technology: Some work has already been done on doing this with gtk-webkit[1]- perhaps that could be built on? There is also a screenlet that will do some web-based widgets.

  • Note: Proposed by LuisVilla. This idea is already being implemented by a non-GSoC student. (There's no up to date overview, but Natan's blog provides some information (http://theesylum.com). Look at recent commits to his branch for some information or ask on irc (nick is aantn on freenode and irc.gnome.org)


  • panel replacement (mentor: ?)

  • Benefits: The current panel does not incorporate any new UI ideas.

  • Requirements: work with bigboard, gimmie, and/or AWN to build something appropriate to replace the panel in future releases.

  • Note: Proposed by LuisVilla

  • Note from admins: requires too much coordination with the community, and is really a huge task.


  • very basic search in panel/run dialog (mentor: ?)

  • Benefits: Windows and KDE4 both have search and MRU deeply integrated into how users find and run applications, and it makes them simultaneously easier and more powerful to use.

  • Requirements: These features have been prototyped but not deployed into mainline GNOME, via deskbar and Novell's 'slab'/gnome-main-menu. Diving into those projects, figuring out what prevents them from being mainlined, and working on those rough edges may be worthwhile.

  • Note: Proposed by LuisVilla

  • Note from admins: not clear what this is about? deskbar is in the destkop already.


  • mozilla 'prism' integration (mentor: ?)

  • Benefits: gratis-free webapps are a big part of the future of the desktop; making sure they integrate well into GNOME should be an important task.

  • Requirements: Investigating Mozilla's prism or similar technologies, and doing a good job at tying them to GNOME (e.g., currently prism places a launcher on the GNOME desktop but not in the menus) might be interesting and worthwhile.

  • Note: Proposed by LuisVilla

  • Note from admins: seems like most of what is needed is too small for a SoC project. It's mainly small tasks that could be done for GHOP.


  • testing framework (mentor: NagappanAlagappan)

  • Benefits: GNOME badly needs an automated, regularly run test framework to avoid regressions and improve accessibility.

  • Requirements: Work with the QA, buildsquad, and a11y folks to evaluate the three competing technologies and ensure that one of them gets run automatically every single day.

  • Note: Proposed by LuisVilla

  • Note from admins: there is a GNOME Outreach Program: Accessibility task for this.


  • SDDT: start development (A common data access layer for the free desktop) . (mentor: ?)

  • Benefits: Ideally, all useful data will be accessible through this layer. Desktop applications, web services data and devices (N800, PDAs, Phones, etc). Notifications will be provided as dataproviders become available and go away.

  • Requirements: C/C++, Python

  • Note: Proposed by seiflotfy. For more Information visit SuperDataDaemonThing.

  • Note from admins: a bit too vague, and not well-enough defined. Also too big for Soc.


  • Alarm clock integration into Gnome clock applet (a menter is *needed*)

  • Benefits: adding a very useful feature to deskbar for those who work around the clock in front or near their computers :)

  • Requirements: ?

  • Note: The gnome clock applet has been expanded recently for Ubuntu Hardy. Something in the fashion of wmtimer would be just simple and great


  • Soylent: add simple group event planning (mentor: TravisReitter)

  • Benefits: Narrow the gap between a whim and a party!

  • Requirements: C programming, GTK+/GObject (need not be a pro at the start!)

  • Note: This is to start making Soylent fun to use by solving this use case: Alice wants to invite her friends Bob, Christine, Darryl and Edna over for a party Saturday at 7:00pm. Alice wants to email her friends the details, create and include a link to the new event on her calendar all in one simple process. (Of course, this would be useful for non-party events too)
  • Note: General Soylent proposal by LuisVilla, specific idea by TravisReitter

  • Note from admins: this specific use case sounds a bit less interesting than generally improving the user experience in soylent.


New Untriaged Ideas

(Ideas will be triaged into Rockstars and Underground later by the GNOME SoC Admins)

Other ideas

Unless otherwise noted, you may make proposals related to these projects with GNOME as your mentor organization. GNOME will seriously consider applications to work on projects that are relevant to GNOME since this will help improve the user experience.


  • LLMNR protocol integration in Avahi (mentor: TrentLloyd)

  • Benefits: This would allow Avahi to take part on both Apple-style and Microsoft-style Zeroconf networking. LLMNR is enabled by default in Windows Vista and Windows CE 5.0. Adding this functionality to Avahi would allow Linux machines to integrate much better in Windows-style networks when it comes to name resolution.

  • Requirements: C

  • Note: This idea was proposed by Avahi itself last year, but as it seems that there has been no progress I would like to work on it. (SunilGhai)

  • Note: This has been a top item on Avahi's TODO list for quite a while, so we as the Avahi maintainers (i.e. LennartPoettering and TrentLloyd) would love to see this done as part of GSoC.


  • Hotwire Hypershell: Improved overview mode (mentor: ColinWalters)

  • Benefits: This is a much-asked for improvement to managing execution of multiple pipelines simultaneously. See: http://code.google.com/p/hotwire-shell/issues/detail?id=169

  • Requirements: Python

  • Hotwire Hypershell: "Tomboy of code" (mentor: ColinWalters)

  • Benefits: For this task you will implement a system that allows easy creation of multi-line Python scripts, and executing them in-process. See http://code.google.com/p/hotwire-shell/issues/detail?id=79

  • Requirements: Python

  • Hotwire Hypershell: SSH Remoting prototype (mentor: ColinWalters)

  • Benefits: For this task you will implement a prototype of code to execute and manage pipelines on remote machines over SSH, most likely using the paramiko library.

  • Requirements: Python

  • Hotwire Hypershell: Fix 3 small issues (mentor: ColinWalters)

  • Benefits: For this task you add patches to 3 of the more minor issues in the task tracker.

  • Requirements: Python

  • Hotwire Hypershell: Prototype multi-language under OpenJDK (mentor: ColinWalters)

  • Benefits: For this task you will modify the hotwire/ core to run under OpenJDK+jython, and prototype execution of multiple languages in the same process. You'll also need to create a small non-GUI interface to the Hotwire core for this project.

  • Requirements: Python

  • Hotwire Hypershell: Windows installer (mentor: ColinWalters)

  • Benefits: For this task you will create a system where the project can create a Windows installer, including an updater system.

  • Requirements: Python

  • Hotwire Hypershell: OS X port (mentor: ColinWalters)

  • Benefits: For this task you will bring Hotwire on MacOS X up to roughly the Windows level of functionality, including process enumeration, native icons on files, and application launching.

  • Requirements: Python

  • Diva Project

  • Benefits: For this task you will bring to life the most promising project to give GNOME an easy-to-use video-editing application.

  • Requirements: Mono, GStreamer/Gnonlin

  • Note: Michael Dominic K. left the development of Diva Project on December 2006 with this article, replied by a comment by Christian Schaller.

  • Note: You could try latest version of Diva compiling from source or installing a deb package.


For GNOME from previous Summers of Code editions

Outreach/SummerOfCode/2008/Ideas (last edited 2013-12-03 18:32:29 by WilliamJonMcCann)