# Abonnement

> [en] That all sounds great. However, as I mentioned, we love goodwill, and a lot of people wince when they hear “subscription.” The first thing that pops up in a user’s head are scammy companies that make cancellation a nightmare, like multi-level marketing schemes, gym memberships, and Adobe. The App Store prevents these shenanigans: you get a reminder email before renewal, and you can cancel within the *Settings* app in seconds. Whenever a company offers a subscription, I always try to buy it through the App Store.
>
> Some folks absolutely loathe subscriptions on *principle*, and ==will never rent something if they can own it==. This is not unreasonable. Halide is like a camera, and while professionals are used to renting gear, most consumers own their camera.
>
> <cite>*[Lux Year 4: Doubling Down](https://lux.camera/lux-year-4-doubling-down/)* ([cache](/david/cache/2021/0c45751cd69748ca779b1442b26ad6c3/))</cite>

Les créateurs de Halide (et Spectre) reviennent en détail sur leur stratégie, notamment financière, pour faire évoluer leur produit. J’utilise ces deux applications, aussi c’est d’autant plus intéressant de lire leurs doutes et leurs pistes vis à vis de cette évolution.

*Je ne crois pas avoir lu un seul retour de développeur d’application pour iOS qui ne se plaigne pas de l’AppStore.*

Ce n’est vraiment pas évident de trouver un moyen d’être rémunéré de manière stable et pérenne lorsqu’on vend un produit, surtout si on souhaite qu’il soit durable. Il y a des jours où j’aimerais me préoccuper de ces aspects là… et d’autres où je suis bien content de vendre ma « force de travail ». C’est un choix de vie qui m’offre pour l’instant une plus grande liberté d’esprit mais qui pourrait changer lorsque je n’aurai plus l’impression d’avoir suffisamment de <q>force</q> justement.

En tant que développeur, j’ai de plus en plus l’impression que l’on crée notre propre système d’abonnement en augmentant la complexité de nos outils et de notre *stack* (ça sonne toujours mieux en anglais), ce qui génère la nécessité d’une maintenance régulière assurant un fond de roulement. La « tierce maintenance applicative » n’est pas nouvelle mais elle me semble atteindre un tout autre niveau ces dernières années sur le Web.

On crée tranquillement notre propre besoin, [en étant sur-payé·es](http://megelison.com/poor-in-tech) ([cache](/david/cache/2021/86eba8e465d7ce11ef61a0c61f878f21/)), et personne ne semble s’en offusquer plus que ça…

> [en] And I’m not 100% sure, but I think this might contribute to longevity. Some of my clients are still working with the same sites I built for them nearly 10 years ago, a few with just minor security-related updates in the meantime and ==no other maintenance strictly required==. That’s not to say that those sites couldn’t use a “lick of paint” to bring them in to the 2020s; the point is that they *work*. And for organizations working on really tight budgets, or budgets that fluctuate wildly due to public funding, stability is really important. They can’t afford a developer on retainer to keep things running smoothly.
>
> <cite>*[Two articles on SPA or SPA-like sites vs alternatives](https://piperhaywood.com/two-articles-on-spa-or-spa-like-sites-vs-alternatives/)* ([cache](/david/cache/2021/d46752726e00de301573576176df1f1c/))</cite>

#produit #incompétence
