In the past months development of Kbin slowly came to a halt, development was bottlenecked by a single maintainer. I have tried several times to start a discussion about the way of working and trying to address the problems and to come up with a plan to keep development doing and more importantly keep contributors happy!
Despite all of this; no response on Matrix and nothing has really changed at Kbin. I saw the project slowly dying over the past months, and I couldn’t let this happen. That’s why I decided to fork the project called Mbin. I wanted to avoid a fork initially, but I didn’t saw any way out.
Mbin is community-focused fork, build upon trust and embracing the Collective Code Construction Contract (C4).
Despite the fact I’m the creator of Mbin, I am NOT the only maintainer, several contributors already have owner rights on the GitHub organization as well as on the Matrix Space and Weblate. We are all maintainers, we peer-review each other’s code and are allowed to merge pull requests from other external contributors and our own. The community of Mbin will now decide what will be picked-up and resolved, what will be merged or not. The community is in charge. And I am “just” another contributor, following the C4 rules.
Mbin development has been accelerated tremendously over just one week time. With tons of improvements in GUI, backend, security and documentation. We have great internal discussions and a friendly community. We work as a team, sharing knowledge and helping each other out. We review and test our code changes together, we all feel responsible. I think all this is the real reason why I created the fork; it’s about the people and about empowerment.
Various instances already migrated towards Mbin, see: https://fedidb.org/software/mbin. Mbin is backwards compatible with kbin, so migration should be straight forward and easy.
Success story: Jerry almost gave up fedia.io, if it weren’t for Mbin, we would already have lost a big federated instance (I genuinely didn’t know he was about to give up). Luckily the fork gave him hope. And hopefully I gave everybody hope again.
I see what you mean, I guess. I wasn’t aware of any previous trauma or drama. Developers not always getting along is common with open source projects - and it’s the cause of many decisions to fork. Look at Linus, for instance… he’s super happy to tell anyone to fuck off on the mailing list, but he has obviously very successful projects.
I have not been following kbin development, but while it’s a great project it does seem to me that Ernest has way more than enough to do.
Ernest is just kbin.social. melroy here has been claiming “core kbin developer” status for all of kbin, that he’s part of the “kbin.social” team but excluded(so join his instance kbin.melroy instead)and now he’s heading the mbin fork because no one in either team “listens to him or includes him in meetings/group chats”. Melroy constantly fudges his worth and credentials. He’s somehow simultaneously “core/vital” and “ignore/excluded”. Which is it? Sounds like he’s only “core” in his own mind. Every time he has a problem with his teams, he posts publically in various communities to complain to regular users about how unfair he’s treated.
Melroy is a drama queen.