Très tôt, Dwolla a implémenté des "APIs" ("interfaces de programmation applicative") ouvertes qui permettent à quiconque d'intégrer librement son dispositif de paiement dans un site web ou une application mobile. Cette approche est classique et relativement courante, même si elle n'est pas (encore) universellement répandue. Elle souffre malgré tout d'un petit défaut : elle s'adresse plutôt à des développeurs expérimentés qui n'hésiteront pas à se plonger dans une documentation riche mais parfois aride.
Pour rendre sa solution plus accessible, Dwolla a donc décidé de créer une application de paiement pour iPhone et de la publier sous une licence libre (open source), offrant donc à n'importe qui de se l'approprier et de la modifier à sa convenance. Contrairement à la pratique usuelle de fournir des exemples d'utilisation des APIs, elle présente l'avantage d'être une mise en situation opérationnelle et directement réutilisable de toutes les fonctions disponibles (de l'authentification aux paiements, en passant, entre autres, par la localisation des commerçants partenaires).
De ce fait, l'application répond à 2 objectifs concrets. D'une part, elle constitue un porte-monnaie mobile prêt à l'emploi, qu'un tiers (par exemple un commerçant) peut très simplement mettre à ses couleurs (elle a été conçue pour cela) et redistribuer sous son nom. D'autre part, elle fournit des briques logicielles immédiatement exploitables par les développeurs qui créent leur propre solution, leur permettant de gagner un temps précieux tout en profitant des meilleures pratiques mises en œuvre par Dwolla.
L'initiative peut paraître anodine mais elle représente en réalité une excellente leçon à retenir pour toutes les entreprises qui veulent capitaliser sur les talents extérieurs afin d'accroître leur potentiel d'innovation. En effet, les ressources qu'elles mettent à disposition de tiers (qu'il s'agisse de données ou d'APIs) peuvent intéresser des personnes aux profils extrêmement variés (développeurs, designers, chercheurs…) et dont les ambitions ne sont pas toutes les mêmes.
Or, pour mieux profiter de la richesse qui découle de cette diversité, il faut fournir des "outils" adaptés à chacun. A titre d'illustration, les données et interfaces de programmation "brutes" répondront aux besoins des spécialistes souhaitant contrôler l'utilisation qu'ils en font dans ses moindres détails tandis que d'autres partenaires préfèreront des composants prêts à intégrer pour ajouter rapidement et sans aucune expertise les fonctions proposées dans de nouvelles solutions, ciblant d'autres besoins.
Il ne faut jamais l'oublier : la créativité peut s'exprimer sous de multiples formes et emprunter bien des voies différentes…