Tag - Libre

Entries feed - Comments feed

Last entries

Tue 16 Feb 2016

Open-source alternative to Trello: does it exist? Can we make it better?

I am a daily user of Trello, the visual online service to organize cards into lists. Trello is a very simple but neatly found idea: you use cards organized into lists to represent your things (e.g. to-do lists) and, more importantly, you re-organize them as you wish: moving cards, moving lists, putting colored labels, comments, due date, or check-lists on cards, ... That way, you can represent about any system and update it status very easily and visually. Trello has also filtering capabilities and, last but not least, collaborative capabilities by sharing boards of cards. Trello is visual, simple to use. You can organize both your private and professional life with it: bug tracker, to-do list, project management, holidays planning, etc. Trello is great!

Well, nearly. Trello has a big drawback: it is a proprietary product.

So, can we find an open-source alternative to Trello?

Looking for open-source Trello-like application

A friend of mine recommended me to look at AlternativeTo's suggested application for Trello. The listed applications can be classified in four categories:

  • Bug trackers and project management tools (Trac, Tuleap Open ALM, ...);
  • Kanban-like boards for Agile project management (Kanboard, TaskBoard, ...);
  • Some strange-application-in-that-category like Loomio, Agenda or ERPAL;
  • Two Trello-like applications: Restyaboard and Wekan!

Restyboard and Wekan are very similar, i.e. a very early prototype of Trello. You can create lists and cards, move them, add labels and do some filtering, share boards... and that's all! Moreover Restyboard is very slow and uneasy. So if you want a basic Trello-like open-source alternative to Trello, use Wekan.

But if you want the full power of Trello, you won't find any open-source alternative.

So we need to build it. :-)

Designing a better Free Software alternative to Trello

So, how could we improve Trello?

Firstly, take all the basics of Trello: lists, cards, due dates, filters, check-lists, board sharing, etc. Maybe some goodies like badges are not needed, but the core of our Free Software Trello should be very close to the current proprietary Trello.

Second step: make it real desktop application (and mobile App), not an online service. Why? Because in a post-Snowden era, you cannot trust any online server, not in the US, not in Europe, not even your own lovely-administrated-server. So edit your data locally, encrypt it and then upload it for sharing. For a local application, you can create a real desktop application, or a web application. The second one might be easier to create and is in the mainstream, but even if web-based application can be very powerful, there always are strange UI issues, like application "windows" not interacting similarly to your other desktop windows. So I vote for the real application.

Third step: add sharing capabilities. Data should be uploaded in encrypted form. On the server, you need a minimal platform to store pieces of data, maybe with some PHP to maximize hosting ability. That step might be a bit tricky: you need some crypto power, be astute and not re-invent the wheel (or you won't have any security) to be able to share data while keeping that data encrypted on server. But there is always a lot of fun in a technical challenge! :-) And other people are looking at this issue, like Mozilla's Firefox Sync.

Fourth step: add 2D capabilities. I always found Trello frustrating regarding list organization: I can put lists in column, but I cannot organize lists in two dimensions, as on a table. Sometimes lists are very short: I would like to group them together, one above the other. Trello does not allow that.

Fifth but not least step: add programming capabilities. You want to automatically move cards when a certain label is put on them? You want to create a card when an email is received? Take you favorite programming language (OCaml, Lua, Ruby, ...), use the API and program the behavior your want. Even better, publish the recipe online, in a public repository, that way other people can reuse your nice Agile Project Management Tool Manipulated With Only Five Keystrokes™.

With all of that, I think we'll have a better Free Software alternative to Trello.

By the way I propose its name, Tibett: Tibett is better than Trello and because with Tibbet you can go to high heights. :)

What do you think of it? Would you have other improvements to Trello?

Introduction aux méthodes formelles actualisée

Comme en 2010 et 2011, j'ai faire une intervention de 2h pour présenter les méthodes formelles à l'ESIR, école d'ingénieur de Rennes 1. J'ai un peu actualisé la présentation, je pense qu'elle est plus illustrée et j'ai introduit quelques démonstrations d'utilisation des outils. La présentation est disponible en PDF ou en source au format PowerPoint (licence Art Libre, sauf pour les illustrations, que j'ai pioché à droite et à gauche sur le web).

Note pour les libristes : la plupart des logiciels mentionnées sont libres.

Sun 26 May 2013

Issues with distributions, not only a Debian specific problem

Some time ago, I blamed Debian for not looking enough at its users. Apparently, I'm not the only one to make such remarks. Ingo Molnar, a famous Linux kernel developer working for Red Hat made similar remarks. He even proposed some technical solutions.

Other solutions are already available. For example, for OCaml specific software, OPAM, an OCaml specific package system, seems very interesting to work around the freshness issue of OCaml Debian packages.

I'm not sure Ingo's answers or OPAM are THE answers, but they at least open interesting perspectives. Handling of security and licensing issues are very difficult and not yet solved. Distributions are making an heavy work of integration that is currently not done by anybody else.

It is nonetheless refreshing to see people thinking at those issues and proposing new solutions. I find Ingo's proposal of sandboxing, flat dependencing and not forcing people to upgrade very interesting. If you read French, you can also read this LinuxFR article that makes a small review of current proposals.

Sun 27 Jan 2013

The failures of Debian (and its derivatives)

I am a long term Debian user. I have used Debian since probably the mid 90' up to now. I use latest Debian stable on my personal server or at work, and Ubuntu on my desktop and laptop machines at home. Using it does not mean I am entirely satisfied with it to say the least. I think the distribution is not making enough efforts for its users and I'll try to explain why. Of course, YYMV. ;-)

  • Debian packaging is made for developers, not users. Debian has too many packages. To take just one example, the OCaml compiler is packaged into the main compiler, its libraries, the native compiler and the byte code one, etc. Why so many packages? If I am an OCaml developer, I want all of them so why do I need to manually find (the naming is far from being obvious, at least for beginners) and install so many packages? I have heard of several reasons: it allows to factorise common parts between the different binary architectures, it allows to install the command line only parts without the graphics parts, it allows to install only what the user wants, etc. For me, those reasons are just plain wrong. We have more and more disk capacity on our machines so disk usage is no longer a limitation. The package should be able to dynamically activate the graphic parts automatically if the X server is available. And the factorisation of shared parts between Debian architectures should be done on the servers storing the packages, not trough the packaging system.
  • Debian has out-dated software. Debian Wheezy is about to be released and it will have GNOME 3.4. But GNOME 3.6 is already out and GNOME 3.8 is on its way. And I am taking GNOME as an example, it is the same issue for lot of software within Debian. I have heard this is for stability issues. But software packaged in Debian is already stable! It should take 10 or 15 days to integrate a new software into Debian stable, not months or even years (the time between successive stable releases). I acknowledge that some packages have complex interdependencies between each others. For example, when a new release of the OCaml compiler is out, one needs to recompile all OCaml packages. But this constraint is only for OCaml packages. Why should I wait for a new stable version of Debian to get the newly released OCaml compiler? For me this sounds just plain wrong.
  • Nobody uses plain Debian stable. Debian developers are using unstable. Debian users are using Debian stable, but enriched with backports because of out-dated software. Or derivatives like Ubuntu. The fact the Debian developers are not using what they recommend to users is bogus. I know they do that for technical reasons, but that should not be a good reason. Debian developers should use what they are providing to their users, except maybe for a few packages they are working on.
  • There are too many dependencies between packages. The dependency system of Debian is a nice piece of work, it was ahead of its time when it was created. But the use of dependencies has been perverted. The dependencies are manually computed (thus source of errors and bugs) and at the same time any software can write to about any part of the file system. Due to too many dependencies and lack of clean interfaces between sub-systems, the installation of a recent user software can trigger a ton of packages down to a new kernel or libc. Why is it so? I think the sub-systems of Debian (e.g. the X graphical infrastructure, the kernel and base C libraries, the OCaml system, ...) should be isolated the one from the others. It would allow them to be updated without waiting for the others. Having dependencies between 29,000 packages is just not scalable. It is even more true if those dependencies are manually computed.
  • Debian packaging is lacking automation. I am a developer. Debian packagers are developers. It always astonished me how much manual work should be done to make and maintain a Debian package. All developers know that if they want to be efficient, they need to automate their work as much as possible, so as to be able to focus their manpower on the complex parts. Everything should be automated in Debian packages, starting from a minimal description file. Automation should be the default (package creation, test, static analysis, ...), not the exception.
  • One cannot install simultaneously several versions of the same software. As a user or developer, I want to use the stable version of a piece of software and maybe the latest stable version that just have been released in order to do a few tests or check that my software still compiles with the new shiny compiler. Debian does not allow me to do that. And if I install a newer package, downgrading to the previous version is complex and error prone.
  • Debian is undocumented. I am not talking about the installation guide which is nice, I am talking about the modifications made to software by Debian developers. Doing modification on the "standard" (for the software) way of configuring or using it has always seemed suspect to me, even if I agree that having harmonized configuration is a real advantage (all configuration files in /etc for example). But all of those modifications should be documented in README.Debian file. To take an example, the last time I tried to install the dokuwiki Debian package, I was unable to configure it! The way to add new users had been changed compared to a regular dokuwiki (the web interface was disabled), and those changes were undocumented. It should be a release critical bug! Without proper documentation, the user cannot use the software. And, of course, the reason behind those changes should be questioned, even for security reasons (a very secure but unusable software is superfluous. Security is a trade-off).

So, why I am complaining? Why I do not become a Debian Developer, so I can fix it? Because a single developer is not going to change the root causes of those issues. They need a massive development effort, or at least a massive acknowledgement by the Debian Developers. And I don't have ready-made answers to those issues (even if I have some ideas to solve them).

Is the grass greener in the other fields? I don't think so, or at least I am not aware of it. I like Debian for is community approach, its focus on Free Software (even if it is sometimes imperfect) and the wide range of software packaged in it (the OCaml packages are numerous for example). I just hope that the whole Debian community will focus on more user related issues in the future.

Mon 07 May 2012

Gulliver à Vern-sur-Seiche du 23 au 26 mai : Libre-sur-Seiche

Gulliver organisera à Vern-sur-Seiche une semaine autour du Libre du 23 au 26 mai prochain : Libre-sur-Seiche.

Au programme :

  • Mercredi 23 mai de 14h à 17h : démonstration de jeux sous licences libres dans l'espace multimédia
  • Mercredi 23 mai à 20h : débat : l'Art et le Libre
  • Vendredi 25 mai : conférence-débat « Le Libre, j'y participe ! », autour d'OpenStreetMap, un projet de carte mondiale participative pour le citoyen et les collectivités
  • Samedi 26 mai de 10h à 16h : conférences et démonstrations de logiciels et œuvres libres
  • Samedi 26 mai 12h30 - 13h30 : pique-nique libre ouvert à tous avec les membres de Gulliver autour du Volume

Venez nombreux !

Wed 19 Jan 2011

« OpenData » à Rennes, ça avance !

J'étais mardi à la Cantine Rennaise pour assister à un BarCamp OpenData à propos du concours « Rennes Métropole en accès libre ». Je ne candidate pas au concours mais comme j'ai pas mal critiqué l'actuelle licence des données « libérées » par Rennes Métropole et que j'avais eu en retour une discussion avec des acteurs du dossier[1], j'ai voulu aller aux nouvelles.

Le dossier avance ! Une nouvelle version de la licence est en préparation, dont on peut espérer un brouillon en ce début d'année. Des clauses seront supprimées, par exemple la clause qui oblige la mise à jour de son application en cas de changement de l'API. Une contrainte même pour des gens qui font des applications propriétaires, comme me le faisait remarquer un collègue. Reste à voir le résultat final, affaire à suivre ! ;-)

Sinon, soirée très sympa, où j'ai rencontré pas mal de Gulliveriens et d'anciens Gulliveriens. Sylvain a pointé très justement ces questions sur la licence dans la partie questions de l'exposé. J'ai aussi eu un très bon contact avec des responsables du service SIG de la Ville de Rennes. Ils connaissent OpenStreetMap (et même MapOSMatic !) et envisagent diverses manières d'y contribuer. Ça prendra un peu de temps (probablement en 2012) mais on devrait voir des choses intéressantes. Là aussi, une affaire à suivre !

Sinon, la date du fameux concours a été repoussée. Pourquoi ? Parce que la mise à disposition des applications développées au grand public dépend de la vitesse avec laquelle Apple valide les applications sur sa plateforme propriétaire. Vous n'y voyez pas une contradiction ? Moi si : on ne parle que de données « Libres » mais les applications développées ne sont disponibles que sur la plateforme fermée et propriétaire d'un seul constructeur. Le monde est plein de paradoxes. :-)

Notes

[1] Il y avait aussi des gens d'OpenStreetMap et de Wikipédia.

Wed 20 Oct 2010

Pourquoi l'« ouverture » des données de Rennes Métropole est insuffisante

cube-interdiction.jpg La Ville de Rennes et Rennes Métropole ont récemment mis en place un entrepôt accessible à tous de données publiques leur appartenant. On trouve sur ce site www.data.rennes-metropole.fr des informations concernant les transports, les données de la base « Guide Vivre à Rennes » ou des informations du Système d'Information Géographique (SIG) de la Ville de Rennes et de Rennes Métropole.

Cette ouverture des données est largement mise en avant par Rennes Métropole et la Ville de Rennes, avec un concours de 50.000 € de prix, une couverture médiatique comme cet article de Télérama ou la réception d'un « prix européen e-démocratie » lors du World e.Gov Forum.

L'ambition affichée est de « permettre aux usagers, aux développeurs, aux entreprises de s’approprier et de retravailler les données mises à disposition pour créer de nouveaux services utiles au grand public. » En tant que développeur et contributeur à la communauté des logiciels et œuvres Libres, je ne ne peux qu'adhérer à cette vision des choses. Permettre à quiconque d'utiliser des données publiques et les réutiliser dans d'autres œuvres est pour moi crucial.

Donc, comme tout bon utilisateur potentiel, je me suis précipité sur les conditions d'utilisation[1]. Et là j'ai été plutôt surpris ! En particulier l'article 4, « Obligations du Réutilisateur » précise :

Conformément à l’article 12 de la Loi, le Licencié s’engage à ce que les Informations ne soient pas altérées ni leur sens dénaturé. Le Licencié veillera à respecter l'intégrité des données, et notamment à ne pas les dénaturer et/ou tronquer. L'insertion de commentaires doit être clairement distinguée du contenu du concédant.

En d'autres termes, il m'est impossible de réutiliser les données dans d'autres œuvres composites, car en les intégrant je vais très certainement « dénaturer ou tronquer » les données. Un comble pour des données soit disant « ouvertes » ! Notez bien au passage que l'article 12 de la loi n°78-753 du 17 juillet 1978 précise bien que « Sauf accord de l'administration, la réutilisation des informations publiques est soumise à la condition que ces dernières ne soient pas altérées, que leur sens ne soit pas dénaturé et que leurs sources et la date de leur dernière mise à jour soient mentionnées. » Donc un accord de l'administration peut permettre une réutilisation plus libre des données.

Prenons un exemple concret : imaginons que je veuille ré-intégrer la « localisation des points d'apport volontaire des déchets ménagers » dans la carte libre OpenStreetMap. Cette carte est ouverte, enrichie en permanence par des volontaires à l'échelle planétaire et Rennes y est très bien cartographiée. La localisation des conteneurs à déchets y serait très utile, ce serait un geste citoyen. Et pourtant avec la licence actuelle, c'est impossible. Je devrais forcément transformer les données pour les intégrer. Et comme la carte OpenStreetMap doit pouvoir être redistribuée et modifiable par n'importe qui, il m'est impossible d'y intégrer des données ayant de telles contraintes de contrôle d'intégrité.

Ce que Rennes Métropole aurait dû faire

Le plus drôle dans cette histoire, c'est que d'autres acteurs ont tout compris. Rennes Métropole et la Ville de Rennes ne font que recopier ces acteurs, mais en faisant tout de travers par cette licence inadéquate !

L'article de Télérama est éclairant sur ce point. Outre OpenStreetMap, Antoine Mairé y cite l'exemple des villes anglo-saxones qui ont ouvertes leur données, comme l'initiative anglaise Data.gov.uk. Mais quand on regarde les conditions d'utilisation de Data.gov.uk, on y lit que la personne réutilisant les données a le droit :

de copier, publier, distribuer et transmettre les données ;

d'adapter les données ; (le point crucial !)

d'exploiter commercialement des données, en combinant par exemple ces données avec d'autres données ou en l'incluant dans votre produit ou application.

La Ville de Rennes et Rennes Métropole aurait dû utiliser une licence inspirée des licences d'œuvres libres comme Creative Common BY ou BY-SA permettant à quiconque de transformer et intégrer les données. Sans ces conditions, les données « ouvertes » de Rennes Métropole sont inutilisables dans d'autres œuvres ou programmes, à l'opposé même du but initial de permettre aux usagers de s'approprier les données.

Peut-être qu'un jour nous aurons des données réellement ouvertes, et réellement réutilisables ! En attendant, passez votre chemin, il n'y a rien à voir sur data.rennes-metropole.fr.

Notes

[1] Lisez les, elles sont courtes et plutôt lisibles.

Tue 24 Aug 2010

La fin du bureau ?

Un aspect social du bureau (licence CC-BY) On parle de plus en plus de la fin du bureau, du desktop, au profit d'« applications » web. Tristan Nitot se pose par exemple la question de l'avenir de Linux sur le poste de travail. Même les développeurs Gnome s'y mettent, comme Luis Villa demandant à la communauté Gnome de prendre à bras le corps le web (« to embrace the web »). Et bien sûr lil faut compter sur Google qui, de Google Chrome à Google Docs, vise à fournir tous les outils et applications pour laisser nos informations dans le nuage (c.-à-d. sur les serveurs de Google), loin de nos PC de bureau et nos portables.

Est-ce que l'avenir du PC et de ses applications est définitivement compromis ?

Certes, les applications web sont très pratiques. Gros utilisateur du webmail, j'apprécie sa disponibilité en toute situation, sur n'importe quelle machine pourvue d'un accès Internet et d'un navigateur. Et l'aspect centralisé des applications web est appréciable lorsqu'on utilise plusieurs machines, dans différents endroits. Enfin et peut-être surtout, l'aspect « social » des applications web peut être vraiment utile. Trouver la réponse à un problème technique dans un forum sur Internet est inappréciable et m'a sauvé plusieurs fois de plusieurs heures de recherches fastidieuses. Par ailleurs, les applications web sont faciles à déployer. Tout le monde à un navigateur sur son poste de travail, chez soi ou au travail. Et en tant qu'informaticien, il devient plus facile de déployer une nouvelle version de l'application.

Pour autant les applications web sont loin d'êtres parfaites et posent même de sérieux problèmes.

En premier lieu et probablement le plus important, nous perdons le contrôle sur nos données. En tant que Libriste convaincu, cela m'inquiète de laisser mes données chez Google ou Yahoo!. Je ne sais pas comment ses données personnelles sont stockées, qui peut y accéder ou même leur pérennité.

En second, les interfaces web sont très pauvres, malgré les progrès indéniables du Web 2.0 et des technologies AJAX. Google, expert et leader en ce domaine, arrive péniblement à finaliser le Glisser-Déplacer dans les dernières versions de GMail, alors que cela existe depuis des (dizaines d' ?) années sur les applications de bureau. Et quel que soit les efforts de programmation, la latence réseau sera toujours là, ralentissant l'interface au point de la rendre malcommode voire inutilisable. Sans compter que le réseau même doit être disponible en permanence, ce qui réduit d'autant la disponibilité des applications.

Alors, quel avenir pour le bureau et ses applications ? Je pense que le bureau n'est pas mort, que ce soit sur un PC de bureau, un ordinateur portable ou un téléphone portable. Par contre, les framework de développements doivent évoluer, prenant en compte dès le départ le réseau et la distribution des données. Pour reprendre un vieux slogan publicitaire de SUN, « the network is the computer » (le réseau est l'ordinateur).

Ces frameworks doivent fournir un moyen simple pour une application de stocker des données sur un ou plusieurs ordinateurs distants, de manière centralisée ou distribuée, et ce de manière sécurisée et authentifiée. Par exemple chaque utilisateur d'application devrait pouvoir facilement mettre en place un serveur pour stocker ses données ou répartir ses données entre plusieurs ordinateurs avec des protocoles Peer to Peer (P2P). La confidentialité des données doit être prise en compte dès le départ, que ce soit sur le bureau de l'ordinateur ou un serveur distant. Les frameworks doivent également fournir des API simples permettant de gérer les problèmes de latence d'un réseau sans que le programmeur soit un expert en réseau et en comprenne toutes les implications. La technologie d'appel de procédures à distance des années 80, les fameux RPC (Remote Procedure Call), encore utilisées dans les applications AJAX avec les XML RPC sont trop limités. D'autres paradigmes doivent être utilisés. Et bien sûr des API doivent être fournis pour développer facilement des applications « sociales » où l'ont peut partager facilement des données avec des autres utilisateurs sur la planète.

En bref, il va falloir inventer le meilleur des deux mondes. Mais un monde où l'utilisateur, le citoyen, garde le contrôle sur ses données. Comme le dit Philippe Meyer, « le progrès est en marche et le futur ne manque pas d'avenir ! » :-)

Correction 2010-08-24 : s/Christian/Tristan/. Merci Thomas ! ;-)

Sat 21 Aug 2010

De grands pas vers une téléphonie Libre !

Le projet OsmocomBB a pour objectif de créer une solution de téléphonie GSM (nos téléphones portables de 2e génération dit 2G) entièrement Libre, que ce soit sur le téléphone et la station de base.

Ce projet fait des progrès de jours en jours. Le dernier en date est qu'il a été possible de passer un appel de 20 minutes en utilisant uniquement des logiciels libres, tant sur le téléphone que la station de base !

Le déploiement de telles solutions est encore très loin, ne serait-ce que parce que les fréquences utilisées pour la téléphonie GSM sont soumises à des licences au coût exorbitant. Mais je trouve exaltant cette incursion du Libre dans le royaume du propriétaire et les progrès qui sont fait en si peu de temps ! Relisez le blog d'Harald Welte pour vous en convaincre.