Ernest, the lead dev for Kbin, has had a lot of big events happen in his life recently, so he has a tendency to just kinda disappear for weeks/months at a time while the project gets put on hold. He'll usually come back, announce new plans for development, maybe push out a few updates, and then inevitably go radio silent again.

I believe he's got a few people assisting him now, but development has definitely slowed to the point of becoming concerning. I think it might be time for the Mbin team to start getting a little more free with the fork.

[–] [email protected] 15 points 4 months ago (1 children)

I think it might be time for the Mbin team to start getting a little more free with the fork.

eh? what do you mean?

[–] [email protected] 30 points 4 months ago (2 children)

I believe that currently, Mbin isn't making any drastic changes, and relying mostly on Kbin's existing code as its base. As far as I'm aware, the Mbin team are mostly just doing maintenance-level development; fixing things as they break and making optimizations, but not so much in the way of developing new features. Mbin is currently just basically a copy of Kbin, without much distinguishing the two.

Since Kbin doesn't seem to be moving much at all, I think it might be a good idea for Mbin to start flexing their own muscles a bit, and making it into its own separate project. Otherwise, having a copy of a stale project just leaves you with two stale projects.

[–] [email protected] 23 points 4 months ago* (last edited 4 months ago) (2 children)

Mbin isn't making any drastic changes

UI wise, that one is definitely true

and relying mostly on Kbin's existing code as its base

This one most certainly not. We actually stopped porting kbin code a few months into the project, because it just was too much work and it was obvious that Ernest didn't want us to. So everything which changed on mbin in the about 8-10 months since, was purely our own work. Of course the basis will always be kbin, but the form will most likely change

We've been keeping the UI mostly as is, because we all like it, however on the backend site of it a lot has changed. The biggest problems kbin had were compatibility wise (federation) and scaling wise. These were the points where we made huge changes. The federation compatibility has improved a lot (yes there is still a lot to do) and scaling/performance has also improved a ton.

The biggest UI changes we made are:

new filter designs that work for threads as well as microblogs
a subscription panel
a usable instance wide modlog
a cake day display
and more stuff that I am forgetting at the moment (it's been a while since I looked at kbin and I am mostly a backend dev)

The backend changes we improved are (imo) more impactful:

(next release) direct messages are federating
(next release) pins federate
deleting users federate
magazine descriptions are federating correctly
mods federate
reports federate
incoming likes are working
the "hot" sort actually makes sense with lemmy content because it also looks at upvotes and not just at boosts
completely redone the hashtag system so it scales at all
completely redone the background worker system so it scales better (partly next release)

And these are only the changes I could think of in 5 minutes. We likely changed a lot more things, which I just forgot.

[–] [email protected] 4 points 4 months ago (1 children)

Holy shit, that's awesome! Thanks for sharing!

[–] [email protected] 4 points 4 months ago

Yes indeed, we made a lot of changes under the hood!

[–] [email protected] 4 points 4 months ago

Thanks for the insights!

[–] [email protected] 19 points 4 months ago (1 children)

youre not wrong, they spent a lot of time refactoring things, and still are.

that said, the list of changes in the last several versions is very long, and the code base is no longer trivially similar. looking through the waiting prs, there are a lot of interesting bits like extending microblog AP connectivity (tag handling).

the mbin guys have been pumping out releases steadily since the fork, including implementing managed documentation and version numbering. it has well exceeded kbin at this stage.

theyre prepping for a 1.7 release soon. when was the last kbin update? to me, theres only one stale project here.

[–] [email protected] 8 points 4 months ago

Thanks for the insight! I'm not super familiar with how the development cycle goes, so my thoughts are coming from the standpoint of a user experiencing both platforms. I'm sure that a lot of the back-end stuff has probably had a lot of improvements, but the end-user experience between Kbin and Mbin are still largely identical, I feel.

I was gonna load up Kbin to try to do a live comparison but, uh... Yeah, who knows when that'll be possible again lol

[–] [email protected] 4 points 4 months ago* (last edited 4 months ago) (1 children)

So it basically failed the bus factor

Hopefully mbin becomes more resilient, or if Lemmy just gets some nice rewrites.

[–] [email protected] 3 points 3 months ago* (last edited 3 months ago)

I'm using both Mbin and Piefed and I'm loving both! It's absolutely not looking bleak. :)

[–] RedSquadCampFollower 2 points 4 months ago (2 children)

it might be time for the Mbin team to start getting a little more free with the fork.

the impression i had of mbin was very "anything goes" did that not end up being how things shaped up??

[–] [email protected] 11 points 4 months ago

its a community. anyone can generate a pr, code it up and it gets discussed. so far there has been no crazy drama about what to include or not.. no one has proffered any incompatible ideas. its been quite pleasant

its all public though, in the matrix or github channels

[–] [email protected] 6 points 4 months ago (1 children)

That was the message that was pushed out when @[email protected] started the fork, because a lot of people were not particularly fond of the way he did it. We were trash talked a lot in the first months and obviously (and sadly) that kinda stuck on a lot of people.

[–] [email protected] 5 points 4 months ago (1 children)

I did the fork in the best way I could think of. Including a very detailed Collective Code Construction Contract for contributors: https://github.com/MbinOrg/mbin/blob/main/C4.md

[–] PlasticExistence 3 points 4 months ago (1 children)

I'll never fully understand why humans are so quick to judge and offer non-constructive criticism on someone else's creative work. It seems like the least knowledge are most often the loudest in this regard.

[–] [email protected] 4 points 3 months ago (1 children)

Communication is difficult, especially over text, and emotions can get strong as there is a lot of work involved. Software developers are not always the greatest diplomats. Well-intended constructive feedback is often read as criticism, and situations escalate. And for whatever reason people love picking sides.

At least Mbin seems like a healthy project now, and since Kbin.social went down for good it's hard to argue a fork wasn't needed. Hopefully Ernest is alive and recovering well - he did us all a huge service by creating Kbin and making it open source.

[–] PlasticExistence 2 points 3 months ago

Agreed. Diplomacy is not a skill that many people practice, and even when they do misunderstandings happen over text too easily.