Mbin: a federated content aggregator, voting, discussion and microblogging platform (By the community, for the community) - GitHub - MbinOrg/mbin: Mbin: a federated content aggregator, voting, disc...
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.
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.)
@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"
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.
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.
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.
@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.
@ReedLindwurm The Fork was created as there's a few things that the community of Kbin don't enjoy as well as the creator of Kbin has had some personal issues as of late and has publicly said they won't be able to work on the project for a bit. Also Kbin has had a lot of errors and slowdown as of late what Mbin has and is working on fixing regularly what is really nice.
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.
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!
@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.
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.
@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.
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.
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.
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).