Lecture on “Jailbreaking the Forges : project export/import efforts”

I’ll be speaking next week‘ve been at Open World Forum, in the OSDCfr track in with a speech titled “Jailbreaking the Forges : project export/import efforts”

Here are the slides (as PDF – 1.3 Mb)

Here’s a copy of the presentation I wrote.

Software forge are “data jails” in that development projects established in a forge may suffer from data lock-in if they have to, or want to, change of hosting solution.

Some of the tools allow easily to fork or move a project’s code (such as DVCS like Git, Bzr or Hg), but for other tools like bugtrackers, mailing-list managers or wikis, it’s much harder to extract data from one forge and transport it to another one. Also, users and their privileges, as well as many other metadata (who did what, and when) may suffer from such migrations.

Even though most projects don’t fell such lock-in as a high risk (even in FLOSS projects which value freedom of information, strangely), history as shown that in case of outages, hosting platforms can be quite a trap to projects.

Other hazards may happen, like unresponsive admins, forks in a community, archiving old projects while being able to restore them, do migrations, or just the wish to move to newer, cooler hosting platforms.

Despite 10 years of forge usage, it is only recently that few progress have been made in implementing standard exchange data formats and supporting tools, allowing us to envision a possible solution to these lock-in issues.

We’ll present the ForgePlucker project (initially started by esr after a few popular blog posts on the subject), and further efforts lead in the COCLICO project to provide an open and extensible standard exchange format for projects data export and import. In addition to forgeplucker, we’ll demonstrate the FusionForge import tools used as an archive/restoration mechanism.

We’ll then call for other forge implementors and advanced users to join us, for more efforts on this topic, in order to gather all the tools that are needed to make possible migrations of projects from forges to forges.

OAuth support in FusionForge, and the forge can tweets

We have been working in the frame of COCLICO on implementing support of the OAuth protocol, both as an OAuth provider/server (for instance for the needs of authentication to the OSLC server‘s Web Services), and an OAuth consumer/client.

That OAuth consumer has been put to work in order to connect to twitter’s API, so that the forge is now able to push news to tweeter and other IM services.

OAuth will, beyond twitter, allow the forge to interoperate with other web services supporting connections on behalf of users, instead of using fake accounts, or storing passwords in the databases.

All these are committed in FusionForge’s SVN trunk.

Dynamically querying external (sub) projects properties with RDF in FusionForge

I’ve been working recently on two plugins for FusionForge. The work is somehow a POC for some COCLICO dynamic interoperability work-package, but some outcomes may actually be of use someday in real life, who knows 😉

The first plugin is called extsubproj, and allows the definition of links to external subprojects (i.e. hosted on another forge), in the properties of a FusionForge project. It’s basically managing a set of stored URLs and displaying them in the top project’s summary page. Nothing fancy, so far, and the code is not yet finished, nor pushed to FusionForge’s trunk yet.

The second plugin, called doaprdf, allows the publication, by the forge, on the same URL as the project summary page (those URLs are standardized in FusionForge in the form : http://.../projects/projname), of a RDF+XML description of some of the project’s metadata, using the DOAP dialect. This works with content-negotiation, following principles of the Linked Data paradigm, so that the same URL, when requested for HTML, renders a Web page (the forge project’s summary page) meant for humans^geeks, and when queried with a special content type Accept HTTP header (Accept: application/rdf+xml), meant for machines.

Now, when you combine these two, you gain the possibility of having extsubproj display not only the suprojects’ URLs, but also some of their meta-data, for instance a link in the form of <a href="http://.../projects/projname">fetched doap:name</a>.

The POC illustrates how one may then construct a hierarchy of (public so far) projects and sub-projects accross the buondaries for different forges databases, and display them in a similar manner as local projects (for instance, what the FusionForge plugin projects-hierarchy provides), through dynamic query of the remote project’s properties fetched on demand and modeled in a generic dialect (RDF with common ontologies such as DOAP).

Note that a similar FusionForge plugin “foafprofile" is being developped too for users profiles, using RDF and FOAF.

Stay tuned for more content in the same vein.

Forges mutualisées, dans le rapport “L’industrie du logiciel”

Je viens de parcourir l’excellent rapport sur “L’Industrie du Logiciel” (en France : une analyse et des propositions pour l’enseignement et la recherche).

Il contient, entre autres sujets de réflexion et propositions, une analyse des modes de financement des forges de développement de logiciel du monde académique.

Je vous livre l’extrait en question (ai replacé les liens en notes de bas de page comme des liens dans le texte):

6.3 Des modes de financement des infrastructures de recherche peu adaptés au logiciel

Dans l’effort actuel de financement de la recherche, certains instruments ont été conçus pour soutenir des investissements importants dans des infrastructures collectives en se basant sur le modèle issu des grandes installations de la physique ou de l’astrophysique. L’État alloue des crédits exceptionnels, parfois considérables pour financer la construction d’un grand équipement de recherche (un accélérateur de particules, un télescope, …) laissant aux “opérateurs de la recherche” (CNRS notamment) le soin de recruter et d’affecter le personnel qui va l’utiliser.

Ce modèle d’intervention de l’État est inadapté pour financer les “forges à logiciel” modernes qui sont indispensables aux grands développements collaboratifs des technologies logicielles de demain. En effet, la part principale de coût de ces infrastructures est le coût des personnels. En particulier, elles ne trouvent leur pleine efficacité que si des ingénieurs de recherche en nombre suffisant y sont affectés, permettant de finaliser et professionnaliser les prototypes logiciels, de maintenir les outils et plateformes logicielles de développement et de former les utilisateurs nouveaux entrants.

L’essor du Cloud Computing permettrait par exemple de construire des forges ou des centres de données mutualisés qui réduiraient énormément les couts et augmenteraient l’efficacité du développement, mais des initiatives de ce genre n’entrent pas dans la définition des infrastructures de recherche actuellement financées, les montants d’investissement étant trop faible, et la part de fonctionnement trop importante.

Les forges existantes fonctionnent plus ou moins en vase clos. La forge du CRU accepte par exemple la création de projets venant de l’ensemble des universités, mais elle refuse les projets étudiants et fonctionne à l’intérieur du monde universitaire, sans ouverture réelle sur le monde des entreprises. La forge de l’INRIA est une des plus significatives de France, et elle rend un service appréciable aux équipes propres ou associées à cet institut.

Le besoin de créer une forge au niveau du CNRS a été exprimé formellement et une proposition de réfléchir à une forge au niveau enseignement supérieur et recherche existe aussi .

Ces outils existants et ces projets ne prennent pas (ou imparfaitement) en compte les besoins d’articulation entre le monde académique et celui des entreprises pour faire éclore les innovations technologiques logicielles ; ils ont aussi tendance à oublier que le développement collaboratif est un besoin qui ne se limite pas au code, mais se retrouve aussi dans l’écriture de documents techniques.

L’innovation logicielle prenant place dans des “écosystèmes” décloisonnés, ces forges doivent être accessibles à tous les acteurs d’un développement innovant, chercheurs d’organismes différents, PME partenaires, pôles de compétitivité, etc.

Laisser le soin aux opérateurs (CNRS, INRIA, CEA, universités) de déployer séparément de telles infrastructures sans que celles-ci ne soient mutualisées est donc contre-productif.

Il serait très préférable d’avoir une structure mutualisée offrant des « vues » spécialisées par types de développements (par ex.: mondes virtuels 3D et jeux, internet d’objets, etc.) ayant des besoins différents, mais ouvertes à tous les acteurs concernés, et qui puissent :

  • héberger non seulement le développement collaboratif du code, mais aussi de la documentation technique associée, voire même l’écriture collaborative d’articles scientifiques dans le domaine ;
  • prévoir explicitement l’hébergement de projets étudiants, et leur possible évolution dans le temps vers un cadre plus institutionnel ou international ;
  • prévoir explicitement un lien et un échange de métadonnées avec les autres forges, notamment industrielles ou internationales ;
  • permettre de suivre l’activité des contributeurs dans le temps, ce qui peut aider les étudiants à constituer facilement un bilan objectif de leurs compétences logicielles pour leur curriculum.

La mutualisation ne vise pas seulement à partager les coûts des investissements matériels (assez modestes si l’on utilise des serveurs virtualisés), mais surtout à mutualiser ces compétences qui à terme forment une part essentielle de la valeur de ces plateformes communes. Dans cet esprit, il nous parait souhaitable que l’alliance ALLISTENE, en liaison avec les pôles de compétitivité, organise une réflexion sur la création et le fonctionnement d’une ou plusieurs forges nationales, fédératives et ouvertes à tous les acteurs concernés, et la mise en place, indispensable, d’un programme de recherche multidisciplinaire sur les environnements collaboratifs qui guide l’évolution dans le temps de ces forges.

Proposition n°12 : Confier à ALLISTENE, en liaison avec les pôles de compétitivité, une mission de préfiguration d’infrastructures de développement collaboratif, adaptées à un type de développement particulier, et dotées des moyens nécessaires en personnel pour mener leurs activités de manière pérenne.

Bien évidamment, l’analyse me semble très pertinente, et la proposition me semble aller dans le bon sens, même si je ne sais pas si ALLISTENE est le meilleur porteur pour cela.

Integrating JUnit tests inside a PHPUnit+Selenium test suite

I’ve spent some time recently integrating the OSLC open source test suite (from the OSLC open source support project)into the FusionForge test suite.

FusionForge‘s test suite uses PHPUnit to drive Selenium (RC) “end user” like tests. Selenium is a tool that makes such tests possible by piloting an instance of FireFox browsing the Web interface of the forge, in a controlled environment.

The OSLC test suite consists in a series of JUnit tests, which is driven by Maven (initially started from inside Eclipse, then also from command-line after I found the nasty command line parameters and changes in the pom.xml file that were required ;).

The whole of the test suite may not pass for our implementation of OSLC-CM in FusionForge, so some tests fail, but I don’t bother too much as this is “normal”, and all we’re caring for at the moment is mainly non-regression. There seemed to be no way to exclude some of the tests from the suite for the moment, but fortunately, that doesn’t matter, since the way I have integrated both test suites happens to allow the verification of only success on some of the tests.

So, the way they are integrated is through execution of the JUnit suite during one of the test cases of the Selenium suite (using a system( ) PHP call), which generates an HTML report (using the Maven SureFire reports plugin), which can then be viewed in the Web pages of the tested forge, so that Selenium + PHPUnit assertions can verify the content of the test report.

This is a bit hackish, but all in all suites our needs so far. Next step is to see if it works in other people’s test environments, including the automated executions in Hudson.