Interview – Thomas Menguy, responsable d'OpenPlug ELIPS Studio
Cherchant une solution pour le développement mobile il y a quelques semaines, je suis rapidement tombé sur OpenPlug, proposant un concept très intéressant.
Après des débuts plutôt difficiles, la plate-forme se révèle plus complète que je l'imaginais. Désireux d'en savoir plus, j'ai pris contact avec Thomas Menguy, responsable du produit ELIPS Studio chez OpenPlug.
Afin de mieux vous aider à cerner le produit OpenPlug, voici quelques Q&R avec Thomas Menguy:
Salut Thomas, tout d'abord, présentes nous l'équipe d'OpenPlug, son histoire…
OpenPlug a été fondée en 2002 par deux anciens de Texas Instruments, qui était alors leader pour les puces GSM (70% du marché des téléphones).
L'idée de départ était d'aider le développement et l'intégration du logiciel pour l'industrie du mobile.
Peu à peu, nous avons fourni à nos clients, fabricants de téléphone et leurs sous-traitants, un produit (appelé ELIPS Suite) contenant toutes les briques logicielles nécessaires pour pouvoir réaliser un téléphone dit "mass market", c’est à dire tout sauf les smartphones, basé sur du hardware très bas cout (en dessous d'une vingtaine de dollars pour l'ensemble du téléphone).
Ce produit ELIPS Suite est aujourd’hui déployé sur des millions de téléphones, y compris auprès de grandes marques comme Sony Ericsson.
ELIPS Suite étant bien déployé sur la partie « mass market » du marché du mobile, nous cherchions à nous positionner sur le marché du « smartphone », en réutilisant bien sur notre bagage de software embarqué pour plateforme bas cout, et les assets développés pour ELIPS Suite. En parallèle il nous manquait une technologie d’UI (User Interface) avancée avec des effets et des langages de programmation plus modernes (dans notre monde tout se fait en C 
) : après avoir évalué tout ce qui se faisait, Flex s’est rapidement imposé (par rapport à Silverlight, SVG, etc).
L’iPhone et l’explosion du marché des applications mobiles ont fait le reste pour nous convaincre de nous positionner sur ce créneau.
Nous pensons vraiment qu'Adobe a mis en place quelque chose d'intéressant avec son framework Flex, ses outils et sa communauté, par contre le moyen de "projeter" ces applications, en particulier pour le mobile, ressemble trop au "write once, doesn't work or look poorly everywhere" de java et de j2me, en tout cas pour les applications. Pour les sites web, c'est une autre histoire. Ce que fait Adobe avec le flashplayer et AIR et la stratégie Open Screen Project, c'est un peu comme si pour vendre Dreamweaver (son éditeur phare d'HTML) Adobe imposait son browser Web à tout le monde. Il nous paraissait dommage de brider leur excellent tool flow à cause d'un runtime trop générique et d'une stratégie difficile à mettre en place.
On s'est donc engouffré dans la brèche, le but étant bien sûr de s'assurer un business pérenne… et de rester dans le milieu du mobile et de ces évolutions qui nous passionnent tant!
Surtout qu’ELIPS Studio est un réel changement culturel pour nous : de quelques très gros (et lourds 
) clients, on passe à une communauté de gens très motivés et créatifs…rafraichissant !
Quels sont les objectifs du projet OpenPlug sur le long terme?
Nous sommes maintenant actifs sur les deux « zones » du marché du mobile : le « mass market » avec ELIPS Suite, et le « smartphone » avec ELIPS Studio.
Notre objectif pour les années à venir est d’un côté d’assoir et de pérenniser notre position de leader sur le marché « mass market », tout en se positionnant sur le marché du « smartphone » comme un acteur clé dans le développement d’applications mobiles.
Pensez-vous déjà à une stratégie commerciale (pricing, licence, …)? Laquelle?
Notre produit est aujourd'hui en beta gratuite, et nous travaillons sur son business modèle, au jour d'aujourd'hui, en voila les grandes lignes (qui pourront fortement changer):
- Une version gratuite, avec quasiment toutes les fonctionnalités, maisavec un bandeau de pub imposé dans l'application, dont on partage les revenus avec le développeur (en gros non seulement le tool est gratuit, mais en plus on vous paye !), on imposera aussi un spashscreen OpenPlug et peut être un logo sur l'icône de l'application sur les stores.
- Une version "indie", pour développeurs indépendants, quelques centaines d'euros pour une plateforme, ensuite un prix par plateforme additionnelle. Dans ce cas bien sur la pub est optionnelle, plus de splash screen
- Une version "small business" avec toutes les plateformes, des features plus premium (comme la possibilité de mixer du code natifavec de l'AS3) du support plus avancé un prix de quelques milliers d'euros avec des licences flottantes ou non
- Une version "enterprise" beaucoup plus à la carte et surtout un niveau de support très différent
Que pensez-vous du framework Slider annoncé pendant Adobe MAX 2009? Un réel concurrent pour vous?
En fait Slider va bien nous aider en défrichant pas mal de choses, comme tout ce qui est lié à la navigation dans une application et son adaptation entre différente plateformes. Ce que nous apportons se situe en fait dans l'adaptation et l'optimisation du framework Flex pour les plateformes: par exemple notre composant List est directement porté sur une vraie liste iPhone sur un iPhone, ce n'est pas un recodage en AS3 de quelque chose qui ressemble à l'iPhone: on retrouve la même physique si particulière (rebonds et autre), l'accélération matérielle de l'iPhone, et donc des performances et un rendu qui font qu'une liste n'est pas discernable entre une application en ObjectiveC et une application ELIPS.
Avec Slider nous allons donc faire de même: réutiliser les bons concepts de programmation que Slider introduit et les rendre plus proche de la plateforme, et plus performants.
D'un point de vue purement technique, que se cache derrière OpenPlug?
Pas mal de choses et de softs développés depuis 2002
En gros: notre plugin FlexBuilder passe tout le code AS3/MXML de l'utilisateur à notre compilateur (basé sur celui d'Adobe) qui génère du C/C++ pour tout ce code.
On compile ensuite ce source à l'aide d'une toolchain basée sur GCC, que nous avons mise au point et brevetée il y a quelques années, on y ajoute des librairies dépendantes de l'OS visé, implémentant les services flash, les adaptations aux widgets native, aux APIs de la plateforme, etc.
On a ensuite des packagers spécifiques pour chaque OS qui vont générer à partir de ce binaire et des fichiers de ressources utilisateurs (images, etc.), un package exécutable et déployable sur la plateforme visée.
Le code qui tourne est donc du code machine, directement exécuté, et optimisé au mieux de ce que peux faire le hardware… ce qu'aucun runtime basé sur bytecode (ou l'astuce utilisé pour le déploiement iPhone de CS5) ne pourra jamais véritablement atteindre.
Utilisez vous un serveur d'intégration continue? Test unitaires?
Nous avons effectivement des builds et test automatiques qui tournent toutes les nuits.
Adobe vous a-t-il contacté? Quel contact avez-vous avec eux?
Nous sommes en contact avec Adobe depuis Février 2009. Nous avons présenté notre approche et lancé notre beta à MAX 2009, où Adobe nous avait invité.
Donc oui nous nous parlons
Même si aujourd'hui Adobe poursuit une stratégie un peu différente en essayant d'imposer son flash player sur toutes les plateformes avec plus ou moins de bonheur.
Quel est selon vous le plus grand défi du développement Mobile?
En premier lieu, la fragmentation, comment développer de manière efficace pour autant d'OS, autant de moyen de déploiements (les différents appstore et leurs règles), comment tester?
Vient ensuite les spécificités du développement mobile: l'interaction utilisateur est totalement différente, chaque plateforme a des paradigmes de développement différents.
Quoi qu'on nous dise, les problèmes de gestion de la mémoire, du processeur, de la batterie, de la bande passante ne vont pas disparaitre, il faut donc développer avec ces contraintes en tête.
L'iPad? Révolution? Déjà dépassé?
Révolution, sans aucun doute : les groupes de média se sont réveillés le jour de la sortie de l'iPad, les départements de pub traditionnels des journaux (et non pas leur branche web) viennent de prendre conscience que la gratuité imposé par le net n'est pas une fatalité, et qu'un écosystème avec du contenu de qualité payant, avec une superbe expérience utilisateur pouvait voir le jour.
La révolution numérique des éditeurs, des journaux, bref de l'imprimerie arrive enfin.
Flash Player 10.1 et Air 2.0 sur Android pour fin 2010, vous n'avez pas peur que la communauté choisisse la solution Adobe plutôt que la votre?
Effectivement le flash player arrive en 2010 sur … Android 2.1 et versions futures, et de plus seulement pour les modèles haut de gamme avec 1Ghz etc… nous verrons alors ou notre produit en sera, mais je peux déjà affirmer que le nombre de téléphones supportés par ELIPS sera sans commune mesure . Et bien sur, du fait de notre lien bien plus fort avec le natif de la plateforme, la possibilité de faire du code natif spécifique pour chaque OS vont permettre aux développeurs de profiter au mieux de Flex … sans ses limitations et sans dépendre de la roadmap d’Adobe.
Ceci dit nos applications compilent aussi en flash et on ne s'interdit pas d'utiliser le flash player s’il est présent sur une plateforme, et pas sur une autre par exemple!
Plus la communauté des Flexer mobiles grandit, mieux c'est pour nous
Quels sont les plans pour OpenPlug dans le futur?
Continuer bien sur! Et voir jusqu'où nous mènera cette approche, en faisant grandir notre communauté…tout en y prenant plaisir!
Articles similaires
Mes projets (Open Source)
Autres
