Planet Forge

There will be some interesting content (I hope) about forges at the forecoming Open World Forum, on the first days of december, in Paris. Besides the higher education track I already blogged about, the Qualipso project organizes its second conference during the forum.

There should be some presentation of the first results of the Qualipso forge, so I’m expecting interesting things to be shown and fruitfull discussions.

The OSOR project will be around also, and some participants of our french community of forgerons, and contributors to the planetforge aggregator.

Looking forward to meet you there.

Part of our work in the Helios project will be on bugtrackers synchronisation.

I happened to notice that bts-link’s maintainer called for help, which triggered more interest in that tool.

I’ve started working on bts-link to see how it works (cool, it’s Python and if it can be useful for Helios, and started implementing GForge tracker support in bts-link. That should help keep track of Debian bugs wrt upstream bugs for projects hosted in GForge forges (like Sympa, for instance, whose bugtracker is hosted in SourceSup).

You may find my git repo at http://www-public.it-sudparis.eu/~berger_o/git/bts-link.git which hopefull contains my proposed changes (I’m new to git, so I hope I did everything right…).

Important security patch for GForge 4.5 - patches database.php SQL injection vulnerability

J'ai l'immense honneur de figurer dans les pages de l'illustre magazine 01 Informatique de cette semaine, dans un encadré en marge d'un article sur les forges déclenché par une actualité (Sun a sorti une forge). Wouhou, c'est la gloire, je suis devenu un people et les statistiques de fréquentation de mon site pro autant que de ce blog vont exploser, et je vais être courtisé par les décideurs qui lisent 01 !

Je saisis donc l'occasion pour apporter quelques rectifications à cet article de Yann Serra.

• Ne vous fiez pas au titre de l'encadré (« 2 questions à Roland Mas »), ni aux guillemets : il ne s'agit pas de questions qui m'ont été posées, ni encore moins de citations de mes réponses.
• Apparemment je n'ai pas assez insisté lors de l'entretien téléphonique sur le fait qu'une forge est une plate-forme collaborative, pas juste un site de téléchargement. Du coup, la première question perd tout son sens (ce qui explique que la « réponse » supposée soit confuse.
• Sur la deuxième « question »... la réponse qui m'est attribuée ne répond pas à la question, et pour cause : Sun n'a jusqu'à présent fait que des annonces sur ce qui différencie Kenai des autres forges. “We're more than just a forge”, mais on ne sait pas quoi. “More about these features will be revealed as we get closer to their availability.” Difficile donc de juger sans savoir.
• Je n'ai pas non plus assez insisté sur l'aspect Ruby, visiblement. Ma position là-dessus est que les choix d'implémentation de Kenai n'ont pas la moindre espèce d'importance sur le succès de la forge kenai.com tant qu'elle est uniquement hébergée par Sun. Ce serait du Cobol ou de l'Intercal que ça ne changerait rien. Ils ne deviendront pertinents que si le logiciel Kenai est publié sous une licence libre, parce qu'ils constitueront, ou non, des barrières à l'entrée pour des contributeurs potentiels qui feront vivre la communauté.

Je ne crache pas sur le journaliste, ç'aurait pu être bien pire. Je suis juste déçu que mes propos aient été complètement réinterprétés, et je déplore ouvertement que l'article laisse entendre que Sun ait relancé une quelconque bataille, alors que pour l'instant rien ne différencie dans le bon sens Kenai d'une autre forge.

Mais bon, je suis un people, il faut que je m'y habitue, pour être préparé le jour où on me fiancera à Grace Kelly ou à la Castafiore. En attendant, vous pouvez trouver des paquets Debian de GForge sur http://people.debian.org/~lolando/. Avec les autres people.

J'ai l'immense honneur de figurer dans les pages de l'illustre magazine 01 Informatique de cette semaine, dans un encadré en marge d'un article sur les forges déclenché par une actualité (Sun a sorti une forge). Wouhou, c'est la gloire, je suis devenu un people et les statistiques de fréquentation de mon site pro autant que de ce blog vont exploser, et je vais être courtisé par les décideurs qui lisent 01 !

Je saisis donc l'occasion pour apporter quelques rectifications à cet article de Yann Serra.

• Ne vous fiez pas au titre de l'encadré (« 2 questions à Roland Mas »), ni aux guillemets : il ne s'agit pas de questions qui m'ont été posées, ni encore moins de citations de mes réponses.
• Apparemment je n'ai pas assez insisté lors de l'entretien téléphonique sur le fait qu'une forge est une plate-forme collaborative, pas juste un site de téléchargement. Du coup, la première question perd tout son sens (ce qui explique que la « réponse » supposée soit confuse.
• Sur la deuxième « question »... la réponse qui m'est attribuée ne répond pas à la question, et pour cause : Sun n'a jusqu'à présent fait que des annonces sur ce qui différencie Kenai des autres forges. “We're more than just a forge”, mais on ne sait pas quoi. “More about these features will be revealed as we get closer to their availability.” Difficile donc de juger sans savoir.
• Je n'ai pas non plus assez insisté sur l'aspect Ruby, visiblement. Ma position là-dessus est que les choix d'implémentation de Kenai n'ont pas la moindre espèce d'importance sur le succès de la forge kenai.com tant qu'elle est uniquement hébergée par Sun. Ce serait du Cobol ou de l'Intercal que ça ne changerait rien. Ils ne deviendront pertinents que si le logiciel Kenai est publié sous une licence libre, parce qu'ils constitueront, ou non, des barrières à l'entrée pour des contributeurs potentiels qui feront vivre la communauté.

Je ne crache pas sur le journaliste, ç'aurait pu être bien pire. Je suis juste déçu que mes propos aient été complètement réinterprétés, et je déplore ouvertement que l'article laisse entendre que Sun ait relancé une quelconque bataille, alors que pour l'instant rien ne différencie dans le bon sens Kenai d'une autre forge.

Mais bon, je suis un people, il faut que je m'y habitue, pour être préparé le jour où on me fiancera à Grace Kelly ou à la Castafiore. En attendant, vous pouvez trouver des paquets Debian de GForge sur http://people.debian.org/~lolando/. Avec les autres people.

We’re seriously considering switching from phpGroupware to eGroupware for some infrastructure needed for a picoforge-based platform that we need to deploy soon.

phpGroupware is unfortunately kinda dead these days, whereas eGroupware seems to have managed to keep some momentum.

Of course we had preferred keeping with phpGroupware when the two projects initially switched apart, in particular because the GNU project-linked QA/copyright policies were a guarantee that our contributions may be better protected in such a collaboration environment (we tried and help the phpGroupware as much as we could, btw, and parts of this history is told when looking at : http://www-public.it-sudparis.eu/~berger_o/weblog/tag/phpgroupware/).

But the copyright policy is not all about successful collaboration, and it happens that phpGroupware fails to deliver from quite a few months now. Btw, I’m not so close to the project to tell exactly what’s happening and why, but looking at the mailing-lists, at least, the situation looks very bad.

So I dare say it lound : the phpGroupware project is quietly dying (at least from my point of view).

But as we need some improvements that were initially planned for its 0.9.18 release (filemanager, accounts, various stuff I’m not really qualified to list completely)… we need to consider what the options are…

And fortunately, it looks like eGroupware has not forked in a too much differing way, from a technical point of view, and that they have even improved some of the things we expected to be coming from phpGroupware 0.9.18.

So it’s very much likely that we’re going to try and switch to eGroupware for some parts of the platform to be deployed in the next month.

This may not concern the whole of the PicoForge infrastructure but only a particular project that builds on top of the current PicoForge infrastructure, with some variations.

As for the future of PicoForge as the libre software forge, it’s not really clear what’s gonna happen, but I think that we may be making a more radical switch some day, for instance by forgetting the old legacy PHP code, and so neither depending on phpGroupware nor eGroupware, but using some more modern tools/frameworks (and why not something like Tine 2.0 ? … no, but we may be inspired by some of its characteristics ;).

Qui vivra verra.

We have presented a paper at the WopDasD 2008 workshop (right after the OSS 2008 conference) in Milano, explaining how RDF could be used to propagate semantically tagged information from the forges to the “repositories of repositories” collecting facts on open-source projects, and advocating to tighter integration of the forges and the research analysis tools.

I was glad that another presentation was made by Kevin Crowston for a paper written by James Howison about the use of RDF semantic schemas to bring more interoperability between the various repositories of repositories (Update 2008/09/22 : slides here). Btw, they explained what RDF is in the slides just before me, so I got more time to talk about the rest

Also quite interesting was the presentation made by Andrea Wiggins for their paper about the workflow for scientific analysis in these repositories of repositories. I guess there’s some momentum towards more interoperability and more integration here. Maybe some web services could interoperate between what’s on the forges and what’s on the repository of repositories.

Weller, Martin J. and Meiszner, Andreas (2008) Report on the effectiveness of a FLOSS-like learning community in formal educational settings. Project Report. The Open University, Institute of Educational Technologies - UK, Milton Keynes, UK. Available from http://flossplanet.org/382/.

We have setup a collaborative maintenance project named pkg-cas for Debian.

The goal is to have more packages available in Debian to be able to use the CAS SSO (Single Sign On) framework for web applications.

More details at : http://wiki.debian.org/Teams/DebianCASPackaging

Feel free to join !

Please read this file and apply if you downloaded GForge 5.5rc1 or 5.5rc1a and are experiencing any issues.

We’ve been setting-up the codename HELIOS project, together with other partners (lead by Thales), which got funded recently, as part of the pôle de compétitivité System@tic (libre software thematics).

That means that our PFTCR team at Institut TELECOM will be able to do more research around infrastructure and process of production for libre software projects.

Among the things we’ll focus in particular in this 2 year project, is the topic of traceability between bugtrackers (WP3). This topic seems quite interesting to many people I’m talking to at the moment in libre software projects (as discussed recently at RMLL/LSM) : good

I hope we’ll be able to help improve the current state of the art where lots of manual synchroniation is done in libre software (between upstream bugtrackers and distributions’ ones, for instance), and deliver useful tool to the communities.

We’ll keep you posted as the project moves on (scheduled kickstart september 2008).

For more details (in french), you may see the brochure (page 4) at System@tic’s site.

Update 2008/09/17 : here’s the official description of the project we’ve just drafted :

HELIOS is a project related to the System@tic research cluster. The aim of the project is to provide an Open Source ALM (Application Lifecycle Management) portal allowing to test, integrate, configure and maintain the many components of an application. HELIOS must be flexible and extensible enough to adapt to any tool with limited developpements in order for the users to keep on using their own tools. In the same way, flexibility and extensibility should allow services providers to build commercial offer. Most of existing ALM tools are specialised into one particular field (requirements management, qualification, project management, …) but the HELIOS project will aim at providing a complete platform covering activities from qualification to maintenance.

We’ve been setting-up the codename HELIOS project, together with other partners (lead by Thales), which got funded recently, as part of the pôle de compétitivité System@tic (libre software thematics).

That means that our PFTCR team at Institut TELECOM will be able to do more research around infrastructure and process of production for libre software projects.

Among the things we’ll focus in particular in this 2 year project, is the topic of traceability between bugtrackers (WP3). This topic seems quite interesting to many people I’m talking to at the moment in libre software projects (as discussed recently at RMLL/LSM) : good

I hope we’ll be able to help improve the current state of the art where lots of manual synchroniation is done in libre software (between upstream bugtrackers and distributions’ ones, for instance), and deliver useful tool to the communities.

We’ll keep you posted as the project moves on (scheduled kickstart september 2008).

For more details (in french), you may see the brochure (page 4) at System@tic’s site.

Update 2008/09/17 : here’s the official description of the project we’ve just drafted :

HELIOS is a project related to the System@tic research cluster. The aim of the project is to provide an Open Source ALM (Application Lifecycle Management) portal allowing to test, integrate, configure and maintain the many components of an application. HELIOS must be flexible and extensible enough to adapt to any tool with limited developpements in order for the users to keep on using their own tools. In the same way, flexibility and extensibility should allow services providers to build commercial offer. Most of existing ALM tools are specialised into one particular field (requirements management, qualification, project management, …) but the HELIOS project will aim at providing a complete platform covering activities from qualification to maintenance.

We (Vu, Christian, Sang and me) have written a paper which was accepted for the fore-coming WoPDaSD 2008 workshop (3nd International Workshop on Public Data about Software Development), later this year in Milano.

Here’s the abstract :

Improving community awareness in software forges by
semantical aggregation of tools feeds

It is rather difficult to monitor or visualize what can be the
contribution of a member in a project, especially when the
project uses multiple tools to produce its results. This is the case
for collaborative development of FLOSS software, that use Wiki,
bug tracker, mailing lists and source code management tools.
This paper presents an approach to data collection by using
aggregation of feeds published by the different tools of a software
forge. To allow this aggregation, collected data is semantically
reformatted into Semantic Web standards: RDF, DC, DOAP, and
FOAF. Resulting data can then be processed, republished or
displayed to project members. We implemented this approach in a
supervision module that has been integrated into the PicoForge
platform. This module is able do draw a live graph of the social
community out of the different sources of data, and in turn export
semantic feeds for other uses.

I hope we will be able to confront this approach to others’ in order to see if this is a valid strategy to enhance the use of the forges and better interoperate between tools.

Update 2008/09/10 : the paper is now online.

… and the slides are now online on the workshop site, or bellow :

There’s probably much more to say than I’ll remember, but here’s an attempt at reporting from the excellent edition of RMLL/LSM which was held in Mont-de-Marsan (France) early july.

I’ve been chairing one of the tracks, on Communautary development, where I’ve had the pleasure to chair and attend excellent presentations. The rest of the LSM/RMLL was very good too, but being stuck in a room, I couldn’t attend much of it

To summ-up, there have been very interesting talks and discussions on the following subjects (links to descriptions of talks and their slides included) :

• translations : Claude Paroz has presented the classical process of translation in libre software (gettext, etc.) and organized a practical workshop to help get contributors started. But just before his talk, Marc Laporte (aka the man paying free beers at night) presented a system which was implemented in a wiki to handle multilingual content, which seems very smart, in helping synchronize multilingual content in wikis (where individual translations may change in a non-coordinated way). I think that both talks were very complementary : great to have had both speakers there… and by the way, they proved the international nature of the RMLL (Switzerland and Quebec/Canada)
• forges : another topic was the forges, or the development environments in (potentially) large projects, with the presentation of the forges genealogy and the GForge project made by Roland Mas. It was interesting to get feedback from the audiance where people reported from their switch to GForge AS, for instance. Also a presentation by Quang-Vu Dang about the use of semantic web standards to monitor activity in forges. We also discussed the semantic web standards and interoperability after other presentations about bug-tracking or packages (more bellow). Lucas Nussbaum also presented the infrastructure of the Debian project which loosely integrates different tools which are used to monitor the activity and do the QA work in the project. Lucas’ presentation was too short unfortunately, for such a complex project in-depth review (and trolls popped-up also ;).
• packaging : Lucas also presented interesting starting elements for attracting volunteers contributions to Debian, by describing the packaging of applications in Debian (and Ubuntu, sort of ;-). Complementary were the presentations by Vincent Untz and Bruno Cornec, resp. on the OpenSUSE build service, and Project Builder, which both more or less manage the generation of packages for various distributions. Their philosophical approch seem different, which lead to interesting discussions : is upstream supposed to get interested in specifics of package contruction in various distributions, or should it be handled independently ? Great debate. There were also intersting talks about convergence in package description formats, which would need more detailed discussions (I welcome any links).
• Release process : we had three talks which addressed this topic : first the excellent (and crowded, although very early in the morning : 9:00 ) presentation by Thomas Petazzoni on the Linux project process. Next Lucas’ presentations on Debian (comparing release strategies between Debian and Ubuntu, for instance). And finally Vincent Untz’s other presentation on the 6 month paced release process in Gnome. Very complementary and interesting talks, IMHO.
• Bug tracking : Of course this was the topic addressed by Emmanuel Seyman in his very interesting talk about Bugzilla. But we also discussed the subject of bug trackers in Lucas’ presentation, for instance (with the Debian BTS), or when we discussed the problem of synchronisation of the bugs lists between upstream and distributions (which will be one of the topics of our forecoming HELIOS project : more blogging ahead). Definitely something where the contacts were very valuable amond people attending and presenting.
• Other topics : well, that wasn’t all with this track at LSM/RMLL, but I wasn’t as much interested in these others I guess. You’ll find more details on the conference’s site.

I hope the content was enjoyable to the audiance too (although I disturbed the presentations with my silly jokes or my facist approach to schedules ;).

See you in next edition.

Quick status update: not much happened due to a variety of reasons, but there is still some progress to report.

The most important piece of news is that the Mediawiki plugin should be on its way to Debian sid by the time you read this, as the new gforge-plugin-mediawiki binary package (it'll have to go through NEW, but that seems to be rather fast these days). Testing and reporting and bugfixing are most welcome, of course.

I also went through a round of cleanups in the packaging. No more Lintian overrides, far fewer Lintian errors and warnings, and some fixes for PostgreSQL 8.3 compatibility.

deliverable D7.2.1 of the qualipso project, documenting the state of the art for forges

 Bookmark this on Delicious - Saved by olberger to forge SoftwareForge qualipso gforge - More about this bookmark

Agrégateur de feeds sur les forges

 Bookmark this on Delicious - Saved by olberger to SoftwareForge forge - More about this bookmark

Site de ressources sur les forges logicielles

 Bookmark this on Delicious - Saved by olberger to SoftwareForge forge - More about this bookmark

Forge based on GForge and other tools

 Bookmark this on Delicious - Saved by olberger to SoftwareForge forge gforge - More about this bookmark

Voici quelques nouvelles de GForge en français, pour changer, parce qu'il y a visiblement un fort contingent d'utilisateurs francophones de GForge. Si le blabla ne vous intéresse pas, sautez quelques paragraphes, y'a une annonce qui peut vous intéresser.

Je m'en doutais un peu à vrai dire : je savais déjà qu'il y avait des instances de GForge en usage dans un certain nombre d'entreprises et d'administrations françaises. Je déplorais d'ailleurs que ces usages soient privés, voire secrets... On n'en entendait parler que par la bande, au détour d'une conversation. Et chacun avait ses bricolages locaux, et ses améliorations personnelles, dont personne ne profitait.

Heureusement, les différents utilisateurs francophones de GForge (de forges en général) ont fini par plus ou moins se retrouver, et des discussions ont commencé sur la liste Picolibre Forges. On s'aperçoit donc que de nombreux utilisateurs existent, qu'ils ont souvent des besoins communs, et que certains ont même déjà des solutions à apporter à certains de ces besoins. Il se pourrait bien que ces utilisateurs (et ces développeurs) se mettent à communiquer et à relancer une vraie dynamique de communauté autour de GForge (pour l'instant, il y a une poignée de développeurs, et quelques utilisateurs qui ne communiquent pas, donc j'hésite à appeler ça une communauté). Quelques-uns de ces utilisateurs et moi-même nous sommes rencontrés à la conférence Qualipso la semaine dernière, normalement nous devrions nous retrouver au salon Solutions Linux la semaine prochaine, et une réunion spéciale forges est même organisée après ça. Donc, ça prend forme.

Concrètement, ce que j'espère principalement est que les modifications de chacun seront partagées, de sorte qu'elles puissent être intégrées au cœur de GForge, et portées sur une version plus récente (puisque l'immense majorité des utilisateurs actuels sont basés sur une version 4.5.x patchée). Le « tronc » Subversion de GForge devrait donc intégrer, dans un futur que j'espère pas trop lointain, les évolutions suivantes :

• Intégration du bug-tracker Mantis : au moins deux (et vraisemblablement trois) entités ont déjà réalisé cette intégration, et j'essaie de récupérer les patches pour que tout le monde en profite. Pourquoi tout le monde se focalise sur l'intégration d'un nouveau tracker au lieu d'exploiter la flexibilité de celui de GForge pour l'étendre, ça me dépasse, mais je ne suis pas là pour juger. De même, je trouve vraiment dommage que ce développement ait été fait deux ou trois fois de manière indépendante et sans concertation. Vous avez dit gaspillage de temps humain ?

• Ajout d'un système d'intégration continue (on me dit « Maven »). Là encore, normalement ça a déjà été fait, il ne devrait plus rester qu'à publier les patches et les porter vers l'état actuel du code.

• C'est peut-être lié à l'item précédent (je manque de détails), mais on devrait aussi voir apparaître une intégration dans GForge d'un système de tests automatisés.

...et je ne doute pas que d'autres utilisateurs, qui ont eux aussi ajouté leurs propres fonctionnalités sans rien dire à personne, vont aussi se révéler au grand jour et collaborer avec la communauté (n'est-ce pas ?). Peut-être même que des gens vont remettre au goût du jour l'empaquetage RPM, abandonné depuis plusieurs années.

Histoire de ne pas être en reste, je fais ici l'annonce publique suivante : le plugin Mediawiki pour GForge est enfin publié. Ce plugin fait suite à une intégration faite « avec des contraintes de temps assez serrées » (comprendre « un peu à l'arrache ») pour un client, et à une autre intégration faite plus proprement pour un autre client. Le dépôt SVN de gforge.org contient donc présentement le code qui va bien, et la prochaine version des paquets Debian qui seront publiés fournira un nouveau paquet binaire appelé gforge-plugin-mediawiki. Je dispose également d'une version du plugin pour GForge 4.5.x, mais comme Mediawiki nécessite PHP 5, il faut également extraire de ma branche client la conversion PHP 4 → PHP 5 de GForge 4.5 (et en retirer les fonctionnalités réellement spécifiques au client), ce qui explique que ce n'est pas encore publié sur mon dépôt APT (ni déployé sur Alioth). J'y travaille, promis.

Je m'aperçois que quand je cause d'outils de suivi de version, il m'arrive de mentionner, en plus des standards (CVS, Subversion, Bazaar et les autres), le vénérable CPOLD. Et que souvent, mes interlocuteurs ne connaissent pas CPOLD. Et effectivement, ce n'est guère documenté dans la littérature et le web multimédia mondial. Je m'en vais donc vous présenter un peu cette formidable méthodologie de suivi de versions.

Pourquoi formidable ? Parce qu'elle ne souffre d'aucun des problèmes récurrents des autres outils :

• pas de format de fichier complexe et susceptible de corruption ;
• pas de conflits ;
• aucun besoin d'un serveur dédié (on peut tout mettre ensemble, prod et dev confondues) ;
• aucune limitation sur la gestion des branches ;
• une rapidité insurpassable ;
• une simplicité de mise en œuvre et d'apprentissage enfantine ;
• pas de modèle de développement imposé (centralisé, distribué, en quinconce, en hélice, toutes les variantes sont possibles) ;
• des sauvegardes facilitées ;
• etc.

Pour résumer, CPOLD, c'est la poudre verte du suivi de versions. Mais alors, comment ça marche ? Très simplement. Tout répertoire contenant des fichiers est déjà une archive CPOLD, pas besoin d'initialiser quoi que ce soit. Pas besoin non plus de « prendre la main » sur un fichier avant de l'éditer. Une seule commande à retenir, celle pour créer une nouvelle version de ce fichier :

cp fichier fichier.old

Bien entendu, le .old peut être remplacé par n'importe quel suffixe ou combinaison de suffixes, il suffit de définir une convention de nommage et de s'y tenir. On pourra ainsi avoir fichier.old.test.2, la troisième révision archivée de fichier dans une branche « test ». Ou, lorsque les contraintes sont moins marquées ou moins fortement ressenties par l'équipe de développement, on pourra être moins strict. Un « dépôt » CPOLD pourra alors se présenter sous la forme suivante :

roland@mirexpress ~/cpold-demo $ ls
fichier                    fichier.OK             fichier.old.old
fichier.1999-08-16         fichier.old            fichier.old.test-roland
fichier.2003-10-27.valide  fichier.OLD            fichier.prod
fichier.a-verifier         fichier.old.marchepas
roland@mirexpress ~/cpold-demo $

Alors évidemment, ce système présente quelques inconvénients, dus principalement à sa simplicité. Mais il reste tout-à-fait utilisable dans des environnements de production, j'en veux pour preuve le nombre d'entreprises qui ne jurent que par lui et n'en changeraient pour rien au monde. CPOLD, le premier outil de suivi de versions du monde, est sans doute aujourd'hui encore parmi les plus utilisés. Il a su s'adapter depuis les copies de bande magnétique à bande magnétique, a vécu son heure de gloire à l'époque des disquettes, et continue vaillamment son aventure (avec un potentiel décuplé) à l'heure des mémoires Flash et de l'Internet.

Bon, ceci dit, personnellement je préfère Bazaar, et je ne mentionne pas CPOLD parmi les services que je propose habituellement à mes clients (si ce n'est pour leur proposer une migration depuis CPOLD vers autre chose).

Interesting approach to forges as mashup

 Bookmark this on Delicious - Saved by olberger to forge SoftwareForge - More about this bookmark

liste forges@picolibre.int-evry.fr

 Bookmark this on Delicious - Saved by olberger to forge SoftwareForge - More about this bookmark

Interesting project to help build NextGen Social Networks, and which may be usefull for Next Gen forges

 Bookmark this on Delicious - Saved by olberger to contrib2 SoftwareForge forge - More about this bookmark