Welcome to the Oregon State University Open Source Lab Google Summer of Code Ideas page.
One of the things we learned in the past two Summer of Code programs is that the more time spent on collecting and refining the proposed project ideas, the better the summer goes. So with that in mind … ta-dah! A new SoC ideas page.
Thank you for your interest in the Open Source Lab's Summer of Code proposals. Here at the OSL we feel we have a two-part goal. First, we are a strong supporter of the open source community and want to help as many projects as we can. Second, we are an educational institution that tries to incorporate teaching and learning into as much of what we do as possible. The Google Summer of Code helps us to do both.
It is important to note that none of these projects are cast in stone. We very much want to work with our students on developing and shaping the project. Think of this page as a general outline of some of the things we want to do. Don't be afraid to propose something that does not exactly match what we have below.
If you have a great idea for a project that's not listed here, please feel free to submit it as well. If it is a very well thought-out proposal with realistic goals, is in some way related to one of the projects we work with and something one of our mentors would be interested in working on, we may accept it.
There's more to a good proposal than just a good project idea. When we evaluate applications, we don't just look at the idea itself. We also look at how much thought and effort has gone into the proposal. Does it have a roadmap or a timeline with milestones? Are the milestones reasonable? Is there time built in for documentation and bug-squashing? Has something like this been done before? If so, how is this proposal different?
It's important when starting a new relationship like this that both sides are aware of the expectations involved. We're a pretty easygoing bunch here at the OSL - we're far more interested in building neat stuff than we are about rigidly following some policies and procedures manual. However, we do have some pretty simple expectations:
Questions? Concerns? Want ask us if we'd be interested in an application? Drop in and visit us in #osuosl on irc.freenode.net. If you're not sure who to talk to ping gchaix in #osuosl or #gsoc.
Hint: if we've already talked to you about your proposal, it helps your chances for acceptance. We're happy to give feedback and suggestions on proposals, so it's a good idea talk to us before you submit it.
For the first pass, it will probably be easiest to generate a file (a zip file of some other filetype?) that gets saved from one site, and then uploaded into the other.
Watch&Listen is a media player for the One Laptop Per Child (OLPC) aka the XO. It uses the Helix media engine for playback.
Helix Producer is an encoding tool that is part of the Helix Media Engine. It can read from some existing formats as well as capture audio/video from capture devices such as microphones, webcams, and TV cards. Helix Producer is being used in several applications for the OLPC
Implementing any of the protocols required for standard videoconferencing:
Output Plugin for any of the common image formats
System administrators receive quite a bit of email from their systems hourly/daily/etc. Often times the emails are just informative and are often repetitive. There needs to be a way of sucking in the emails into an application which in turn, stores it in a sane manner, has an aggregate reporting mechanism, and an easy way to search the archives.
Implement an application that will use emails sent by systems that will import the data into a database. It will also offer the ability to easily define new data-sets and reports without needing to change the database schema. Basically, you define a template which this application uses to import the data. It would need to also have a “language” or a configuration file which dictates how it gathers the information. This might be similar to how tenshi works for defining how to grab the information.
An example of what we're wanting using a Mysql performance email.
Another feature that would be nice would be a webapp frontend. This frontend would be able to generate PDF or printable reports on the fly. It will also have a search function so we find various information easily without having to parse through emails. It could also display any trends that might be happening.
We have a working example written in python, but its written specifically for GLSA emails. Its current workflow is the following:
The cron jobs are currently staggered an hour apart.
In the UNIX sysadmin world, there is no central ground for building packages that span distributions, and even operating systems. For the most part, each OS has their own set of tools to build packages. I'm (Lance) currently working on merging several tools into one tool called unify which will enable system administrators to use one spec file to build an RPM, deb, or solaris package. I'm using spec files primarily because there have been tools written for both debian and solaris which let you use spec files to build them. Unfortunately they both have slightly different ways of building packages. The goal of this project is to unify this into a simple command line driven system that works seamlessly.
The current git repository is at this link.
I'm still very much in the alpha stage of this project, but there's definitely potential for having a student work on a few parts of the project.
I'd prefer to use ebuilds rather than spec files, but unfortunately neither portage nor any of the alternatives that use ebuilds (pkgcore/paludis) don't have support for building binary packages yet. However, I am going to look into that.
Some of the parts are already in place, but more work needs to be done in order to fully support internationalization.
Build a Drupal module to allow Drupal to become a fully-featured OpenID server that supports the full OpenID 2.0 specification.
The value of the public fossology repository would be enhanced considerably if it could refer other data sources, like Krugle, Ohloh, Swik, SourceForge, etc. For example, FOSSology queries could use Ohloh tags, or report Ohloh development cost, or SourceForge rank. These wouldn't replace those other repositories, but complement them and link to them for more indepth data that they provide.
A big need we have is to figure out how to do a static dependency analysis. For example, download a project from sourceforge and by analyzing the files, figure out what packages or libraries the code depends on. The depfind project, http://depfind.sourceforge.net/, tries to do something similar for Java. It would be great to have a dependency analyzer for C, C++, etc.
There are multiple uses for such an analysis. For example, linux distributions could use it to make sure that their package dependencies are correct. FOSSology, would use this for vulnerability tracking. For example, if library A has a vulnerability and program B uses library C, but library C depends on A, then B depends on A and B may have the vulnerability.
Take a project from sourceforge (or wherever) and looking at the project files, try and figure out the degree of internationalization.
Relate vulnerabilities from the national vulnerability database (http://nvd.nist.gov/home.cfm) to files in the fossology repository.
Relate cyber alerts (http://www.us-cert.gov/cas/techalerts/) to files in the fossology repository.