Laurent HAUSERMANN

Et voila !

Google n'en finit plus de marcher sur les platebandes de Microsoft :) Après s'être installé - et comment ! - dans le monde du Web et avoir lancé un ensemble de service aussi diversifié qu'impressionant (Gmail, Google Docs,  Calendar, Reader, Earth, Maps), voici Google qui cheche à se tailler la part du lyon au pays des développeurs.

En effet,la conference Google I/Oregroupait il y a deux semaines, deux jours de presentations, de retour d'experience autour des technologies de Google : 

• Google Maps et ses APIs AJAX
• Google Gears, vu comme source d'inspiration de HTML 5 par Google
•  Google Widget Toolkit, et sa nouvelle version compatible Java 1.5
• Google App Engine
• etc...

Google affiche une stratégie et un discours marketing cohérents : fournir des services de type Cloud Computing - via Google App Engine par exemple - , proposer des logiciels OpenSource comme "brique de base" du futur Web (Gears, GWT) et renforcer les capacités des clients. Le pitch de Google pourrait se résumer ainsi : 

En fournissant des "briques de bases" du futur web, qui sera plus "riche", plus "mobile" et qui fusionnera toute les applications, les utilisateurs utiliseront encore plus le Web... et verront encore plus de publicité via Google !

L'avenir nous dira si cette vision est la bonne et si les développeurs du monde entirer aideront Google à renforcer sa position dominante !

Je vous laisse apprecier la video :

Suite à mon billet précedent, je ne résiste pas à vous montrer le nouveau look and feel du site OpenSolaris.com.

Un modèle du genre en terme de distribution de masse d'un logiciel !

Si vous avez déja eu l'occassion de tester le dernier build du projet, n'hésitez à m'en faire par dans les commentaires ! 

Joel Spolsky a posté une note très détaillée sur son système "EBS". A lire, rien à rajouter.

Parlons un peu de FogBugz de FogCreek, la société de Joel Spolsky

Ca ne vous dit, rien ?  Joel Spolsky est surement un des meilleurs bloggeurs sur le monde du Software, ("Génie Logiciel" en bon français). Il a roulé sa bosse au sein de Microsoft, avant de monter FogCreek, ISV de logiciel de gestion de contenu et de gestion de projet / issue.

FogBugz 6.0 est la dernière version de ce logiciel.

Avant d'aller plus loin, regarder la video, elle parle d'elle-même (en anglais) !

Finalement, ce logiciel est "le" logiciel qu'une équipe de projet devrait posseder pour travailler sur un logiciel :

• Gestion du contact "client" dans l'outil (mini outil de support)
• Gestion des choses à faire et du planning via un outil de saisie des taches et des temps passés
  
• Estimation de la date de fin basée sur l'historique des estimations : voici une fonction qui est le bon sens en action :) Je sais que "John Doo" en général sous-estime ces tâches de 20%, et bien, en bon chef de projet je piffo-mètre que la tache devrait plutot faire x+20%.. Mais là où le logiciel dépasse le "flair", c'est qu'il permet une estimation de la probabilité de "ship on time" via un calcul statisique. Bref une killer feature en puissance
• Interface 100% mais avec une super ergonomie grace à l'intégration des technos AJAX.
• Gestion de bugs
• Gestion documentaire via un Wiki
  
• Integration aux outils de développements (Visual Studio, Eclipse, SVN etc..)
  
• Plus de fonctions... 

Bref, un logiciel à posseder pour ceux qui n'aurait rien d'autre aujourd'hui qu'un client mail et une feuille Excel (ou OpenOffice :). Tout y est intégré et on sent la patte de Joel Spolsky et sa "vista" sur ce qu'un utilisateur "veut faire" avec un logiciel. Le coût reste raisonable surtout quand on pense aux nombre d'outils différents que FogBugz se propose de remplacer.

Good Job FogCreek Crew ! What whould you do next ?

"Libérez cette nouvelle version", semble être l'injonction à la mode dans le monde de l'open source et du Logiciel en général.

J'évoquais déjà notre envie à tous de voir sortir plus souvent nos logiciels préférés. En effet, dans les temps qui cours, on ne peut pas rester plus de 6 mois sans apporter de nouvelles versions, de nouvelles fonctionnalités à ses utilisateurs, à ses clients.

Il est vrai que les usages en matière de gestion de cycle de vie sont extrêmement variables en fonction des entreprises et des projets open source majeurs. Ainsi, Microsoft explique en détail sa politique de gestion du cycle de vie de gestion du cycle de vie de ses produits (on notera un effort d'explication remarquable de la part de l'éditeur) et distribue de ses produits environ 5 ans. Suite à ces 5 années (une moyenne), le support se poursuit pour environ 2 années après la fin des ventes. On notera tout de même une accélération du cycle de vente car on passe d'un cycle sur 7/8 ans pour MSDOS 6 (!), à un cycle sur environ 5 ans pour Windows XP.

Les projets open source ont, quant à eux, des politiques de sortie de versions très diverses, allant du vieil adage "When it gets ready" (entendez, "quand ca sera prêt"), à des cycles plus stricts de 6 mois comme les projets Gnome, ou OpenBSD. Mais ces projets open source ressentent aussi la même pression de leurs utilisateurs et il est fort probable que la gestion des sorties, le rôle de Release Manager, devienne prépondérant au sein des communautés.
Ainsi, le projet Debian, qui doit renouveler son "Debian Project Leader"s'anime autour de la question de la gestion des release.

"Libérez !", sembleraient donc dire les usagers des logiciels et les producteurs de logiciels de s'adapter en conséquence...

Mais plein de contradictions, nous cherchons des logiciels qui durent (l'affaire Bouygtel nous l'avait rappelé).

J'en veux pour preuve l'émotion que suscite l'arrêt par Microsoft du support gratuit et du développement de VB.6.
Certains vont même jusqu'à lancer des pétitions à Microsoft pour que la société éditrice continue à faire vivre le langage. La grogne des développeurs est compréhensible : après avoir investi tant d'années dans des développements VBA et VB6, pourquoi devraient-il continuer à investir dans la technologie VB.NET pour refaire ce qu'il ont déja ?.
Joel Spolsky, enfonce le clou :

But here's the thing. If you have a million line code base that's mission critical, as many companies do, and VB suddenly changes, as it did, you have a choice: keep using VB 6 or spend a lot of time (=money) upgrading to VB.NET. If you keep using VB 6, eventually new things will come out that will not be supported from VB 6, and you'll be stuck using the yucky old VB 6 IDE until the end of time. Already most of the big component vendors are doing all the new components as .NET components, not OCXes.

If you spend the money to upgrade to VB.NET, well, you just spent a lot of money to stand still. And companies don't like to spend a lot of money to stand still, so while you're spending the money, it probably makes sense to consider the alternatives that you can port to that won't put you at the mercy of a single vendor and won't be as likely to change arbitrarily in the future. So as soon as people with large code bases start hearing that they're going to have to work to port their apps from VB to VB.NET with WinForms, and then they start hearing that WinForms isn't really the future, the future is really this Avalon thing nobody has yet, they start wondering whether it isn't time to find another development platform.

Tout ceux qui, comme moi, naviguent dans le milieu du logiciel, apprécieront les citations du site "Software Quotes". Vous y trouverez de nombreuses "perles" de développeurs et de différents chef de projets.

Quelques unes de mes préférées :

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. -
Martin Fowler (un auteur prolixe du monde du software)

... the cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion. ... The trick is to pick the features that don't fight each other. -
John Carmack (le créateur du célèbre Quake !)

Le site propose aussi une "source" RSS !

Dans cette note, Joel Spolsky donne quelques conseils aux étudiants :

Without further ado, then, here are Joel's Seven Pieces of Free Advice for Computer Science College Students (worth what you paid for them):

1. Learn how to write before graduating.
2. Learn C before graduating.
3. Learn microeconomics before graduating.
4. Don't blow off non-CS classes just because they're boring.
5. Take programming-intensive courses.
6. Stop worrying about all the jobs going to India.
7. No matter what you do, get a good summer internship.

Now for the explanations, unless you're gullible enough to do all that stuff just because I tell you to, in which case add: 8. Seek professional help for that self-esteem thing.

Où s'arretera le peer to peer (P2P) ?

On croyait peut-être à tors que ce mouvement périrait avec la fin de Napster, mais d'autres ont pris la suite (Kazaa, EDonkey, EMule pour ne citer que les plus célèbres)... Le succès de ces logiciels mélangeait en réalité deux succès :
- Celui du téléchargment de films et de musique de façon gratuite et le plus souvent illégalle (je ne vais pas entrer dans ce débat...)
- Celui du mode de communication, où chacun partage ces informations et est à la fois "serveur" et "client". Les membres du réseau devenant tous égaux, ils peuvent partager ensemble, sans contrainte externe, sans le contrôle d'une société tierce, des informations et des contenus. Notez que ceux qui voudraient rester "in touch" avec le monde du P2P, doivent lire le Weblog P2P & NTIC qui regorgent d'informations sur le domaine.

Mais, je m'égare, je voulais surtout vous signaler l'extension du concept à un nouveau domaine, celui des Photographies. C'est le pari fait par le site PixVillage qui permet de partager les photos de ces amis et de sa famille, sans avoir besoin d'un blog dédié, d'un site internet, ou d'une connexion FTP (certains d'entre vous sourient ?).
Découvrez donc vite, la simplicité de mise en oeuvre de "PixVillage", qui m'a vraiment séduite dans sa simplicité et sa maturité.

Je suis curieux de voir l'usage que feront les internautes de ce logiciel... Peut-être certains de vous offriront les photos qu'ils auront prises lors d'évenements , de conférences, de manifestations ?

Dans tous les cas, il faut saluer l'initiative et la créativité, car finalement le P2P peut encore nous étonner !

Firefox, Eclipse, Linux, Apache sont aujourd'hui des "marques" (et oui !) de plus en plus populaires dans l'industrie du Logiciel et des Télécoms. Du CEO/PDG à l'analyste programmeur, les débats ne tournent plus sur le "pourquoi" installer des logiciels libres, mais sur le "comment", signe d'une grande évolution en peu de temps (5-7 ans).

Et ce n'est pas cette nouvelle donne qui va pas permettre à Steve Balmer, CEO de Microsoft, de se "calmer" ! (lire ses frasques avec les dirigeants asiatiques). Microsoft perdrait-il patience ? Mais au fond pourquoi ?

Je suis assez favorable à une approche pragmatique des problèmes (tout comme un certain Linus Torvald ) mais vu la puissance économique des grands éditeurs de logiciels, je ne trouve pas de bons arguments pour défendre les brevets logiciels.
Même si le brevet a été crée pour défendre l'innovation en protégeant l'auteur, et pour partager l'information en publiant ses découvertes, aujourd'hui "l'homme de l'art" (pour reprendre la terminologie "brevets") semble bien contraint.
IBM (première entreprise à déposer des brevets au monde), Cisco, Microsoft disposent d'une telle capacité de recherche et développement, qu'il semble difficile d'innover, d'inventer sans enfreindre un des milliers de brevets déja déposé. Et ceux qui s'engageraient dans l'aventure, s'exposeraient au risque d'être "broyer" par les machines juridiques de ces grandes multinationales. Aucune PME n'a les moyens de combattre juridiquement ces grands groupes. Ces entreprises ont déja un pouvoir conséquent, voir monopolistique, pourquoi leur donner de nouveaux moyens pour augmenter leur emprise ? Souhaite-t-on augmenter leur monopole ?

Et d'un autre point de vue, y-a-t-il un patron de PME en Europe, qui puisse m'expliquer en quoi un brevet logiciel lui permet de gagner des parts de marché et d'être rentable ? Comment s'intègre un brevet logiciel dans le buisness model d'un "petit" éditeur de logiciel (dans d'autres secteurs, cela semble plus évident que pour les logiciels) ?

Heureusement que certains nous rappelent l'ampleur de la politique de propriété industrielle des grands éditeurs et nous mettent en garde.

Vous avez tous entendu parler cette semaine de la mega panne qui c'est produite chez Bouygues Telecom. Reuters nous apprend que l'opérateur aurait perdu près de 16 Millions d'euros à cause de cette panne. La moitié de la somme allant pour des remises clients (qui ne font pas plaisir à tous le monde !).
Cette panne, s'ajoute à celle qui a eu lieu chez France Telecom, il y a quelques semaines. Du coup Patrick Devedjian, Ministre de l'Industrie, a diligenté une enquête administrative pour en savoir plus. Tekelec, fournisseur de serveur de geolocalisation, semble en cause... on devrait en savoir plus d'ici à la fin du mois.

Cette affaire est révélatrice du manque de maturité qu'on trouve aujourd'hui dans le monde de l'informatique, des réseaux et des télécomunications. Il y a bien longtemps que les industriels "de l'ancien économie" (ie automobile, chimie, etc..) utilisent des processus redondant, et possède une "management de la qualité" leur donnant une vrai maitrise de leur "métier de base". Bref, ces industries connaissent les risques operationnels liés à leur activité, et "gère" ce risque. Ca n'empêche pas les pannes, mais ils y sont préparés et les ont anticipées.

Dans la "nouvelle économie", cette culture de la sureté de fonctionnement et des procédures qualités n'est pas encore généralisées. Cette culture est en formation, et les mutliples normes internationales (ITIL, COBIT pour la partie IT, Critères Commun ou ISO 17999 pour la sécurité informatique) sont encores jeunes. Tout ceci doit encore "grandir" et se démocratiser ... (même s'il ne faut pas penser que Bouygues Telecom ou FT soit des entreprises désorganisées)

Cela me fait penser à un de mes professeurs lorsque j'étais étudiant : A chaque cours, il racontait comment son premier employeur, un operateur Américain, lui avait expliqué que si le réseau téléphonique "tombait" (c'est à dire était en panne), alors de nombreuses personnes allaient mourir.
Mourir ? Oui, car le téléphone (et demain l'internet) est le premier support des moyens d'urgence. Couper le téléphone, c'est mettre en danger de mort les personnes seules, isolées, agées ou malades.

Devant cette importance grandissante de la fiabilité des logiciels, toute l'industrie informatique réfléchit: j'en veux pour preuve, cet article qui demande des logiciels durant 200 ans (comme un pont par exemple). Par ailleurs, je ne résiste pas à vous citer Alan Brown (Rational / IBM) dans son article sur "The Future of Software Tools" :

2. Greater transparency in the software development process: Auditing, traceability, and accountability. Software plays a pivotal role in all our lives. It runs our financial institutions, controls the power and utility infrastructure, is embedded in almost every useful device we use, and so on. With this important role comes a certain responsibility. Government regulators, lawyers, and auditors are beginning to pay increasing attention to the software industry to verify that the software we all rely on has been developed according to some provable quality standards. Sarbannes-Oxley and BASEL2 are just the tip of a very large iceburg. For example, in discussions with those in the auto industry I was overwhelmed by the role software plays in the design, manufacture, control, and management of automobiles, and the kinds of requirements they need fulfiled by the software tools they are using. Suppose there is a major design flaw in the software managing the anti-lock brakes on a popular model of car that results in injury of a number of people. How does the manufacturer of the braking system prove that it was not negilgent in the design and implementation of that software? Were the engineers developing the software certified against some recognized standards? Were the processes used to develop the software audited for quality? How were software designs analyzed and validated before they were put into production? And so on. This kind of rigour and auditability will become the norm. Tools must permit this level of access and control. I refer to this as transparency...of process, design, realization, etc. New tooling will emerge that supports and enforces these design principles. Traceability and reporting at all levels will become essential.