Pourquoi n'y a-t-il pas une culture de paiement pour les frameworks? [fermé]

L'un des effets secondaires de la tendance récente des startups "Lean" et de l'ère de l'App Store, est que les consommateurs sont plus acclimatés au paiement de petits prix pour de petits jeux / produits.

Par exemple.:

• SAAS en ligne qui facture ~ 5 $ / mois (le style de produit du camp de base)
• Des jeux courts, amusants et bon marché (0,99 $ sur l'App Store

Ce marché a été défini en «faisant bien une chose et en faisant payer les gens». DHH of Rails / 37 La renommée des signaux fait valoir que si votre site Web ne fait pas d'argent, ne vous embêtez pas à le faire.

Pourquoi la même règle ne s'applique-t-elle pas aux frameworks?

Il existe de nombreux projets de cadre logiciel, dont beaucoup sont matures et riches en fonctionnalités, qui offrent aux développeurs une valeur significative, mais il ne semble pas y avoir de marché ou de culture pour les payer.

Il semble que les projets qui facturent de l'argent sont souvent des choses comme des ensembles d'outils de composants d'interface utilisateur, et sont souvent marginalisés en faveur d'alternatives gratuites.

Pourquoi est-ce?

Les programmeurs / entreprises voient certainement la valeur de contribuer à des projets tels que Ruby, Rails, Hibernate, Spring, Ant, Groovy, Gradle, (la liste est longue).

Je ne suggère pas que ces cadres devraient commencer à être facturés à quiconque souhaite les utiliser, mais qu'il doit y avoir un modèle commercial significatif qui permettrait aux développeurs de gagner de l'argent à partir du moment où ils investissent dans le développement du cadre.

Vous pensez pourquoi ce modèle n'a pas émergé / réussi?

Modifier Pour être clair: ce n'est pas un article sur le fait de minimiser l'importance des logiciels libres et open source. Il s'agit d'un article sur la question de savoir pourquoi une culture de paiement pour les cadres n'existe pas.

Il y a absolument une éthique du trading valeur-valeur dans les logiciels libres / open-source.

Dans la plupart de l'économie, nous échangeons de l'argent contre un produit ou contre de l'argent. C'est très pratique de le faire. En effet, nous le faisons dans le secteur des logiciels commerciaux de l'économie.

Mais nous n'échangeons généralement pas de l'argent contre de l'amitié ou de l'argent contre une romance. Nous échangeons amitié contre amitié et romance contre romance.

De même, dans les logiciels libres / open-source, l'éthique consiste à rembourser la DHH et les contributeurs à Rails en: signalant les bogues, contribuant les correctifs, écrivant / mettant à jour / corrigeant la documentation et évangélisant Ruby, Rails, Linux, etc. des projets de logiciels libres / open-source en général. C'est ainsi que nous échangeons valeur / valeur.

Demander pourquoi "ce modèle [facturer de l'argent pour les frameworks] n'a pas émergé / réussi" revient à se demander pourquoi ce même modèle n'a pas émergé / réussi quand il s'agit d'amitiés ou de romance. Quelqu'un qui offre de l'amitié ne veut pas d'argent - il veut de l'amitié en retour. De même la romance. De même, dans de nombreux cas, des logiciels.

Je pense que cette question peut être répondue par des réponses à cette question Pourquoi les programmeurs écrivent-ils des applications de source fermée et les rendent-ils ensuite gratuits? .

Et je voudrais juste y ajouter:

Ce que je crois, c'est qu'en rendant le framework gratuit, nous permettons aux programmeurs débutants et amateurs de s'intéresser à la programmation sérieuse. Cela leur facilite le chemin. Nous avons déjà vu que les plateformes qui ne sont pas gratuites sont souvent moins adoptées que celles qui le sont. De plus, les cadres gratuits sont généralement développés par un groupe de personnes qui souhaitaient contribuer à la communauté.

Il semble toujours se résumer à l'une des deux cultures différentes. Il y a le groupe "Je paie pour les logiciels avec de l'argent" et le groupe "Je paie pour les logiciels avec du temps".

Considérez l'informatique dans une organisation. Supposons qu'une entreprise souhaite effectuer une surveillance du réseau. C'est soit A) Mission critique et digne de pomper des tonnes d'argent dans (Openview, Netcool). Ou B) Budget serré, faites ce que vous pouvez avec moins (Nagios, MRTG).

De même, il y a des gens qui ont "grandi" avec l'approche Microsoft / Apple d'approcher les logiciels. Vous payez de l'argent et tout ça devrait marcher. Vous voulez de nouvelles fonctionnalités, vous les payez. D'un autre côté, il y a des gens qui se sont habitués à payer avec leur temps. Unix, Open source, java, etc. Si vous voulez plus de fonctionnalités, vous l'écrivez vous-même ou permettez à quelqu'un de le réparer pour vous.

Considérez l'App Store d'Apple sur le marché Android. Vous achetez Angry Birds sur iPhone, mais vous l'obtenez gratuitement (avec des publicités) sur Android. Différentes cultures au travail. Angry Birds remporte un franc succès sur l'App Store en facturant un maigre 0,9 centime, mais ils savaient que cela aurait une très petite part de marché s'ils facturaient même un 0,25 sur Android Market.

Je pense que les cadres ont commencé dans ce dernier camp, et c'est ainsi que cela se passe pour l'instant. Vous ne pouvez pas commercialiser un cadre comme une grand-mère de produit fini peut utiliser, quelqu'un doit investir du temps pour en faire un consommable. Les gens qui ont l'habitude de consacrer du temps ne sont pas habitués à payer avec du temps et de l'argent.

Les programmeurs / entreprises voient certainement la valeur de contribuer à des projets tels que Ruby, Rails, Hibernate, Spring, Ant, Groovy, Gradle, (la liste est longue).

D'après mon expérience avec les clients et les employeurs, j'ai remarqué plusieurs raisons pour lesquelles les entreprises qui utilisent fortement les logiciels Open Source (et qui font ou économisent beaucoup d'argent en l'utilisant) ne redonnent pas autant qu'elles le pourraient:

• Pas de compréhension du fonctionnement du modèle Open Source, et donc une prise de conscience manquante de la nécessité des dons pour maintenir des projets solides

• Souvent, un manque de clarté sur ce qui va se passer avec un don

• Questions fiscales, incertitude sur la déductibilité

• Difficultés pour les techniciens justifiant les dons (ou autres moyens de redonner comme l'organisation d'événements, etc.) face à une gestion / contrôle non éclairé ("Si nous n'avons pas à payer pour cela, pourquoi devrions-nous leur donner de l'argent? Pour être gentil "Nous n'avons pas le budget pour ça. Peut-être l'année prochaine")

J'ai tendance à penser que chacun de ces problèmes pourrait être abordé dans une certaine mesure dans n'importe quel projet Open Source, mais ce n'est généralement pas fait en raison du manque d'expertise sur la façon de communiquer plus clairement et d'une certaine réticence à demander aux entreprises des dons de manière plus prospective. façon.

J'aime l'esprit «pas d'argent, pas de bureaucratie, pas d'obligations» de la communauté Open Source, mais je pense parfois - et si chaque entreprise qui utilise, disons, OpenOffice au lieu d'une licence de bureau MS Office de 200 $ donnerait seulement 2 $ à OOo, ou un autre projet Open Source?

Le principal risque d'utiliser un logiciel open source est le fait qu'il ne dispose d'aucun support officiel. Fondamentalement, vous possédez le code. Alors qu'au début, il semble plus rentable d'utiliser un logiciel "gratuit", vous devez tenir compte de la possibilité que les coûts de maintenance interne puissent éventuellement dépasser le coût d'une solution propriétaire. Certaines organisations ne sont pas disposées à prendre ce risque.

Une partie de la question semble comparer les cadres avec le paiement des applications (par exemple, des jeux amusants, 37 produits de signal, SAAS en ligne) mais ce sont des pommes et des oranges. Les consommateurs achètent des applications tandis que les développeurs utilisent des cadres pour créer des applications pour les consommateurs. Et bien sûr, votre développeur peut être un consommateur s'il est un utilisateur et achète des applications, lorsqu'il ne développe pas sur des frameworks.

Les cadres ne font rien hors de la boîte jusqu'à ce qu'ils soient transformés en applications qui peuvent être vendues.

Cependant, si nous comparons simplement des outils de développement, comme les frameworks vs les ensembles de composants vs les suites RAD, etc., je pense qu'il y a une bonne discussion à avoir sur le type de choses payées et non.

Imaginons que je crée un framework appelé "AwesomeWork" (original hein?). Maintenant, les gens ne l'ont jamais utilisé et ne sont pas sûrs que cela les aidera et ne voudraient pas payer de l'argent pour quelque chose qui pourrait ne pas leur être bénéfique du tout (s'ils l'aiment même!), Alors je le libère gratuitement. Maintenant, suis-je un imbécile d'avoir perdu des bénéfices potentiels parce que j'ai peut-être pu m'en tirer en le vendant pour 5 $ la licence? Non, car à mesure que je passe le mot et que les gens commencent à utiliser mon framework, il y a un marché secondaire qui s'est ouvert: les livres. Je peux maintenant écrire un livre sur AwesomeWork (appelons-le "Do [Awesome] Work Son!", Désolé de devoir le faire en). Donc, les ventes du livre sont stables, maintenant je décide de faire quelques mises à jour d'AwesomeWork et de le publier sous AwesomeWork 2.0 et voilà que je peux vendre "Do [Awesome] Work Son!

Je ne dis pas que le scénario ci-dessus est la principale raison pour laquelle quelqu'un publierait son framework gratuitement, mais cela montre qu'il peut toujours faire de l'argent en le faisant.

Note latérale: Il y a quelques frameworks qui facturent (bien qu'ils puissent offrir une édition communautaire gratuitement mais avec des fonctionnalités limitées). Celui qui me vient à l'esprit est WebSharper , qui permet aux sites Web d'être entièrement écrits en F #.