Libération de Feedbin, lecteur de flux RSS/ATOM

Posté par  (site web personnel, Mastodon) . Édité par ZeroHeure et palm123. Modéré par Nÿco. Licence CC By‑SA.
Étiquettes :
26
6
sept.
2013
Internet

L'extinction de Google Reader aura été un mal pour un bien. En plus de raviver la concurrence comme jamais sur le front des aggrégateurs de flux, elle a clairement mis en lumière à la fois les problèmes de dépendance et de maîtrise des données des solutions type cloud / SaaS et fermées, mais aussi le fait que les flux RSS/Atom ne sont pas morts. Cependant, l'histoire semble bégayer et la solution qui a le vent en poupe est actuellement Feedly, qui a effectivement tout pour plaire : application web, interface proche de GReader, principales fonctionnalités gratuites (pour le moment ?), des applications mobiles, une API (Normandy), etc. Cependant, les solutions libres ne sont pas en reste : Oumph a écrit une petite synthèse le mois dernier.

Un petit nouveau vient de les rejoindre : Feedbin. Enfin, nouveau, c'est une façon de parler ; il s'agit d'un logiciel propriétaire qui vient d'être libéré sous licence MIT.

Logo Feedbin

Feedbin est donc un agrégateur de flux RSS et Atom (si vous avez lu jusque là, vous vous en doutiez un peu) sous forme d'une application Web à l'interface simple, moderne, assez réactive et fluide. Il propose tout un tas de fonctions qui ont fait ou font le succès des compétiteurs: raccourcis claviers, tags, partage, import/export, utilisation de Readability, etc. et désormais, le contrôle sur vos données et l'assurance qu'elles pourront rester privées.

L'auteur continue de proposer une offre d'hébergement à 3 $ par mois si vous ne souhaitez pas l'installer vous même.

Capture d'écran Feedbin

Les raisons avancées par le développeur sur son blog pour la libération du code sont triples :

  1. Attirer des contributions extérieures pour l'aider ;
  2. La transparence qu'il affectionne particulièrement, or l'accès au code source est certainement l'un des meilleurs exemples de transparence ;
  3. S'assurer que son projet ne subisse pas le sort du défunt Google Reader.

Codé en Ruby (on Rails), le code source est disponible sur le désormais incontournable Github. Mais pourquoi se réfugier dans un modèle que l'on quitte alors que Gitorious ou Gitlab existent ?

Aller plus loin

  • # Pourquoi Github ?

    Posté par  . Évalué à 5.

    Parce que simplement, gitlab et gitorious sont durs à installer et nécessite des ressources. Et chez moi, j'ai mes DNS, un masq (pour openID), un mozilla-sync, un 0bin, un roundcube, un tt-rss, bref, des tas de trucs, mais j'en ai pas trop chié pour les installer. J'ai lu la doc de gitorious et gitlab, et c'est pas encore ça.

    Bon, c'est pas encore aussi difficile que NewsBlur, mais quand même :)

    • [^] # Re: Pourquoi Github ?

      Posté par  . Évalué à 4.

      La dernière version de gitorious est plus simple à installer, mais ce n'est pas trivial. Par contre, ils proposent un service gratuit (ou payant) avec gitorious.org. Ça tourne bien, et la philosophie est bien différente de github.

      Si tu ne sais pas demande, si tu sais partage !

      • [^] # Re: Pourquoi Github ?

        Posté par  (site web personnel) . Évalué à 3.

        Sérieusement, tu as déjà utilisé Gitorious pour un de tes projets?
        Ou bien ne serais-ce que essayé d'y trouver des choses, par exemple pour les dépôts Qt?
        Je me souviens y avoir passé plus de 30 minutes, pour chercher un commit que j'ai jamais trouvé.
        J'ai fini par utiliser Woboq ( http://code.woboq.org/qt5/ ) pour trouver ce que je cherchais.

        Leur interface est complètement obscure, j'ai jamais réussi à y trouver quoi que ce soit.

        • [^] # Re: Pourquoi Github ?

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Tu veux dire que tu utilises une WUI pour chercher un commit alors que git a tous les outils nécessaires pour ça ?

          • [^] # Re: Pourquoi Github ?

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 06 septembre 2013 à 15:38.

            Tu as déjà checkouté Qt en entier? Tu sais quelle taille ça fait?
            Tu sais probablement que Git impose de checkout le repo en entier, non?

            • [^] # Re: Pourquoi Github ?

              Posté par  . Évalué à 1.

              Le dépôt entier mais pas nécessairement tout l'historique.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Pourquoi Github ?

                Posté par  . Évalué à 1. Dernière modification le 06 septembre 2013 à 20:54.

                Le dépôt entier mais pas nécessairement tout l'historique

                En disant cela tu prouves que tu n'as pas compris comment fonctionne git …

                PS : à moins que ce soit moi

                • [^] # Re: Pourquoi Github ?

                  Posté par  . Évalué à 6.

                  Dans la page d'aide de git clone, on trouve :

                  --depth <depth>
                             Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a
                             number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only
                             interested in the recent history of a large project with a long history, and would want to send in fixes as patches.
                  

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Pourquoi Github ?

              Posté par  (site web personnel, Mastodon) . Évalué à 1.

              Mais alors, quel est l'intérêt de chercher dans l'historique si ce n'est pour travailler dessus ?

              • [^] # Re: Pourquoi Github ?

                Posté par  (site web personnel) . Évalué à 2. Dernière modification le 07 septembre 2013 à 07:35.

                Il y a 2 façons de récupérer qt : check out le git entier, et tu en as pour plusieurs Go de données, soit télécharger une tarball des fichiers sans l'historique (200Mo).
                Ma façon la plus saine si tu veux pas y passer 6 heures est de DL la tarball et si besoin consulter l'historique sur gitorious ou autres.

                • [^] # Re: Pourquoi Github ?

                  Posté par  . Évalué à 2.

                  Ma façon la plus saine si tu veux pas y passer 6 heures est de DL la tarball et si besoin consulter l'historique sur gitorious ou autres.

                  Moi je préfère faire un git clone avec l'option --depth 1 ça permet d'utiliser git grep et git ls-files.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Pourquoi Github ?

        Posté par  . Évalué à 3.

        Question naïve du vendredi. Que reproche-ton à GitHub ?

        Je l'utilise car je participe à un projet qui y est hébergé. J'en sais peu de choses sinon que le code de la plate-forme est proprio, que l'hébergement est gratuit si le code est public, et payant pour l'hébergement de projets privés. C'est pratique, joli. On voit une volonté de "fidéliser" avec par exemple plein de stats sur l'activité des profils, pour inciter à brasser de l'air intervenir sur des projets pour augmenter ses points de XP son nombre de contributions.

        Les alternatives citées ici sont des plateformes libres, dont l'une propose un hébergement gratuit pour des projets libres.

        En quoi la philosophie est-elle "bien différente de github" ?

        Volonté de décentralisation ?

        Est-il possible de pull-requester entre instances de gitorious ?

        • [^] # Re: Pourquoi Github ?

          Posté par  . Évalué à 5.

          Question naïve du vendredi. Que reproche-ton à GitHub ?

          De ne pas être libre tout simplement.

          • [^] # Re: Pourquoi Github ?

            Posté par  . Évalué à 3.

            Oui, ça je comprends bien. Mais la phrase

            la philosophie est bien différente de github.

            semblait sous-entendre autre chose.

            (Même si stricto sensu, libre / pas libre, c'est pas la même philosophie, d'accord.)

            • [^] # Re: Pourquoi Github ?

              Posté par  . Évalué à 1.

              (Même si stricto sensu, libre / pas libre, c'est pas la même philosophie, d'accord.)

              Oui c'est peut-être ce qui est sous entendu. Mais j'avoue que cela gagnerait à être mieux expliqué.

    • [^] # Re: Pourquoi Github ?

      Posté par  . Évalué à 7. Dernière modification le 06 septembre 2013 à 10:28.

      Autre argument : tout n'est pas d'offrir le service git pour attirer du monde, il faut aussi que les contributeurs potentiels connaissent le projet. Or github c'est un peu le facebook du code, il donne de la visibilité dans un certain type de population.

      La différence est que quand un service comme facebook ou google reader ferme, la quasi totalité des utilisateurs ne sait pas comment remplacer le service. Si github ferme, un grand nombre des participants saura migrer l'historique vers un service équivalent voire auto-hébergé. Pour l'instant feedbin a juste besoin que le serveur git marche et que la plateforme recrute de nouveaux contributeurs, et cela github le fait très bien. Quand le projet libre sera suffisamment lancé ils pourront toujours migrer vers une autre solution.

    • [^] # Re: Pourquoi Github ?

      Posté par  . Évalué à 1.

      Gitlab est facile à installer : https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md
      Il suffit juste de faire des copier coller de toutes les étapes, en 30 minutes c'est fonctionnel ;)

      • [^] # Re: Pourquoi Github ?

        Posté par  . Évalué à 2.

        En effet, testé et approuvé (il vaut mieux partir d'une machine vierge cela dit). Par contre, les mises-à-jour - fournies de la même manière - ont un peu tendance à tout casser.

    • [^] # Re: Pourquoi Github ?

      Posté par  . Évalué à 4.

      Tiens petite question, vu que tu as l'air d'avoir trouvé pas mal d'outils distincts. Est-ce que tu as une piste (ou seulement l'envie) pour relier tout ça niveau authentification? Parce que c'est bien joli d'installer douze mille services, mais si c'est pour se retaper son mot de passe à chacun…

      Pour l'instant, je n'ai guère vu que LemonLDAP-ng (en mode reverse-proxy), mais ça me semble légèrement surdimensionné pour une usage quasi-domestique. Tu aurais autre chose?

  • # Newsblur

    Posté par  . Évalué à 1.

    Je préfère NewsBlur, l'affichage étant très cousin avec feu Google Reader.
    Dispo en hébergé (https://www.newsblur.com/) ou sur github (https://github.com/samuelclay/NewsBlur).

    • [^] # Re: Newsblur

      Posté par  (site web personnel) . Évalué à 3.

      Je viens de voir la section "Pricing" de Newsblur. J'ai explosé de rire sur la dernière ligne du tableau comparatif. Et en même temps c'est un vrai argument, auquel je suis sensible. Bien vu.

  • # Encore un truc que tu dois héberger sur un Quad Core

    Posté par  (site web personnel) . Évalué à 10.

    Tain y a vraiment des fois où je me demande si l'hébergement personnel réussira jamais à percer, quand tu vois que les services que tu as typiquement envie d'héberger chez toi nécessitent un PC de competition et 16Go de RAM…

    Genre là pour Feedbin, faut 3 ou 4 processus différents qui tournent (Redis, Sidekiq, nginx, ruby, ….), avec une installation à rallonge, où tu dois définir 28 (j'ai compté) variables d'environnement, qui checkout la moitié des gems ruby dans ton home..

    Feedbin is a simple, fast and nice looking RSS reader.

    Je veux bien qu'il soit nice looking, mais sur un matos d'hébergement personnel typique (Raspi, NAS, ou PogoPlug), ça m'étonnerait qu'il soit fast. Et simple… oui si tu payes les 3$ par mois.
    Quand tu passes plusieurs heures à l'installer, que ça t'oblige à mettre en place un reverse proxy pour garder ton HTTP fonctionnel, que ca prend dans les 500Mo de disque pour les dépendances, pour moi c'est du bloat.

    • [^] # Re: Encore un truc que tu dois héberger sur un Quad Core

      Posté par  . Évalué à 2.

      tu as vu le logo, tu as tout compris :)

      Postgres, RoR, et tout un tas de dépendances… halte à l'indigestion !

      Moi je vais rester avec mon selfoss qui ne nécessite que sqlite, php et lighttpd (ou apache)

      (par contre il y a quelques astuces à savoir pour l'installer, ici c'est pas mal détaillé : http://mobilesociety.typepad.com/mobile_life/2013/06/getting-selfoss-running-on-a-raspberry-pi.html)

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

    • [^] # Re: Encore un truc que tu dois héberger sur un Quad Core

      Posté par  (site web personnel) . Évalué à 2.

      Personnellement, j'utilise feed2imap, c'est ultra-light ;)

    • [^] # Re: Encore un truc que tu dois héberger sur un Quad Core

      Posté par  . Évalué à 3.

      Genre là pour Feedbin, faut 3 ou 4 processus différents qui tournent (Redis, Sidekiq, nginx, ruby, ….)

      +1

      Je fuis déjà depuis plusieurs années tout ce qui est java/j2e et depuis 1 an tout ce qui est rails.

      Je ne conserve que mon redmine qui a un énorme historique que je ne peux migrer. Tout le reste est du pure foutage de gueule simplement pour afficher quelques infos sur une page web. Et beaucoup décrient PHP mais PHP c'est :

      • facile à installer
      • foutrement rapide
      • le langage est à la portée de n'importe quelle personne avec une bonne santée mentale (qui n'utilise pas de framework à la symphony)
      • [^] # Re: Encore un truc que tu dois héberger sur un Quad Core

        Posté par  . Évalué à 2.

        le langage est à la portée de n'importe quelle personne avec une bonne santée mentale (qui n'utilise pas de framework à la symphony)

        Tu peux expliquer? Je ne connais pas trop PHP et pas du tout Symphony mais ça m'intéresse.

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Encore un truc que tu dois héberger sur un Quad Core

          Posté par  (site web personnel) . Évalué à 1.

          Disons qu'avec les nouvelles versions des Framework PHP : Symfony 2 / Zend 2, il faut quand même commencer à avoir un minimum de connaissances en programmation, design patterns, MVC, … avant de pouvoir faire un « Hello World » !

          • [^] # Re: Encore un truc que tu dois héberger sur un Quad Core

            Posté par  . Évalué à 4.

            Tu veux dire que les bases de code spaghetti, sans design, pété de trou de sécu et où seul jean kevin qui l'a écrit peut y comprendre quelque chose vont finir par disparaitre ? Quelle mauvaise nouvelle !

            Presque à chaque fois que j'ai jeté un coup d'oeil dans les sources d'un service php que j'hébergeai pour moi. Je me suis posé pleins de questions existentielles sur la vie.

            • [^] # Re: Encore un truc que tu dois héberger sur un Quad Core

              Posté par  . Évalué à 5.

              les extrêmes sont partout : peut-être que les scripts PHP sont souvent trop "simples" et "mal pensés". Concernant Java ou ruby ou se retrouve parfois avec des morceaux de code qui montrent que le développeur n'est pas sain d'esprit.

              Quand on voit des dizaines et des dizaines de classes avec de l'héritage multiple, des abstract/implement, des design pattern parce que ça fait pro et autres joyeusetés, et, qu'on comprend le résultat, on se dit : "tout ça pour ça ???". J'ai parfois l'impression que certains dev cherchent à tout prix à caser le maximum de couches et le plus de structures particulières à un langage.

    • [^] # Re: Encore un truc que tu dois héberger sur un Quad Core

      Posté par  . Évalué à 8.

      Genre là pour Feedbin, faut 3 ou 4 processus différents qui tournent (Redis, Sidekiq, nginx, ruby, ….), avec une installation à rallonge, où tu dois définir 28 (j'ai compté) variables d'environnement, qui checkout la moitié des gems ruby dans ton home..

      Tu viens de découvrir qu'il existe un fossé entre les objectifs des projets destiné à l'hébergement personnel et les services hébergés.

      Pour l'un on veut des dépendances minimales, une installation simple et un footprint minimal en s'en tamponnant des perfs. Pour l'autre on cherche une architecture robuste pour assurer la résilience du service, qui sera capable d'encaisser la charge et qui dispose de briques évolutive pour répondre rapidement aux différentes évolutions fonctionnelles ou non-fonctionnelles (basiquement tu scales petit à petit tout ses composants qui deviennent des goulots d'étranglement).

      Ces contraintes et objectifs sont très important à comprendre quand on évalue des produits ou des technos ainsi que quand on créer un produit. Et je pense que c'est un problème courant quand on lit les conneries sur telle ou telle technos alors que le mec n'a visiblement pas su cerner le contexte dans lequel elle avait un intêret.

      C'est la tout le problème pour les produits libre destinés aux particuliers et voulant jouer sur les deux tableaux. Il faut souvent une partie cloud/hébergement pour se financer et ainsi pouvoir arriver à un niveau de développement qui permet de faire des produits qui évoluent vites et sont bien polishés (une bonne UI/UX ca coûte une blinde, ca demande pas mal de technique et c'est donc très rare). Mais si tu pars avec ce modèle en tête alors tu as un produit inadapté à l'auto-hébergement du geek qui veut faire tourner ses 300 services dans 32Mo de RAM sur un ARM. On ne peut pas tout avoir et il faut faire des choix.

    • [^] # Re: Encore un truc que tu dois héberger sur un Quad Core

      Posté par  . Évalué à 1. Dernière modification le 07 septembre 2013 à 12:17.

      Feedbin is a simple, fast and nice looking RSS reader.
      Je veux bien qu'il soit nice looking mais sur un matos d'hébergement personnel typique (Raspi, NAS, ou PogoPlug), ça m'étonnerait qu'il soit fast. Et simple…

      Tu le fais exprès où tu n'es pas capable de contextualiser une phrase ? Elle fait bien entendu référence à l'utilisation du service.

      Pour "l'hébergement personnel typique" ca n'a jamais été son but.

  • # cher

    Posté par  . Évalué à 0.

    3$ par mois, c'est beaucoup trop cher pour ce genre d'outil. 5$ par an est le maximum que je pourrais mettre.

    Surtout que le marché est encombré de solution libre, ou en hébergement gratuit.

    • [^] # Re: cher

      Posté par  (site web personnel) . Évalué à 2.

      3$ par mois, c'est beaucoup trop cher pour ce genre d'outil. 5$ par an est le maximum que je pourrais mettre.

      On peut tous fermer boutique, l'avenir appartient aux chinois et aux indiens …

      Donc on va faire le calcul avec l'hypothèse que feedbin soit une boite française (ce qui n'est pas le cas).
      5$ par an donne 3.80€. On enlève la TVA (on va prendre le taux 2014, c'est 20% tout rond), ça donne 3.04€ par an.
      Je compte pas les frais bancaires de transaction, c'est cadeau …

      Les charges d'exploitation, les CFE-TVAE, RSI ou URSSAF, IS et taxes diverses aussi c'est cadeau, on va même tout frauder pour voir si on peut quand même tirer un revenu quelconque.

      Avec 25 centimes d'euro par mois par utilisateur, c'est même pas la peine d'essayer de fournir le service.

      • [^] # Re: cher

        Posté par  . Évalué à 3.

        En même temps si t'as zéro client parce que ton service est trop cher pour ce qu'il apporte…

      • [^] # Re: cher

        Posté par  (site web personnel) . Évalué à 1.

        Avec 25 centimes d'euro par mois par utilisateur, c'est même pas la peine d'essayer de fournir le service.

        D'après toi, Google et Facebook (par exemple) sont à combien par mois par utilisateur?

        On peut tous fermer boutique, l'avenir appartient aux chinois et aux indiens …

        Non, à celui qui sait vendre à un nombre suffisant de personnes. Mais pour ça, faut faire un projet interessant.
        3€ par an? si t'as 10 000 utilisateurs, soit rien, tu peux vivre tranquille sans trop d'efforts (c'est un petit outil à la con!), tu arrive à 50 000 utilisateurs soit a peine plus que rien, tu fais jackpot. Et ce en France.

        • [^] # Re: cher

          Posté par  . Évalué à 4.

          Google, c'est plus difficile à calculer, mais Facebook c'est assez simple, avec un chiffre d'affaire en 2012 de 5.1 milliards $ et un nombre d'utilisateurs revendiqué de 1.15 milliards. Ça fait, 4.43 $ par an et par utilisateur (soit 0.37$ par mois par utilisateur).

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: cher

          Posté par  (site web personnel) . Évalué à 1.

          Super, le commentaire portait sur "ce genre d'outil", et toi tu m'expliques que si on parle de tout à fait autre chose, ben si, c'est possible.
          Ça va t'étonner, mais je suis d'accord avec toi.

          • [^] # Re: cher

            Posté par  (site web personnel) . Évalué à 3. Dernière modification le 09 septembre 2013 à 13:06.

            Xavier t'a fait le calcul, qui démontre que pour un service bien plus complexe et consommateur de ressource, le prix est du style de celui que tu critiques.
            Donc en fait, ça démontre que le prix de ce genre de service, qui ne nécessite pas de grands développements par rapport aux exemples cités, devrait être encore moins cher que ce dont tu te plains.

            Les gens se plaignent souvent du prix élevé des vidéos et audio, mais bizarrement quand c'est plus proche d'eux (comme un truc qu'ils pourraient faire), d'un coup ce n'est pas assez cher…

            Ça va t'étonner, mais je suis d'accord avec toi.

            Tu es d'accord pour dire que le prix demandé est ridiculesement élevé par rapport au petit service fourni? excuse-moi, j'avais lu le contraire.

            • [^] # Re: cher

              Posté par  (site web personnel) . Évalué à 1.

              Facebook et la recherche Google (c'est de là que vient leur CA) sont gratuits pour les utilisateurs, ils ne payent pas ! Les utilisateurs ne payent pas pour un produit, le produit c'est eux. Le commentaire, c'était => Pour ce genre de produit, avec des utilisateurs qui payent, et pas des utilisateurs qu'on vend.

              J'ai pas l'impression que des fonds de pension aient injecté des centaines de millions de dollars dans feedbin pour combler ses dettes le temps d'être rentable comme l'a été Facebook (qui je ne sais même pas si ils est rentable aujourd'hui), on n'est pas dans le même monde. Et regarde le nombre de clone de réseaux sociaux et moteurs de recherche, et tu verras qu'il y a beaucoup plus de casse que de réussite.

              Donc en fait, ça démontre que le prix de ce genre de service, qui ne nécessite pas de grands développements par rapport aux exemples cités

              Le prix de développement, c'est une chose, à ça faut rajouter le coût d'exploitation : les serveurs, les backups, la maintenance, le support (et oui, là les utilisateurs payent). Et tu n'arriveras jamais aux mêmes économies d'échelle que les mastodontes.

              Si un utilisateur veut pas payer 4€/an pour ce genre de produit, avec toutes les emmerdes que ça génèrent, je dis que c'est pas la peine, Il vaut mieux effectivement faire comme tes exemples et vendre tes utilisateurs, c'est un autre business, pas de support, pas de garanties, une qualité de service moindre et moins de tracas.

              Les gens se plaignent souvent du prix élevé des vidéos et audio, mais bizarrement quand c'est plus proche d'eux …, d'un coup ce n'est pas assez cher

              Ça marche aussi dans l'autre sens ! Les gens se plaignent du prix trop élevé de service proche d'eux qui leur rende un service quotidien, en estimant que ça vaut pas le prix d'une capsule nespresso par mois, et pourquoi payer ces gens qui ont développé un service que je pourrais faire, mais que je veux pas faire surtout que ça me couterais plus cher, et ça les dérange pas d'acheter des capsules de café à 30 centimes pièce.

              Mais c'est sûr que si tu estimes que le produit ne te rend aucun service, alors oui, même 12 centimes par an c'est trop cher.

              • [^] # Re: cher

                Posté par  (site web personnel) . Évalué à 3. Dernière modification le 09 septembre 2013 à 14:47.

                Si un utilisateur veut pas payer 4€/an pour ce genre de produit, avec toutes les emmerdes que ça génèrent, je dis que c'est pas la peine,

                Tu disais que tu étais d'accord avec moi… Mais en fait non.
                bon, OK, tu ne veux pas réfléchir à la notion de scalabilité, admettons. D'autres le font (quand ça a un intérêt, évidement)
                4€/an si tu as 50000 utilisateurs et que tes coûts sont de 50000 Euros (par exemple), ça ne vaut pas le coup pour toi, tu dis tout de suite "ça vaut pas la peine" sans réfléchir à un calcul de rentabilité, c'est une façon de faire.

                Mais c'est sûr que si tu estimes que le produit ne te rend aucun service, alors oui, même 12 centimes par an c'est trop cher

                A toi de faire un service qui rend service. C'est sûr que si tu fais un lecteur RSS valorisé à 4€§an/personne mais que tu veux gagner 1 Million d'euro avec 1000 utilisateurs pour pas te faire chier, ça va poser problème.

                avec des utilisateurs qui payent, et pas des utilisateurs qu'on vend.

                Ils payent dans les deux cas. C'est que la forme de paiement, tu ne veux pas parler du fond.
                Tu veux du pas cher? une offre de téléphonie mobile complète pour 24€/an. du pas cher. "Ca vaut pas le coup" pour pas mal de monde. Sauf un. Et sans publicité. La, on parle d'un bête lecteur RSS sans investissements lourds.

                J'ai pas l'impression que des fonds de pension aient injecté des centaines de millions de dollars dans feedbin pour combler ses dettes le temps d'être rentable comme l'a été Facebook (qui je ne sais même pas si ils est rentable aujourd'hui), on n'est pas dans le même monde.

                Ben… C'est peut-être que personne ne trouve utile la chose? Mauvaise offre, c'est tout.


                Bref, si ça a un intérêt, à toi de faire correspondre l'offre à la demande. Le coût (1, 4, 10, 10000 Euros) fait partie de l'offre. Et ça peut marcher si tu répond à un besoin. Donc la, en fait, ça a plutôt l'air qu'il n'y a pas de besoin.
                La, ici, la seule chose que je dis c'est qu'une tonne d'entreprises se sont plantées en essayant de mettre un prix de vente complètement surévalué, et donc personne n'accroche et donc ça meurt, alors qu'une offre plus adaptée aurait plus ses chances (évidement, si tes coûts n'explosent pas, mais ça c'est ton problème).

  • # Hum

    Posté par  . Évalué à 0.

    […] elle [L'extinction de Google Reader] a clairement mis en lumière à la fois les problèmes de dépendance et de maîtrise des données des solutions type cloud / SaaS et fermées […]

    Qu'elle dépendance ? Tu pouvais exporter toutes tes données.

    Cependant, l'histoire semble bégayer et la solution qui a le vent en poupe est actuellement Feedly, qui a effectivement tout pour plaire : application web, interface proche de GReader, principales fonctionnalités gratuites (pour le moment ?), des applications mobiles, une API (Normandy), etc.

    Ça c'est du FUD. Faut pas s'étonner que les logiciels libres subissent du FUD si en retour on fait de même.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Hum

      Posté par  . Évalué à 2.

      La dépendance vient du service lui-même. Tu ne peux justement pas exporter TOUTES tes données, comme les marqueurs lus/non-lus, et si je ne me trompe pas, l'historique (me flageller si nécessaire). Tu peux juste exporter la liste des flux suivis.

      Ensuite, ça a l'air d'être du FUD, mais peu de services propriétaires ont gardés de bonnes fonctionnalités gratuites. Il y a toujours de la pub un jour ou l'autre, ce qui enlève le côté gratuit, puisque c'est l'utilisateur lui-même qui devient le produit.

      Enfin, les services hébergés par des entreprises ne dépendant pas du droit de ton pays (USA ou autre, je vis en France), ça ne me plaît pas. J'ai les compétences pour héberger des services, j'ai envie de pouvoir m'en servir.

      • [^] # Re: Hum

        Posté par  . Évalué à 0.

        La dépendance vient du service lui-même. Tu ne peux justement pas exporter TOUTES tes données, comme les marqueurs lus/non-lus, et si je ne me trompe pas, l'historique (me flageller si nécessaire). Tu peux juste exporter la liste des flux suivis.

        Et ici Feedbin fait mieux ?

        Ensuite, ça a l'air d'être du FUD, mais peu de services propriétaires ont gardés de bonnes fonctionnalités gratuites. Il y a toujours de la pub un jour ou l'autre, ce qui enlève le côté gratuit, puisque c'est l'utilisateur lui-même qui devient le produit.

        Ouai donc à part expliquer que comme ils cherchent à gagner leur vie avec, un jour peut être que tel ou tel fonctionnalité deviendra payante tu n'a pas grand chose sur quoi t'appuyer. Mais je trouve tout de même bizarre que, dans une même dépêche, on vente un service payant et on FUD sur du gratuit (paille/poutre).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Hum

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Qu'elle dépendance ? Tu pouvais exporter toutes tes données.

      « Toutes», le mot est un peu fort je trouve. à part l'OPML et les articles suivis, je n'ai pas vu grand chose d'exporté.
      Et ensuite, je n'avais aucune instance de GReader pour tout réimporter et me retrouver dans un état similaire sur une autre instance. À part réimporter l'OPML dans un autre soft, je n'ai rien pu tirer du reste (ou alors, il faut scripter pour importer au forceps dans un autre outil les autres données…)

      Ça c'est du FUD. Faut pas s'étonner que les logiciels libres subissent du FUD si en retour on fait de même.

      Juste un lien : https://cloud.feedly.com/#pro . La recherche dans tes flux est payante.

      • [^] # Re: Hum

        Posté par  . Évalué à 2.

        Et ensuite, je n'avais aucune instance de GReader pour tout réimporter et me retrouver dans un état similaire sur une autre instance.

        Et c'est différent dans le service dont tu parle qui est payant ? Si tu l'héberge toi même tu peu cloner, mais ça n'a rien de très pratique (tu dump la base et tu la restaure). Impossible de merger des configurations sans rentrer profondément dans les arcanes du logiciel. Pour importer des donner ailleurs il faudrait qu'il existe un format interopérable ? Ça existe ? Si tu t'autohéberge une instance de feedbin et que demain son développement s'arrête peux-tu switcher sur autre chose (sans scripter puisque c'est ce dont tu parle).

        Oui la libération des données c'est important, mais c'est pas mieux pris en charge par les LL que les autres. Les LL se contentent de dire que tu peux faire un backup puis une restauration de la base, mais c'est loin d'être suffisant.

        Bref la problématique existe, mais contrairement à ce qui est dis dans la dépêche, elle n'est pas adressée par feedbin. À coté de ça les services de google et github 2 logiciels propriétaires font parti des services qui exportent le mieux les données loin devant leur concurrents libre.

        Juste un lien : https://cloud.feedly.com/#pro . La recherche dans tes flux est payante.

        Feedbin aussi fourni un service payant. Comme il y a un dépôt où tu peut trouver le code l'un est gentil et l'autre est méchant ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.