Acquisition d'OpenPlug par Alcatel
C'est maintenant officiel, Alcatel-Lucent a racheté la société française OpenPlug:
Alcatel-Lucent acquires OpenPlug, a cross-platform mobile software development tool provider
Après avoir racheté ProgrammableWeb en juin, Alcatel montre une vraie envie de s'immiscer dans le monde mobile. Après des années de silence sur le marché du mobile (rappelez-vous, les mobiles Alcatel avec le joystick qui durait 2 semaines), Alcatel pointe donc le bout de son nez.
Bonne nouvelle pour OpenPlug?
Sûrement oui ^^. C'est souvent le but des startups, de monter monter puis de se faire racheter. Google ou Oracle par exemple sont friands de ce genre d'entreprise innovante. Cette annonce se fait 1-2 mois après le lancement commercial (avec pricing) de la suite ELIPS d'OpenPlug
L'appellation OpenPlug sera encore utilisée quelques temps puis sera le système sera intégrée à l'existant d'Alcatel:
“In the short term the service will continue to use the OpenPlug brand,” said Monson, though OpenPlug will also be included in Alcatel-Lucent’s Developer Platform and Open API Service.
Bonne nouvelle pour les utilisateurs? A mon avis, on verra. Ce genre de merge peut ralentir la marche d'OpenPlug qui a encore du chemin à faire. Certes, OpenPlug joue sur toutes les plate-formes (je ne sais pas s'ils ont eu la confirmation écrite de la part d'Apple confirmant que leur système respecte bien les derniers termes de licence du SDK Apple) mais la concurrence est rude.
Notamment, les grands points à améliorer (lorsque je l'avais testé), sont:
- Emulateur "bricolé", très loin de ce que l'on peut expérimenter avec les émulateurs natifs
- Taille des applications générées bien trop importantes
- Compilation qui prend des plombes (conversion C)
- Pas de gestion des librairies SWC
- Des tutoriaux pas assez touffus
Je ne vais pas forcement comparer avec la solution Adobe Air sur Android que je préfère. C'est quand même très plaisant d'avoir un runtime qui va assurer un rendu sans trop se pré-occuper du système derrière. En fait, j'aimerai juste qu'OpenPlug arrête un peu de faire ce que je considère presque comme de la publicité mensongère:
Create Cross-Platform Native Mobile Apps in Flex with ELIPS Studio
Non, on ne code pas "en Flex", on code "à la manière de Flex" s'il on veut. On peut dire que l'on peut écrire du code MXML (déclaratif) et de l'ActionScript mais ce n'est pas du Flex derrière. Avec Air pour Android, oui on code en Flex, pas avec OpenPlug.
Enfin bon, souhaitons quand même bonne continuation à OpenPlug 
OpenPlug publie sa liste de tarifs pour la version finale
Cela faisait un moment que je n'avais pas parlé d'OpenPlug pour diverses raisons mais après 5 versions beta, la version finale n'est plus très loin. Une version beta 6 et 7 sont prévues, rajoutez donc quelques semaines pour avoir la date de release.
Outre les nouveautés comme la compatibilité Flex 4, les extensions native pour Android, …(Voir la liste complète), OpenPlug a définit son futur mode de commercialisation. Celui-ci se fera sous forme de licence avec 4 niveaux différents:
- Free
- Pro
- Premium
- Indie
Vous pourrez ainsi choisir votre licence suivant le type de consommation que vous aurez. Notez que la version gratuite vous permet de créer des applications mais vous oblige à placer une bannière de publicité sur votre application (dont vous partagerez les revenus avec OpenPlug). Pour l'instant, comme Elips Studio est en beta, vous n'avez accès qu'à la version Free.
Voici le récap:
Plus de détails sur le pricing
OpenPlug est pour l'instant la seule technologie qui vous permet de créer des applications iPhone / Android / Symbian (et d'autres je crois) sur la même base de code (framework Flex modifié pour pouvoir être compilé en C++). Pour l'instant, les applications iPhone sont encore acceptées, malgré le fait qu'OpenPlug tombe (à mon sens tout du moins) sous le coup des nouveaux Terms Of Service du iPhone SDK (car les applications ne sont pas originellement codées en Objective-C). Apple refusera peut-être ces applications dans le futur, peut-être pas, qui sait…
Contrairement à ce que j'avais annoncé sur le blog, je ne continuerai pas à faire des tutoriaux sur l'utilisation d'OpenPlug. La raison est plutôt simple, il y a énormément de choses à dire sur ce que l'on peut maintenant faire avec Flash Player 10.1 et Air 2 sur Android. Je vais plutôt me diriger dans cette direction car c'est aussi dans cette direction que je me dirige dans mon environnement professionnel. Je vais donc traiter plutôt cet aspect du développement mobile, dès que j'aurai un peu de temps libre !
Apple se la joue à huis clos
Si cette nouvelle avait éclaté une semaine plus tôt, je l'aurai volontiers pris comme un poisson d'Avril. Mais non, la dernière prouesse d'Apple n'est pas une blague, et cela va sûrement faire pleurer pas mal de développeurs.
Pour la sortie prochaine de leur iPhone SDK 4.0, Apple a décidé de mettre à jour leurs Terms of Service. D'habitude, c'est la partie où l'on clique "I agree > Next" sans trop y réflechir mais voilà ce que les nouveaux ToS stipulent:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Pour le coup des APIs private/public c'était déjà le cas, pas de changement de ce côté-là. Au passage, ce n'était pas super non plus pour les développeurs qui n'avaient pas accès à certaines fonctionnalités dont leurs applications avaient besoin. Par exemple, si vous faites une application permettant de lire un livre sur votre iPhone, vous souhaiteriez peut-être jour avec la luminosité de l'écran. Pourtant, si vous faîtes cela, vous êtes en dehors des régulations d'Apple et votre application ne sera jamais acceptée sur le AppStore par Apple. Ah oui et l'application officielle d'Apple (iBooks je crois) peut le faire. Vos applications seront donc toujours des applications de second rang par rapport à celles d'Apple. Cool, non?
Là où il y a un vrai changement, c'est sur la seconde partie. Celle-ci vous interdit d'utiliser une couche de compatibilité ou un outil permettant de créer des applications iPhone, vous devez obligatoirement l'écrire en C/C++/Objective-C directement. Si on suit ces instructions à la lettre, cela signifie que si vous utilisez un outil "Code Once, Deploy Everywhere" tels que Titanium (JavaScript vers applications mobiles natives) ou OpenPlug (Flex/AS vers applications mobiles natives), vos applications ne passeront pas la barrière de l'AppStore.
Encore mieux, vous savez sûrement qu'Adobe va sortir sa CS5 dans 3 jours. Dans cette nouvelle mouture de la Creative Suite, il y a le très attendu Flash Pro CS5 et son packager iPhone, vous permettant d'exporter vos "applications Flash" en applications iPhone ou iPad. Il y a bien sûr d'autres fonctionnalités mais celle-ci était de loin, la plus attendue. Et bien le packager pour iPhone de Flash CS5 tombe sous le coup de cette nouvelle régulation.
Adobe a répondu par son twitter de manière concise (pas trop le choix sur twitter héhé):
We are looking into the new SDK language. We continue to develop Packager for iPhone OS which will debut in Flash #CS5
Bref, à quelques jours de la sortie, cela doit être un peu la panique chez Adobe, on verra s'ils arriveront à contourner le problème d'une certaine manière. Certains diront que c'était un peu jouer avec le feu de sortir ce package pour iPhone OS et qu'Adobe se brûle maintenant les doigts. Certains parlent de poursuites en justice, d'autres espèrent voir Steve Jobs en prison. Bref, ça fuse dans tous les sens ^^
Adobe n'est pas le seul à avoir peur
On y voit clairement une attaque directe d'Apple sur Adobe mais puisque les ToS sont généralisés et pas spécifiques à Adobe, les autres se font aussi du souci sur leur futur:
- Titanium: iPhone OS 4.0 Announcement and Our Commitment to You
- Unity 3D: iPhone OS4 Today
- PhoneGap
- MonoTouch: MonoTouch Not Supported on iPhone OS 4.0
- OpenPlug
Certains sont "petits", d'autres sont là depuis longtemps. Tous proposent des outils permettant d'une certaine manière, de générer des applications iPhone/iPad. Certains comme Unity 3D proposent des outils qui ne sont pas disponibles de base avec XCode et ont permis à des développeurs de mettre leur application sur l'AppStore depuis des mois. Que va-t-il donc arriver à ses applications qui ont été sur l'AppStore avant ce changement de régulation? Suppression lors de la prochaine update de l'iPhone OS? Un coup de Jailbreak pour tout le monde?
Personne du côté d'Apple ne semble donner de réponse sur ces points plutôt critiques et tous semblent un peu être dans l'attente. Toutes ces entreprises se trouvent dos au mur. Si Apple décide vraiment de bannir ces outils, la plupart peuvent mettre la clé sous la porte.
Ce qu'il vous faut pour faire des applications iPhone / iPad
Prenez votre livre de recette. Pour faire une application pour iPhone, il faut:
- Apprendre le language d'Apple, l'Objective-C, qui ne vous servira qu'à cela d'ailleurs
- Travailler avec XCode, jetez votre IDE favori par la fenêtre
- Acheter un Mac, sinon vous ne pourrez jamais publier votre application sur l'AppStore
- Payer pour pouvoir être présent dans l'AppStore
- Développer sans utiliser de Runtime ou d'API qui ne soit pas public
- Croiser les doigts pour que votre application ne soit pas rejetée à l'entrée de l'AppStore
- Serrer les fesses pour qu'elle ne se fasse pas jeter de l'AppStore dans les prochains mois car Apple à changé ses règles en cours de route
- Subir les prochaines restrictions qu'Apple va vous infliger (nouveau système de publicité etc.)
Point de vue personnel
J'ai été très déçu de voir cette nouvelle ce matin dans mes feeds. Très déçu aussi de voir que personne ne sait à quoi s'en tenir et que tout le monde attend une réponse de la part d'Apple (qui arrivera on ne sait quand).
Sortie du SDK OpenPlug 3 beta 4
En beta 3, OpenPlug annonçait le support des plate-formes Android et bien d'autres choses. C'est à ce moment là que j'ai testé cette technologie de développement Flex-like pour mobile et je n'en avait pas un une très bonne impression. Entre temps, la beta 4 est sortie et corrige de nombreux points, surtout pour le support Android:
Voir les Release Notes OpenPlug 3 beta 4
Pour le téléchargement du nouveau SDK, vous devez vous enregistrer sur leur site et aller dans la section Download.
Télécharger le SDK ElipsFlexSDK 3.0.1.230
Les applications Android sont bien plus fluides qu'avant et moins buggées notamment au niveau de la gestion du texte et des basculements d'orientation d'écran.
J'ai pu lire sur les release notes que la méthode clone() sur Point et les propriété topLeft et bottomRight de la classe Rectangle ainsi que la classe Shape ont été implémentées. Cela fait partie des points bloquants que j'avais soulevé dans ma première review. Cela fait plaisir d'être entendu si rapidement ^^.
Maintenant, il ne reste plus qu'à coder 
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.
Mes projets (Open Source)
Autres
