• pitninja@lemmy.pit.ninja
    link
    fedilink
    English
    arrow-up
    22
    ·
    1 year ago

    It’s kind of interesting to watch in open source which projects survive and which get forked and essentially made irrelevant. It basically becomes a referendum on the vision of the original individual or team and how well they’re serving the collective user base. If they aren’t accepting PR’s and competently managing development, they’ll likely be forked. So I’m glad to see that folks are making progress with mbin and I can’t help thinking that its entire existence is probably due to individuals not being able to agree on a roadmap for the platform. If anybody has any info on any drama that led to this, I’d be curious to read about it.

    • vintprox@kbin.melroy.org
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Hello! I had the same question and I’ve got a perspective from one fellow contiributor: Matrix thread. (There’ll probably be an error when you first open it: join the room with your account and try my link once more.)

    • 🔸Daniele Turra🔸@hachyderm.io
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      1 year ago

      @stu @yogthos Can anybody point to research or literature about the development and survival of FOSS communities? I am only aware of Gabriella Coleman’s studies on Debian and Raymond’s “The Cathedral and the Bazaar”

  • Ashyr@sh.itjust.works
    link
    fedilink
    arrow-up
    13
    ·
    1 year ago

    I’m very excited for mbin. I hope it continues to gain traction. I’d love to see it get support with Artemis, the iOS app.

    • debounced@kbin.run
      link
      fedilink
      arrow-up
      10
      ·
      1 year ago

      Mbin’s API is 100% compatible with kbin as of today, so @hariette should have little to no issues pointing Artemis at Mbin instances.

  • wahming@monyet.cc
    link
    fedilink
    English
    arrow-up
    13
    ·
    1 year ago

    Ootl, what was wrong with kbin that led to the fork? I thought Ernest had quite a bit of support from the community

    • ISometimesAdmin@the.coolest.zone
      link
      fedilink
      arrow-up
      12
      ·
      1 year ago

      Ernest has some big life stuff going on right now (you can check out his posts if you really need to know), and hasn’t been able to review/merge in PRs for kbin lately. Furthermore, kbin.social doesn’t even have the latest changes that are merged in, so the community fork mbin was made by @melroy, one of the most prolific contributors to kbin.

      • pitninja@lemmy.pit.ninja
        link
        fedilink
        English
        arrow-up
        7
        ·
        1 year ago

        Thank you for providing some context for this. It kind of sounds like a fork might not have been necessary if Ernest was willing to make @melroy a maintainer. Do you know if there’s any philosophical reason he wasn’t willing to do that? Real life stuff comes and goes, but it seems silly to halt the “official” project that others are relying on and still wanting to improve upon and thereby force a fork. As it stands right now, it sounds like it will be awkward for Ernest to come back in and try to restart work on kbin and will be increasingly awkward the more that mbin progresses, becomes the standard, and the code bases diverge.

        • melroy@kbin.melroy.org
          link
          fedilink
          arrow-up
          16
          ·
          edit-2
          1 year ago

          Despite being maintainer of Kbin (incl. several others), we wasn’t allowed to merge other PR changes except my own or changes that Ernest didn’t like (eg. GUI pull requests were reverted again). Then when development slowly became to a halt, I didn’t want the project to die. I didn’t saw any other solution than to fork the project. Not only that, we also didn’t like some changes from the past, which Mbin also rolled-back (like only show local magazines in the random sectors in the sidebar).

          The fork by the community for the community also allows us to do multiple things from the start: 1. No single maintainer anymore. 2. Introducing a C4 contract: https://rfc.zeromq.org/spec/44/ 3. More transparency and giving all contributors owner rights on all platforms incl but not limited by GitHub, Weblate and Matrix. Allowing multiple people to become fully responsible for the project. Having discussions about contents, when we as a community agree on changes PRs can be merged after 1 owner approval. Various instances now moved to Mbin (like https://fedia.io/ ), because they saw hope again. As stated earlier, we also moved to GitHub now and to the hosted weblate.org instance. Currently the development is booming, because it’s not getting reversed and slowed down.

          We had ~150 PRs in a only 2 weeks time (Kbin has this number over a year not a week or two). The amount of improvements in the code, bug fixes, GUI, docker setup, documentation and security fixes as well as various features are impressive. Mbin is not about me, it’s about the community now.

          See also: https://kbin.melroy.org/m/updates/t/55330/Mbin-is-born-Fork-of-kbin

          • Odo@lemm.ee
            link
            fedilink
            arrow-up
            5
            ·
            1 year ago

            Wondering why a move from Codeberg (non-profit, free software, self-hostable) to Github (propietary software, Microsoft)? Seems like Codeberg would be more aligned to the project’s values.

            • melroy@kbin.melroy.org
              link
              fedilink
              arrow-up
              3
              ·
              edit-2
              1 year ago

              I agree but the reason was simple. Codeberg.org had too many down time issues. I and the community was impacted by the codeberg issues on almost a weekly basis. Hence the reason to move. I could also go to gitlab, but to keep reusing the Forgejo runners, github has the same workflow syntax. Anyhow, it’s also not up to me anymore. If the community decides to move to another git server I’m also fine with that. But I doubt the community wants to move back to codeberg.

              • vintprox@kbin.melroy.org
                link
                fedilink
                arrow-up
                2
                ·
                1 year ago

                In retrospective, it’s a practical decision to move away from downtimes, especially seeing as development is so rapid now.

                We might do a mirror to Codeberg to avoid a complete dependency on GitHub, while accepting PRs on the side. Priorities tell us to postpone this idea in favor of long-awaited changes and fixes, though! 😉

            • ISometimesAdmin@the.coolest.zone
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              Speaking for myself, I greatly appreciate the fact that it was moved to Github because 99% of all open source projects I’ve ever wanted to contribute to in the past have all been on Github. Kbin (and alexapy, on gitlab) have been the only exceptions.

              And that’s not even mentioning my work also uses Github for our internal repos.

              Speaking purely selfishly, it’s simply more convenient to be able to manage and track my time and contributions all in a single place, and I can’t imagine I’m alone. I’m looking forward to seeing Codeberg’s long-term goals of federation see fruit, but for right now it was simply an obnoxious extra hurdle.

    • Ashyr@sh.itjust.works
      link
      fedilink
      arrow-up
      6
      ·
      1 year ago

      I only know a bit of the story. I don’t think Ernest has done anything wrong, per se, but I don’t think he was prepared for the Reddit migration. He put in a ton of time and work and seems to have gotten burned out. It’s still missing some pretty basic features.

      For instance, I know kbin doesn’t have api support, so apps like Artemis are unable to plug in and use it effectively. It sounds like mbin is already further along on that front.

      I think the original vision of kbin sounds really cool. It’s basically a tighter integration with Mastadon while maintaining a more reddit-like feel and foundation.

      I’ll be curious to see where it goes in the future and wish all the developers well. For now, it looks like mbin is the path forward.

      • SamXavia@kbin.run
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        @Ashyr Yes most of this is correct, from what Ernest has mentioned he has taken a step back due to personal issues in his life, he’s an amazing developer and glad he made Kbin. The Mbin developers are further alone and have already created an API as well as fixed a lot of bugs, glad to be on board and hope Ernest is feeling better soon.

    • debounced@kbin.run
      link
      fedilink
      arrow-up
      9
      ·
      1 year ago

      we’re making it super easy for any existing kbin instance to migrate to Mbin, just a matter of pointing git at the new repo, pull, and update as usual.

      • SamXavia@kbin.run
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        @debounced eventually I’ll work out how to create my own instance but amazing to know that it is simple to migrate if I had a Kbin instance.

      • vintprox@kbin.melroy.org
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        A fun story: I was curating my magazine on Melroy’s instance and didn’t butt heads with any regression when he switched from Kbin to Mbin. Nice to see priorities set straight on migration!

  • SamXavia@kbin.run
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    @yogthos I’ve been really enjoying Mbin myself, have submitted a post about PeerTube not being supported and people have been talking about it and I love that they didn’t just shut the idea down straight away. Glad to be here and slowly moving everything I can across.

    • melroy@kbin.melroy.org
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      Personally I like to have “video” support in Mbin as well, just like we have photo/image support. We already discovered that PeerTube is using “groups” as channels, which are called “magazines” in Mbin. We might want to create a clear distinguish between “normal communities/magazines” and “peertube channels”. Anyhow, feel free to help us.

      • SamXavia@kbin.run
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        @melroy It’s good you’ve worked out the channels are groups / magazines. Sadly I’m not a coder myself so can’t really help on that part, my main goal is spread the word of the Fediverse as a user as well as try and see areas where we can improve as I feel as a user it’s good to see what we might ‘need’ on these amazing platforms like Mbin.

      • vintprox@kbin.melroy.org
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        It’s a fun idea to explore, which is why I didn’t nod it off. 😄 Imagine: PeerTube channel as a magazine (under the hood, it’s a link between video posts made by actor/boosted by ActivityPub group and magazine entries). Not only we’d have a way to preview several videos on a singular page, but also see description and likes. There is certainly a room for improvement in this model, just leaving it here before I forget.

  • spaduf@slrpnk.net
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Does anybody know if there are significant differences in moderation or the federation of moderation actions? One of the few things keeping me from switching to kbin.

    • melroy@kbin.melroy.org
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      We’re busy fixing the cascading problems in PostgreSQL design, allowing the removal of magazines, something that is still not available for some reason. After that, the mbin community will most likely further improve the moderation system. Regarding federating, we do already support all ActivityPub types (incl Services, which are bot accounts).