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.





