Alexis Metaireau

Les dangers du livre numérique

Le framablog vient de publier une traduction de l'article de RMS à propos des dangers du livre électronique. Intéressant, même si il faut faire attention à ne pas confondre livre électronique et risques liés au format de distribution.

Si on passe sur le fait qu'un livre electronique est moins agréable à lire que sa version papier, il reste quand même quelques problèmes, la plupart liés au format de distribution de l’œuvre.

J'avoue ne pas trop savoir quoi penser de tout ça. D'un coté le livre électronique permet de franchir les frontières plus facilement, et semble avoir un tas d'avantage (notamment le fait que se trimbaler avec l'ensemble de sa collection de bouquins est désormais possible).

A mon avis, ce qui pose vraiment problème, ce sont les formats sous lesquels ces livres sont mis à disposition, non pas les livres eux même. Encore une question de DRMs donc…

Encore une problématique liée au copyright et au fait que le copie privée pose des problèmes à l'industrie en place. Ça renvoie à des questions plus profondes, et principalement à la mise en perspective du producteur de contenu et du consomateur de ce même contenu. Exactement ce qu'on essaye de résoudre dans le milieu agricole par le biais des AMAPs.

Sauf qu'ici, on est face au simple problème de la dématérialisation. Est-ce qu'une responsabilisation des consommateurs ne pourrait pas résoudre ce problème de publication ?

Recemment, j'ai récupéré une version piratée d'un livre technique, simplement parce que je ne trouvais pas une version de ce livre en numérique qui me permette de faire une copie privée de celui ci. Un Epub, par exemple. J'ai fait en me disant que c'était un acte militant. Sauf que non, ce n'est pas une solution soutenable, et j'en viens maintenant presque à le regretter. On en discutait rapidement avec Tarek il y à quelques jours et il pointait du doigt que ceux qui en patissent sont les auteurs des livres, non pas les éditeurs (qu'il ne faut pas non plus diaboliser selon moi, ils cherchent à trouver des manières de garder leur coeur de métier).

Or, avoir des auteurs, des personnes qui sont prêtes à partager leur savoir à de larges audiences me semble primordial pour que la répartition du savoir continue à se répendre. Certes, le blogging permet cela dans une faible mesure, mais de manière bien moins construite, et surtout, est fait de manière bénévole (à moins que certains bloggeurs aient trouvé des moyens de rémunération dont j'ignore l'existance ?), donc il est plus difficile pour les auteurs de se dégager du temps pour travailler sur de gros ouvrages (ceci est bien évidemment une généralisation).

Quelles sont nos solutions, donc ? Peut être se tourner vers des solution de publication alternatives, couplées à une résponsabilisation des lecteurs. Je ne pense pas necessairement aux plateformes alternatives comme framabook, parce que je me demande toujours si cela est une solution viable pour les auteurs, du moins dans les premières années, mais au moins des éditeurs qui ne font pas le choix du grand verrou numérique.

On demande pas grand chose, pourtant… Peut être même que de telles initiatives existent déjà ?

Et vous, vous les achetez ou vos livres ?

#
React

Top 5 artists this week

#
React

2012, first months

A lot of changes in these last months. First of all, I've started to work for Mozilla, on the Services team, where I am working on web services and scalability. Basically, what we are trying to do at services is to provide a way for developers to make web services able to scale out of the box.

Our most visible and known project, so far, is Firefox Sync, which allows to synchronize browsing data (tabs, passwords, history, etc.) among different instances of Firefox. We are also building other things, such as a way to get metrics easily, a web service based queue, etc. Our primary consumers are people inside Mozilla, and we want to help them having a simple way to create, deploy and scale their apps. The project is named "sagrada", and you can find some more information about it on our public wiki

All of what we do, we do it in the open. So you can have a look at the different pieces of code we wrote and use them / contribute if you want to.

I will not dig in to all the details of what I have been doing, but so far, this have been a pretty amazing experience. Part of this is explainable by the fact that the team is made of amazing folks, all with a strong experience in different topics, so I'm learning things™.

I am currently practicing a bit my C++ to do crypto related things (I may or may not talk about this later on this web-logs) and it's great (well, it remembers me why I love python for so many things, but it makes me think closer to the metal ;)). I love this job.

Second, I moved to Paris. Yes, Paris. Some of you who know me a bit may find it unexpected, and that's the case. I'm usually not a big fan of big cities and am a fairly strong defender of having and creating activities in the country side, to face the rural exodus problem, into other thingS.

I didn't changed my opinion about that. However, I don't want to start by working remote, especially when working with a remote team. Having offices kind of help me to have a differentiation between my working place and home, which I find to be important.

And, to be honest, I don't like Paris for unknown reasons: I haven't been there, so it's a big over-generalisation to say that it's not good for me. The reality is that I have no idea of what Paris is, and if I'll like it or not.

I found a really nice house (yeah, a house!) in Paris and am sharing it with 3 other persons. We have room, all like good food and… they are not geeks, which is a big win for me: work is work and home is home.

So far, Paris had been really nice. A lot of things are going on in here, and I kind of like the way it is possible to find alternative related things in here. I found a CSA, some people interested by agriculture related problems and I like where things seems to be going.

So, new job, new house, new city, things are going forward and that's great.

Oh, and I will try to post some more technical articles soon, I'm missing them :)

#
React

Introducing Cornice

Wow, already my third working day at Mozilla. Since Monday, I've been working with Tarek Ziadé, on a pyramid REST-ish toolkit named Cornice.

Its goal is to take care for you of what you're usually missing so you can focus on what's important. Cornice provides you facilities for validation of any kind.

The goal is to simplify your work, but we don't want to reinvent the wheel, so it is easily pluggable with validations frameworks, such as Colander.

Handling errors and validation

Here is how it works:

service = Service(name="service", path="/service")


def is_awesome(request):
    if not 'awesome' in request.GET:
        request.errors.add('query', 'awesome',
                            'the awesome parameter is required')


@service.get(validator=is_awesome)
def get1(request):
    return {"test": "yay!"}

All the errors collected during the validation process, or after, are collected before returning the request. If any, a error 400 is fired up, with the list of problems encountered returned as a nice json list response (we plan to support multiple formats in the future)

As you might have seen, request.errors.add takes three parameters: location, name and description.

location is where the error is located in the request. It can either be "body", "query", "headers" or "path". name is the name of the variable causing problem, if any, and description contains a more detailed message.

Let's run this simple service and send some queries to it:

$ curl -v http://127.0.0.1:5000/service
> GET /service HTTP/1.1
> Host: 127.0.0.1:5000
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 400 Bad Request
< Content-Type: application/json; charset=UTF-8
[{"location": "query", "name": "awesome", "description": "You lack awesomeness!"}

I've removed the extra clutter from the curl's output, but you got the general idea.

The content returned is in JSON, and I know exactly what I have to do: add an "awesome" parameter in my query. Let's do it again:

$ curl http://127.0.0.1:5000/service?awesome=yeah
{"test": "yay!"}

Validators can also convert parts of the request and store the converted value in request.validated. It is a standard dict automatically attached to the requests.

For instance, in our validator, we can chose to validate the parameter passed and use it in the body of the webservice:

service = Service(name="service", path="/service")


def is_awesome(request):
    if not 'awesome' in request.GET:
        request.errors.add('query', 'awesome',
                            'the awesome parameter is required')
    else:
        request.validated['awesome'] = 'awesome ' + request.GET['awesome']


@service.get(validator=is_awesome)
def get1(request):
    return {"test": request.validated['awesome']}

The output would look like this:

curl http://127.0.0.1:5000/service?awesome=yeah
{"test": "awesome yeah"}

Dealing with "Accept" headers

The HTTP spec defines a Accept header the client can send so the response is encoded the right way. A resource, available at an URL, can be available in different formats. This is especially true for web services.

Cornice can help you dealing with this. The services you define can tell which Content-Type values they can deal with and this will be checked against the Accept headers sent by the client.

Let's refine a bit our previous example, by specifying which content-types are supported, using the accept parameter:

@service.get(validator=is_awesome, accept=("application/json", "text/json"))
def get1(request):
    return {"test": "yay!"}

Now, if you specifically ask for XML, Cornice will throw a 406 with the list of accepted Content-Type values:

$ curl -vH "Accept: application/xml" http://127.0.0.1:5000/service
> GET /service HTTP/1.1
> Host: 127.0.0.1:5000
> Accept: application/xml
>
< HTTP/1.0 406 Not Acceptable
< Content-Type: application/json; charset=UTF-8
< Content-Length: 33
<
["application/json", "text/json"]

Building your documentation automatically

writing documentation for web services can be painful, especially when your services evolve. Cornice provides a sphinx directive to automatically document your API in your docs.

.. services::
   :package: coolapp
   :service: quote

Here is an example of what a generated page looks like: http://packages.python.org/cornice/exampledoc.html

Yay! How can I get it?

We just cut a 0.4 release, so it's available at http://pypi.python.org/pypi/cornice You can install it easily using pip, for instance:

$ pip install cornice

You can also have a look at the documentation at http://packages.python.org/cornice/

What's next?

We try to make our best to find how Cornice can help you build better web services. Cool features we want for the future include the automatic publication of a static definition of the services, so it can be used by clients to discover services in a nice way.

Of course, we are open to all your ideas and patches! If you feel haskish and want to see the sources, go grab them on github , commit and send us a pull request!

#
React

Introducing Cornice

Wow, already my third working day at Mozilla. Since Monday, I've been working with Tarek Ziadé, on a pyramid REST-ish toolkit named Cornice.

Its goal is to take care for you of what you're usually missing so you can focus on what's important. Cornice provides you facilities for validation of any kind.

The goal is to simplify your work, but we don't want to reinvent the wheel, so it is easily pluggable with validations frameworks, such as Colander.

Handling errors and validation

Here is how it works:

service = Service(name="service", path="/service")


def is_awesome(request):
    if not 'awesome' in request.GET:
        request.errors.add('query', 'awesome',
                            'the awesome parameter is required')


@service.get(validator=is_awesome)
def get1(request):
    return {"test": "yay!"}

All the errors collected during the validation process, or after, are collected before returning the request. If any, a error 400 is fired up, with the list of problems encountered returned as a nice json list response (we plan to support multiple formats in the future)

As you might have seen, request.errors.add takes three parameters: location, name and description.

location is where the error is located in the request. It can either be "body", "query", "headers" or "path". name is the name of the variable causing problem, if any, and description contains a more detailed message.

Let's run this simple service and send some queries to it:

$ curl -v http://127.0.0.1:5000/service
> GET /service HTTP/1.1
> Host: 127.0.0.1:5000
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 400 Bad Request
< Content-Type: application/json; charset=UTF-8
[{"location": "query", "name": "awesome", "description": "You lack awesomeness!"}

I've removed the extra clutter from the curl's output, but you got the general idea.

The content returned is in JSON, and I know exactly what I have to do: add an "awesome" parameter in my query. Let's do it again:

$ curl http://127.0.0.1:5000/service?awesome=yeah
{"test": "yay!"}

Validators can also convert parts of the request and store the converted value in request.validated. It is a standard dict automatically attached to the requests.

For instance, in our validator, we can chose to validate the parameter passed and use it in the body of the webservice:

service = Service(name="service", path="/service")


def is_awesome(request):
    if not 'awesome' in request.GET:
        request.errors.add('query', 'awesome',
                            'the awesome parameter is required')
    else:
        request.validated['awesome'] = 'awesome ' + request.GET['awesome']


@service.get(validator=is_awesome)
def get1(request):
    return {"test": request.validated['awesome']}

The output would look like this:

curl http://127.0.0.1:5000/service?awesome=yeah
{"test": "awesome yeah"}

Dealing with "Accept" headers

The HTTP spec defines a Accept header the client can send so the response is encoded the right way. A resource, available at an URL, can be available in different formats. This is especially true for web services.

Cornice can help you dealing with this. The services you define can tell which Content-Type values they can deal with and this will be checked against the Accept headers sent by the client.

Let's refine a bit our previous example, by specifying which content-types are supported, using the accept parameter:

@service.get(validator=is_awesome, accept=("application/json", "text/json"))
def get1(request):
    return {"test": "yay!"}

Now, if you specifically ask for XML, Cornice will throw a 406 with the list of accepted Content-Type values:

$ curl -vH "Accept: application/xml" http://127.0.0.1:5000/service
> GET /service HTTP/1.1
> Host: 127.0.0.1:5000
> Accept: application/xml
>
< HTTP/1.0 406 Not Acceptable
< Content-Type: application/json; charset=UTF-8
< Content-Length: 33
<
["application/json", "text/json"]

Building your documentation automatically

writing documentation for web services can be painful, especially when your services evolve. Cornice provides a sphinx directive to automatically document your API in your docs.

.. services::
   :package: coolapp
   :service: quote

Here is an example of what a generated page looks like: http://packages.python.org/cornice/exampledoc.html

Yay! How can I get it?

We just cut a 0.4 release, so it's available at http://pypi.python.org/pypi/cornice You can install it easily using pip, for instance:

$ pip install cornice

You can also have a look at the documentation at http://packages.python.org/cornice/

What's next?

We try to make our best to find how Cornice can help you build better web services. Cool features we want for the future include the automatic publication of a static definition of the services, so it can be used by clients to discover services in a nice way.

Of course, we are open to all your ideas and patches! If you feel haskish and want to see the sources, go grab them on github , commit and send us a pull request!

#
React

Top 5 artists this week

#
React

Quels usages pour l'informatique ?

Quand on termine ses études, on s'en pose un tas, des questions. Sur le métier que l'on veut faire, sur ce que ça signifie, sur le sens et la valeur du travail. Et j'en suis arrivé à faire un constat simple: l'informatique, c'est utile, tant que ça ne viens pas vous pourrir la vie. Oui, parce que de l'informatique on en a partout, des "geeks" et des "accros" aussi, et que ça vient s'immiscer dans nos vies même quand d'autres moyens ou médias sont plus utiles ou pertinents.

Certes, l'informatique nous permet de mieux communiquer et de mieux travailler. Mais à quel prix ? ce n'est pas parce qu'il est "possible" d'industrialiser l'éducation (ou l'agriculture !), que l'on doit le faire. Oui, ça me dérange d'être une des nombreuses personnes à l'œuvre derrière cette soit disant "révolution", qui n'est pas toujours pour le meilleur. Attention, je ne remets pas l'informatique et son intérêt en cause: je me pose des questions quand à la place que je veux lui donner et la place que je souhaites occuper dans son évolution. Ce n'est pas parce qu'on peut tuer avec un marteau (avec un peu de volonté) qu'il s'agit d'un mauvais outil, mais si tout le monde se met à tuer avec des marteaux (y a des malades partout, hein), alors se poser la question de son rôle, en tant que fabricant de marteaux me semble nécessaire (oui, je vous l'accorde, on aura vu des comparaisons plus perspicaces).

Donc: à partir de quel moment l'informatique cesse d'être un outil utile pour transformer nos modes de vies d'une manière qui me dérange ? Peut être avec son arrivée sur des périphériques mobiles ? Peut être quand elle se fait l'instrument du consumérisme et de l'individualisme.

Et alors, on fait quoi ?

Mais si je continue à faire de l'informatique, il y à bien des raison. J'ai d'ailleurs trouvé mon intérêt de par le coté collaboratif qui est permis et développé par l'outil informatique, et notamment par le réseau des réseaux (internet). Faisons ensemble, mes amis. Prouvons que la collaboration à de meilleurs jours à vivre que la compétition. Le web, notamment, est une avancée majeure en ce qui concerne la liberté d'expression et le partage de connaissances (oui, kipédia). Je vous conseille d'ailleurs à ce propos l'excellent discours tenu par Bernard Stiegler paru recemment sur owni.

Et c'est cet avenir qu'il me plait de défendre: l'ouverture d'esprit, la possibilité que chacun puisse contribuer et participer à une base de savoir commune, en apprenant des autres. Mais par pitié, n'imposons pas la technologie là ou elle n'est pas nécessaire, et utilisons là avec tact quand elle peut nous être profitable.

Il me plait de repenser l'informatique comme outil et non plus comme mode de vie. Faisons le l'outil de la collaboration. À l'école, apprenons à nos enfants à collaborer, à susciter le partage, pas uniquement avec l'outil informatique, mais aussi avec celui ci, tout en leurs apprenant à avoir un regard critique sur les informations qu'il reçoivent.

En bref, questionner le rôle que l'on souhaites avoir dans notre société par le biais de l'informatique est nécessaire. Comme d'autres, je suis arrivé à l'informatique par le biais du premier ordinateur familial, il y a de ça une bonne quinzaine d'années. Ça intrigue, on touche un peu à tout (on en fait des conneries !) et on finit par apprendre/comprendre comment ça marche, petit à petit. Cette curiosité n'est d'ailleurs pas le propre de l'informatique puisqu'on la retrouve dans la cuisine, dans le bricolage et dans un tas de domaines de notre vie quotidienne.

Finalement, c'est aimer bidouiller, et comprendre comment ça fonctionne, quitte à sortir les compétences de leur domaine de prédilection (qui à dit que l'informatique ne pouvait être artistique ?) Le mouvement hacker (bidouilleurs) aime à sortir l'informatique de son carcan et l'appliquer ailleurs.

C'est de cette manière que j'ai envie de considérer mon métier, qui avant tout est une passion. Je suis un bidouilleur, j'aime découvrir comment les choses fonctionnent et avoir une panoplie d'outils qui me permettent de répondre à des besoins réels.

Favoriser la collaboration

Et donc, en tant qu'individu, pourquoi faire de l'informatique ? Qu'est-ce qui m'attire dans cet outil ?

Ce qu'on pourrait qualifier de "recherche fondamentale", l'écriture de bibliothèques logicielles, est important mais n'est pas tout. Ce qui importe ce sont les usages qui en découlent. Je souhaite savoir écrire des outils qui sont utiles, qui favorisent la collaboration et participent à l'ouverture des esprits.

Je choisis de faire de l'informatique pour créer les outils qui répondent à des problématiques réelles, pour trouver de meilleures manières de communiquer et de travailler ensemble. Mais, comme me le disait David, d'Outils-Réseaux, on ne crée pas de la coopération: rien ne sert d'essayer de faire coopérer des gens qui ne veulent pas. On peut, cependant, la faciliter, en utilisant les bons outils et en formant les gens à leur utilisation, ainsi qu'aux pratiques collaboratives (qui, je le répète, ne s'arrêtent pas du tout aux frontières informatique).

Le logiciel libre, avant d'être une force pour le marché logiciel, est une application du partage. Une démonstration qu'il est possible de travailler ensemble pour fabriquer quelque chose de fonctionnel et d'utile pour tous. Une sorte d'antithèse de ce modèle capitaliste incarné par les brevets logiciel.

A plusieurs reprises, j'ai été bluffé par la réalité du logiciel libre. Oui, il est facile de collaborer lorsqu'on crée un logiciel, pour peu qu'on explique les tenants et les aboutissants aux participants. Les contributeurs sortent d'on ne sait ou, pour peu que le projet leur soit utile. Je ne parles pas d'outils "corpo compliant" (bien que ça soit probablement aussi le cas), mais d'outils que j'ai pu développer pour mon propre usage, et sur lesquels il à été possible de collaborer avec d'autres.

Parce que l'informatique est utile dans bien des milieux, parce qu'elle peut être (et elle l'est) un vecteur de participation et de collaboration, défendons les valeurs qui nous sont chères (logiciels libres et ouverts!) et construisons des ponts entre les initiatives qui nous parlent (dans mon cas ça parles de fermes autogérées, et d'initiatives d'éducation populaire) et l'informatique. Faisons en sorte de rendre l'informatique accessible et utile dans les milieux ou elle peut apporter quelque chose !

#
React

Quels usages pour l'informatique ?

Quand on termine ses études, on s'en pose un tas, des questions. Sur le métier que l'on veut faire, sur ce que ça signifie, sur le sens et la valeur du travail. Et j'en suis arrivé à faire un constat simple: l'informatique, c'est utile, tant que ça ne viens pas vous pourrir la vie. Oui, parce que de l'informatique on en a partout, des "geeks" et des "accros" aussi, et que ça vient s'immiscer dans nos vies même quand d'autres moyens ou médias sont plus utiles ou pertinents.

Certes, l'informatique nous permet de mieux communiquer et de mieux travailler. Mais à quel prix ? ce n'est pas parce qu'il est "possible" d'industrialiser l'éducation (ou l'agriculture !), que l'on doit le faire. Oui, ça me dérange d'être une des nombreuses personnes à l'œuvre derrière cette soit disant "révolution", qui n'est pas toujours pour le meilleur. Attention, je ne remets pas l'informatique et son intérêt en cause: je me pose des questions quand à la place que je veux lui donner et la place que je souhaites occuper dans son évolution. Ce n'est pas parce qu'on peut tuer avec un marteau (avec un peu de volonté) qu'il s'agit d'un mauvais outil, mais si tout le monde se met à tuer avec des marteaux (y a des malades partout, hein), alors se poser la question de son rôle, en tant que fabricant de marteaux me semble nécessaire (oui, je vous l'accorde, on aura vu des comparaisons plus perspicaces).

Donc: à partir de quel moment l'informatique cesse d'être un outil utile pour transformer nos modes de vies d'une manière qui me dérange ? Peut être avec son arrivée sur des périphériques mobiles ? Peut être quand elle se fait l'instrument du consumérisme et de l'individualisme.

Et alors, on fait quoi ?

Mais si je continue à faire de l'informatique, il y à bien des raison. J'ai d'ailleurs trouvé mon intérêt de par le coté collaboratif qui est permis et développé par l'outil informatique, et notamment par le réseau des réseaux (internet). Faisons ensemble, mes amis. Prouvons que la collaboration à de meilleurs jours à vivre que la compétition. Le web, notamment, est une avancée majeure en ce qui concerne la liberté d'expression et le partage de connaissances (oui, kipédia). Je vous conseille d'ailleurs à ce propos l'excellent discours tenu par Bernard Stiegler paru recemment sur owni.

Et c'est cet avenir qu'il me plait de défendre: l'ouverture d'esprit, la possibilité que chacun puisse contribuer et participer à une base de savoir commune, en apprenant des autres. Mais par pitié, n'imposons pas la technologie là ou elle n'est pas nécessaire, et utilisons là avec tact quand elle peut nous être profitable.

Il me plait de repenser l'informatique comme outil et non plus comme mode de vie. Faisons le l'outil de la collaboration. À l'école, apprenons à nos enfants à collaborer, à susciter le partage, pas uniquement avec l'outil informatique, mais aussi avec celui ci, tout en leurs apprenant à avoir un regard critique sur les informations qu'il reçoivent.

En bref, questionner le rôle que l'on souhaites avoir dans notre société par le biais de l'informatique est nécessaire. Comme d'autres, je suis arrivé à l'informatique par le biais du premier ordinateur familial, il y a de ça une bonne quinzaine d'années. Ça intrigue, on touche un peu à tout (on en fait des conneries !) et on finit par apprendre/comprendre comment ça marche, petit à petit. Cette curiosité n'est d'ailleurs pas le propre de l'informatique puisqu'on la retrouve dans la cuisine, dans le bricolage et dans un tas de domaines de notre vie quotidienne.

Finalement, c'est aimer bidouiller, et comprendre comment ça fonctionne, quitte à sortir les compétences de leur domaine de prédilection (qui à dit que l'informatique ne pouvait être artistique ?) Le mouvement hacker (bidouilleurs) aime à sortir l'informatique de son carcan et l'appliquer ailleurs.

C'est de cette manière que j'ai envie de considérer mon métier, qui avant tout est une passion. Je suis un bidouilleur, j'aime découvrir comment les choses fonctionnent et avoir une panoplie d'outils qui me permettent de répondre à des besoins réels.

Favoriser la collaboration

Et donc, en tant qu'individu, pourquoi faire de l'informatique ? Qu'est-ce qui m'attire dans cet outil ?

Ce qu'on pourrait qualifier de "recherche fondamentale", l'écriture de bibliothèques logicielles, est important mais n'est pas tout. Ce qui importe ce sont les usages qui en découlent. Je souhaite savoir écrire des outils qui sont utiles, qui favorisent la collaboration et participent à l'ouverture des esprits.

Je choisis de faire de l'informatique pour créer les outils qui répondent à des problématiques réelles, pour trouver de meilleures manières de communiquer et de travailler ensemble. Mais, comme me le disait David, d'Outils-Réseaux, on ne crée pas de la coopération: rien ne sert d'essayer de faire coopérer des gens qui ne veulent pas. On peut, cependant, la faciliter, en utilisant les bons outils et en formant les gens à leur utilisation, ainsi qu'aux pratiques collaboratives (qui, je le répète, ne s'arrêtent pas du tout aux frontières informatique).

Le logiciel libre, avant d'être une force pour le marché logiciel, est une application du partage. Une démonstration qu'il est possible de travailler ensemble pour fabriquer quelque chose de fonctionnel et d'utile pour tous. Une sorte d'antithèse de ce modèle capitaliste incarné par les brevets logiciel.

A plusieurs reprises, j'ai été bluffé par la réalité du logiciel libre. Oui, il est facile de collaborer lorsqu'on crée un logiciel, pour peu qu'on explique les tenants et les aboutissants aux participants. Les contributeurs sortent d'on ne sait ou, pour peu que le projet leur soit utile. Je ne parles pas d'outils "corpo compliant" (bien que ça soit probablement aussi le cas), mais d'outils que j'ai pu développer pour mon propre usage, et sur lesquels il à été possible de collaborer avec d'autres.

Parce que l'informatique est utile dans bien des milieux, parce qu'elle peut être (et elle l'est) un vecteur de participation et de collaboration, défendons les valeurs qui nous sont chères (logiciels libres et ouverts!) et construisons des ponts entre les initiatives qui nous parlent (dans mon cas ça parles de fermes autogérées, et d'initiatives d'éducation populaire) et l'informatique. Faisons en sorte de rendre l'informatique accessible et utile dans les milieux ou elle peut apporter quelque chose !