WinLibre is an open source project aimed at popularizing Open Source software.
WinLibre is a META-project that was originally targeted for the windows platform (hence its name) but it has evolved during the last 3 years to embrace also the Mac OS and Linux platforms. We are focusing on delivering to our users quality open source software with a strong emphasis on ease of use. We are mainly maintaining WinLibre (open source software distribution for windows) and MacLibre (open source software distribution for Mac OS X).
The Winlibre distribution provides a collection of first-class open-source software bundled in a easy single installer & updater. Through time and thanks to the former editions of the Google Summer Of Code, the Winlibre project has evolved and created other sub-projects to fill gaps in the open-source desktop software offering. The Maclibre distribution is an equivalent to the Winlibre distribution for Mac OS.
The student application period begins Monday, March 23, 2009, and ends Monday, April 4th. Accepted students will be known on April, 20th.
You can find more information on the time line on the GSoC page
We will proceed to a phone or video interview between April, 4th and 11th in order to help us select student’s applications. Please be available during this interval.
Student Signup http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants
The ideas listed on this page are just that - ideas. They are deliberately somewhat vague, because you are meant to fill in the details.
Last year there were too many proposals that were simply cut-n-pasted from our ideas page.
Don’t do that! If you do, you will be tossed out very early in the application sorting process.
In other words - sell yourselves in this Wiki - and link your proposals with the project idea.
Do I have to use one of the ideas?
Definitely not! These are here to get you started, and because some folks think it’d be great to see them done.
If you have your own idea, run with it. We’ll judge applications on their strengths, not on who wants the project done or who thought of it.
If you (as a student) find an idea you like, we ask that you create :
Here are a few documents (written by the Drupal and PostgreSQL teams, but applicable to Winlibre) that could help you in writing your application :
| Drupal's Write a SoC application | Drupal's Student requirements | PostgreSQL: Advice to Students on Submitting SoC Applications | Good example we got years ago (Thanks Pawel) |
If you any question contact us:
This is our main project. It will be splited into three proposals.
| Primary Contact | Licence | OS | Language |
|---|---|---|---|
| Bertrand Cachet | GPL | Multi OS | Python |
We want to develop a package management system for Windows in order to facilitate the deployment of Open Source applications on Windows systems.
In deed there is no application of that sort onto Windows platform. Nowadays, users need to find the application on the web, download/install/keep it updated by themselves. Moreover, there are a lot of different way to manage applications on the Windows platform. End users need to know all of them.
Package manager will be in charge of displaying informations about available packages to the user. User will be able to install/upgrade/remove the application he has selected. End user will manage his/her applications from this single tool.
Our package manager will be able to handle dependencies between packages. That will ease the deployment of applications on Windows platforms because developers will not need to keep a watch on the libraries they use anymore.
The package manager ecosystem is divided into several parts. We have decided to create one proposal for each of these component. One student will be working on each sub-system. They will cooperate intensively during the whole summer in order to build a fully functional package management system.
Each sub-system (Repository, Package Manager, Package creator) consist in a peculiar proposal.
This is the place where all the informations about software will be stored and display. All these informations will be available to package manager in two ways:
* Global: A list of the names, versions and descriptions of the available applications for the platform.
* Specific: The specific information for a given application: URL of the binaries, URL of the developer web site, dependencies, ... which will be used to install/remove/update the application itself.
Anyone can access to this website to get information about packages, rank applications, leave comments ...
Only developers are able to update informations about the software they develop. They can do it using the web interface or by POSTing a package to the URL associated to their application. The second mode will be used by package creator to push new release on the repository.
We will need a way to make it impossible to post a new package that contain viruses and/or content that is not wanted. We need to have a look to repositories like http://pypi.python.org/pypi to understand how do they proceed.
We will need to provide different ways to access to the list of available packages. We may want to get the complete list of available packages, or the list of the packages that have been updated since a given date or just the list of a given category ... All the work will be done easily with the help of database request and it will help us to limitate the amount of data exchanged with the server.
To resume, we want a repository (place where we get info from available packages and packages themselves) and also features like the ones on http://www.kde-apps.org/
Application used to search/install/remove/update applications on the user’s Windows system. It will handle software dependencies will install all the libraries/applications needed by the software to run properly. User will interact with application using CLI or GUI.
Package Manager is divided in two parts:
* One will install/remove/update application using the package file. We will call it the Package Installer.
| wpkg *action* <package> | Install/remove/update software described into package file. wpkg will use scripts located into the package and will use/download binary representation of the application |
| wpkg *status* <package> | Get stattus of the package. Possible output:Installed/Not Installed/Update Available. |
| wpkg *show* <package> | Show information about package. It will output: name, description, license and so on. |
* Another one will search/download packages from repository. It will also handle dependencies. We will call it the Package Manager.
| wpckgmgr *update* | Updates package lists. Get last package list from repository. |
| wpckmgr *action* <name> | Install/update/remove package. Handles dependencies. |
| wpckgmgr *search* <keyword> | Search through name/description of packages. Outputs names of packages whose name or description fits the keyword |
| wpckgmgr *show* <name> | Outputs information about package. It outputs even if package wasn’t installed or downloaded. Manager gets information from package list. |
As we decided to use the SMART library, we already have the Package Manager. We only need to develop a Package Installer which will handle MSI, InstallShield, Inno Setup, Nullsoft packages and the associated backend for the smart library.
In a first time we will reuse the existing SMART interfaces: GTK, QT, CLI.
User will select the application to install using the graphical interface he wants (GUI or CLI), SMART will search for this package in the list of available packages (that it gets from the repository). If it find a package that match the search then it will download this package and all the needed dependencies. When SMART gets all the needed packages it will call the Package Installer to install it.
We only need to develop this Package Installer.
Our Package Installer should be able to:
To do that, we will need to know how to:
We cannot fully automize this kind of tasks, so we will develop modules that ease the writing of a script that will specific to one software installation. Into each package we will have several scripts to: enumerate (does software already installed), install, remove, update applications.
For example a enumerate script will look like:
from registry import exist, read
def is_installed():
return exist('ARegistryKey')
def get_version():
return read('ARegistryKey')
We will only install packages that have been created with our Package Creator: they will contain: a file describing the software itself (XML file), scripts like explained previously. Binaries of the application can be integrated to the package or not. Everything will be noticed into the package description file. For example and URL with :http: indicate we will need to download it but a package: URL indicate that binaries are included into the package itself.
This tool will be used by the software developers to upate informations about their packages onto the WinLibre repository.
Developers will give informations about their application (name, version, description, dependencies, binaries) to the Package Creator which will create the package and also upload informations to the repository.
The aim of this tool is to ease the deployment of applications onto Windows platform. Most of the open source projects use the same libraries. On POSIX system they only provide a binary of their applications and give a list of the libraries they depend on. Package Manager like *ports*, *apt*, *rpm* handle the dependencies for them. On Windows, most of the time, they add to their installation a binary representation of the libraries they use because they need to apply some patch on them in order to make them Windows compliant. That means that each Open Source organization has it’s own patch for the same libraries. All these patches are a redundant work which can be skipped if we are able to create packages of these patched libraries and handle dependencies.
That’s this problem that we want to solve with our Package Creator. We would like to have a common repository where a package of all the common libraries can be found so that Open Source organization can link them dynamically just by providing the list of libraries the depend on.
Main goal is to handle dependencies for developers. We will write tutorials to help developers link DLL dynamically which is not so easy on Windows. But providing some guidelines will help developers to enjoy the fact that they will not need to support libraries they use. Of course, these tutorials will no be written by the students but by ourself with the help of other developers.
These are technologies we may use during our development
We will use SMART (http://labix.org/smart) motor to perform all the tasks of finding/downloading packages, handling dependencies, displaying informations about packages. Currently backends for Debian, Suse, Fedora, Mac OSX .. already exist.
We need to develop a SMART backend for Windows platform that mean a tool that will be able to install/remove softwares contained into MSI, NSIS, NullSoft packages.
In a first time we will use the existing GTK/QT interfaces from SMART library. If we have the time, we will adapt the existing one or develop a new one.
It’s a RESTful web application where each URL represent a package:
* GET access is public and can return JSON, YAML or HTML formats. GET access will be used by WinPacMan client to get information about the package.
* POST, UPDATE and DELETE access are protected (authentification via OpenID or Google Account). These access are used by the Package Generator Tool to update information about the package.
We plan to develop it on appengine to be scalable.
They will contain: a file describing the software itself (XML file), scripts that can be used to install/remove/enumerate the application. These scripts will be developed by the developers and us using all the tools we will develop to simplify this process like explained into the chapter about package manager. All the default installers (MSI, NullSoft, InstallShield) will be handled automatically,in these cases, scripts can be more or less empty.
Binaries of the application can be integrated to the package or not. Everything will be noticed into the package description file. For example and URL with :http: indicate we will need to download it but a package: URL indicate that binaries are included into the package itself.
We propose three proposals that belong to the same global project. Each part of this project will interact with others:
Each part of the project can be developed individualy, we just need to define:
We think we can use the following file format for our project: http://xtreeme.org/xpkg/. We will define precisely all the needed file format and the content of a package before the beginning of the GSoC so that students can be independent.
We want to share as much code as possible between project. We will try to develop every part of this global project from the same repository folder. Maybe we will add branches if needed but Repository, Package Manager and Pacakge Creator will be contained into the same project.
We will setup all the needed directories and tools before the beginning of the GSoC. We want such an organization to force students to interact with each others and communicate about what they implement. It’s really important even it is not easy to work on a same project at the same time.
| Primary Contact | Licence | OS | Language |
|---|---|---|---|
| Pierre-Jean Coudert | GPL | Multi OS / Qt | Python |
http://www.pwytter.com/ : Twitter client, Multi-OS, Python, GPL
| Primary Contact | Licence | OS | Language |
|---|---|---|---|
| Pawel Solyga | GPL | Mac OSX | Python |
MacLibre has been an outstanding success of former Summer Of Code editions. We would like you to help this project going even further with its third version...
Here are some of the enhancements we would be glad to see in MacLibre v3. Of course any other great ideas are welcome and encouraged!
Most important features of admin tool:
| Primary Contact | Licence | OS | Language |
|---|---|---|---|
| Julien Marbach (jumar) | GPL | Multi OS | mono/c# |
This is an open proposal, applicants are encouraged to add their own ideas as far as the main goals are respected.
On the windows platform there is currently no high quality open-source GPS management software. To review, display, backup their GPS data most users must use the proprietary software shipped with their device (Like MapSource for Garmin GPSs). Those software are very poor in terms of usability, responsiveness and overall quality. What we would like to see developed during this summer of code is a fast and easy to use GPS data management software with the ability to visualize GPS tracks and waypoints and display maps from online and/or local databases.
We would like to focus on the quality of the basic features before adding bells and whistles to the software. Implementing “Trendy” features like photo geotagging or social networking abilities are not the main goal of this project but may be considered when a solid code base will be done.
Write a new, innovative, multiplatform, windows compatible, easy to use desktop application.
If you want to create a brand new, innovative application, write and submit a proposal.
Note : Before submitting your idea(s) please be sure that no other Windows open-source alternative already exist (in terms of functionality, quality, ease of use...). Intensive Google searching will help you at this point.