1 points par GN⁺ 2023-11-15 | 1 commentaires | Partager sur WhatsApp
  • Placemark n’a pas réussi à devenir une startup bootstrap pérenne et engage donc la fermeture de son produit et de son activité
  • Les nouvelles inscriptions sont suspendues, et les clients existants pourront continuer à l’utiliser gratuitement jusqu’au 19 janvier 2024
  • Les serveurs seront arrêtés à cette date, les utilisateurs actuels doivent donc s’y préparer en fonction du calendrier de fin de service
  • Le code source complet du site devrait être publié fin janvier 2024, mais la préparation pourrait prendre du temps en raison de la taille de l’application
  • Tom MacWright explique que construire Placemark a été une expérience réjouissante, même s’il a été difficile de ne pas trouver de modèle durable

Calendrier de fermeture du service et publication du code source

  • Le produit et l’entreprise Placemark n’ont pas réussi à s’inscrire dans la durée comme startup bootstrap pérenne
  • Les nouvelles inscriptions sont suspendues
  • Les clients existants pourront utiliser Placemark gratuitement jusqu’au 19 janvier 2024
  • Les serveurs seront arrêtés le 19 janvier 2024
  • Le code source complet du site devrait être publié fin janvier 2024
    • La préparation de cette publication pourrait prendre un peu de temps en raison de la taille de l’application

Le parcours de création et la suite

  • Placemark était un produit réellement utilisé par certains utilisateurs, mais n’a pas trouvé de structure viable sur le plan commercial
  • Le processus de création du produit a été très agréable, et même si l’absence de succès et de pérennité a été difficile, cela se conclut par un résultat qu’il peut accepter
  • Tom MacWright remercie les utilisateurs qui ont essayé Placemark ainsi que les personnes qui l’ont soutenu
  • Il travaille actuellement chez Val Town à rendre le code plus simple et moins intimidant

1 commentaires

 
GN⁺ 2023-11-15
Avis de Hacker News
  • Il n’est pas facile de bâtir une entreprise avec du logiciel. Pour en vivre, il faut énormément de clients à 20 $, et même si le coût marginal d’un utilisateur est faible, il est très difficile d’amener les gens à ouvrir leur portefeuille pour du logiciel.
    Cela contraste avec ces mêmes personnes qui achètent souvent des serveurs coûteux et hésitent beaucoup moins pour du matériel.
    Je serais curieux d’en savoir un peu plus sur la taille des clients entreprise visés. Plusieurs personnes sont venues me voir, mais en tenant compte de tous les coûts, il était très rare que le revenu horaire soit meilleur que dans un emploi salarié classique.
    20 % de mes revenus proviennent de ventes liées à mon logiciel open source, et j’espère qu’un jour ce sera 100 %, pour pouvoir m’y consacrer pleinement.

    • Je fais moi aussi partie des utilisateurs qui rechignent même devant un abonnement à 10 $. Parce que ce type d’abonnement devient l’un des 10 à 20 abonnements “vraiment utiles et qui valent le coup”.
      Pour une petite startup en particulier, 10 $ par utilisateur finissent vite par peser lourd, et quand on regarde s’il y a le budget pour recruter quelqu’un, il faut considérer tous les abonnements ensemble.
      J’aimerais qu’il existe un service où l’on fixe un budget, par exemple 500 à 1000 $ par mois, où l’on choisit parmi les services disponibles sur la plateforme ceux dont on a besoin, où l’on indique la taille de l’équipe, puis où les vendeurs enchérissent. Ce service pourrait aussi fournir le SSO pour chacun de ces services.
      Même s’ils ne peuvent pas facturer 20 $ par utilisateur, ils pourraient probablement obtenir 5 à 10 % de l’ensemble des utilisateurs de ce service.
    • La plupart des prix d’abonnement sont très déconnectés des coûts du logiciel/SaaS. Hors coûts liés au capital-risque, les apps et web apps doivent rivaliser sur autre chose que leur simple utilité.
      On parlait de clients à 20 $ ; il suffit de regarder les prix de Google Workspace ou d’Office.
      https://workspace.google.com/pricing.html
      https://www.microsoft.com/en-us/microsoft-365/buy/compare-al...
      La tarification par version était favorable aux développeurs indépendants, car les utilisateurs se souciaient relativement peu du fournisseur. Office propose d’ailleurs encore une tarification par version autour de 149 $.
      Avec la tarification par abonnement, les indépendants essaient de facturer plus cher que les acteurs établis de l’entreprise, souvent plusieurs fois plus cher ; dès qu’un acteur capable de lancer à grande échelle existe, le marché devient difficilement soutenable pour un nouvel entrant indépendant.
      Au final, il existe bien une niche d’acheteurs qui prennent des abonnements indés, mais c’est trop cher pour attirer tous les utilisateurs et atteindre une taille de marché grand public.
  • Cela aurait été encore mieux que le passage en open source ait lieu avant l’arrêt des serveurs. Si des utilisateurs en dépendaient, cela leur aurait laissé du temps pour migrer.
    Cela dit, la publication elle-même reste bien meilleure que ce que feraient 98 % des entreprises du secteur, et cette attitude me donne envie d’essayer les autres produits créés par cette personne.

    • Il peut y avoir des vulnérabilités encore non découvertes dans le service, et on peut craindre que publier le code source avant la fermeture facilite la tâche d’acteurs malveillants pour les trouver et compromettre les données des utilisateurs.
    • C’est juste. Si c’est vraiment important pour quelqu’un, il pourrait voir cette annonce et contacter Tom pour discuter d’une solution.
      Il pourrait aussi aider à tester que la version open source fournie fonctionne correctement ; il a l’air d’être quelqu’un qui répondrait à ce genre de demande de manière raisonnable et attentive.
  • Quand un service qui échoue n’a pas trouvé de modèle durable, il est fréquent que le code soit laissé de côté ou jeté ; j’apprécie le fait qu’il ait annoncé vouloir tout publier en open source.

    • “Il suffit de le publier en open source” n’est pas toujours une option possible. La propriété intellectuelle peut être verrouillée pour toutes sortes de raisons, et le fondateur n’a pas toujours le droit de la publier comme il l’entend.
    • Si la plupart des startups échouent, je me demande si ce ne serait pas une bonne idée de promettre cela dès le départ. On pourrait même s’y engager de manière non publique, sans que cela contredise l’objectif de réussite.
      Sans ce genre d’engagement, cela devient un problème bien pire que la dette technique.
    • Parmi les bases de code publiées par des startups qui ont échoué, combien ont réussi comme projets open source ? Peut-on en citer ne serait-ce qu’un ?
    • À l’inverse, l’attitude “je ne voyais pas assez de valeur pour payer ton service, mais maintenant qu’il a coulé et qu’il est open source, je vais l’utiliser” est aussi un peu agaçante.
      Je comprends très bien l’état d’esprit d’un fondateur de startup qui n’a pas envie de donner gratuitement quelque chose que personne ne voulait acheter.
    • À noter que l’auteur de la soumission HN, “Tomte”, partage trois lettres avec le prénom, mais n’est pas Tom MacWright, le créateur de Placemark.
  • Le nouveau projet Val(https://val.town) qu’il construit actuellement est vraiment excellent.
    Je l’utilise depuis quelques mois et j’y prends plaisir.

    • Cet exemple en dit plus sur les fondateurs que sur le produit lui-même.
  • J’ai utilisé Placemark pendant plus d’un an pour créer des graphiques personnalisés basés sur des cartes pour torontoverse.com. Il existe beaucoup de web apps dans ce domaine, et QGIS est toujours là, mais personnellement j’ai trouvé que Placemark trouvait un très bon équilibre entre simplicité et puissance.

  • Pour ceux qui suivent ce secteur, j’ai récemment découvert un concurrent intéressant : https://felt.com/
    Le produit est assez agréable visuellement et les fonctionnalités sont solides. C’est une bonne chose que les outils SIG deviennent plus accessibles.

    • Je vais bientôt à une conférence SIG et j’ai vu Felt dans la liste des sessions. Jusqu’ici, je ne savais pas ce que c’était.
  • Je ne connaissais pas l’app, mais c’est une excellente annonce de fermeture. Elle est claire, va droit au but, n’enrobe pas l’échec de la monétisation dans des formules corporate du genre “environnement macroéconomique”, donne aux clients une période de transition raisonnable, et inclut une remise. Elle mentionne aussi la gratuité et, enfin, la publication en open source.
    Avec un texte comme celui-ci, j’aurais confiance dans le fondateur et envie de devenir client de son prochain projet.

  • C’est dommage. Placemark était un très bon outil pour la collecte d’objets géographiques avec des données associées bien structurées. Cette structuration devient toujours un obstacle quand on intègre les données générées dans d’autres systèmes.
    Notre coopérative construit aussi quelque chose de similaire à Placemark : https://cocarto.com
    Mais notre modèle économique n’est pas de le vendre comme SaaS ; il consiste à fournir des services autour du produit à des entreprises et des administrations. Comme il est toujours difficile, et très capitalistique, d’atteindre suffisamment de clients en SaaS, nous l’avons conçu dès le départ comme logiciel libre et open source.

    • Le modèle consistant à “vendre des services autour du produit à des entreprises et des administrations” ne fonctionne pas pour tout le monde.
      Certaines startups n’ont pas les moyens de consacrer les deux tiers de leurs ressources au support. C’est dommage qu’il n’existe généralement pas de voie intermédiaire pour structurer une entreprise autour d’un logiciel libre et open source.
  • Le prix me semble étrange. C’est 20 $ par utilisateur et par mois, mais pour collaborer, l’autre personne doit aussi payer. Donc le minimum est 40 $ par mois, non ? Cela paraît être une barrière à l’entrée assez importante.

    • N’est-ce pas un outil SIG très spécialisé ? Dans ce cas, ce prix ne me paraît pas être une barrière. On dirait plutôt un marché plus petit, avec des outils déjà bien établis.
      Je n’ai pas vérifié si c’était le cas, mais une licence d’organisation incluant un lot d’utilisateurs aurait peut-être été plus adaptée.
  • C’était peut-être trop ambitieux. Était-il vraiment nécessaire de proposer de l’édition collaborative en temps réel ? Cette fonctionnalité semble excessive.
    Je comprends que toutes les startups veuillent une fonctionnalité phare qui crée un argument de vente différenciant, mais cela semble avoir demandé beaucoup trop d’efforts pour une demande probablement limitée. Ce n’est bien sûr qu’une supposition.

    • L’expérience utilisateur collaborative est beaucoup plus facile à bien réaliser qu’avant. Il existe beaucoup de bibliothèques utiles, comme yjs.
      Nous avons ajouté en moins d’une semaine à notre éditeur de blocs basé sur ProseMirror des raffinements et des éléments amusants comme les curseurs multiples.
    • C’est une hypothèse plausible. Certains clients ont bien bénéficié de l’édition en temps réel, mais c’était un gros pari technique et cela a conduit à une conception difficile à faire passer à l’échelle avec des jeux de données plus volumineux.