In recent weeks, people unhappy with Mastodon project talked about forking the project in a different direction. It's harder than it looks.
A lot of people have talked about the possibility of forking Mastodon to get the many improvements their communities need. Making such an effort successful is another discussion entirely.
As an engineer who’s worked on very large codebases over two decades, I’ve realized that this is so much easier said then done.
If people want to fork Mastodon, great. But they’ll quickly realize that what they may think are straight-forward “improvements” will lead to them having to address bigger architectural issues.
Many design decisions that were made when building Mastodon may not be perfect, but they address a lot of very complex decentralization and federation issues.
There’s no such thing as perfect software. What some may think is an improvement, others will think is a terrible choice. Each decision is a trade-off and will have downsides. We just have to decide which of them we’re comfortable with living with.
This was a huge learning in my journey. Realising that every technical decision is a matter of tradeoffs - that there is no perfect pattern/framework/library/implementation/architecture/whatever.
Once the obviously bad choices have been eliminated.
Yeah, aside from developer muscle, an effort like this requires deep knowledge of the existing system. Or, failing that, a commitment to learning it.
It’s also not something that can be done as a side project, if it hopes to compete with the main project to the point of replacing it. Something like that requires an ungodly amount of effort and dedication. Someone would have to commit years of their life to solely working on that.
As an engineer who’s worked on very large codebases over two decades, I’ve realized that this is so much easier said then done.
If people want to fork Mastodon, great. But they’ll quickly realize that what they may think are straight-forward “improvements” will lead to them having to address bigger architectural issues.
Many design decisions that were made when building Mastodon may not be perfect, but they address a lot of very complex decentralization and federation issues.
There’s no such thing as perfect software. What some may think is an improvement, others will think is a terrible choice. Each decision is a trade-off and will have downsides. We just have to decide which of them we’re comfortable with living with.
This was a huge learning in my journey. Realising that every technical decision is a matter of tradeoffs - that there is no perfect pattern/framework/library/implementation/architecture/whatever.
Once the obviously bad choices have been eliminated.
Thank you for these insights!
Yeah, aside from developer muscle, an effort like this requires deep knowledge of the existing system. Or, failing that, a commitment to learning it.
It’s also not something that can be done as a side project, if it hopes to compete with the main project to the point of replacing it. Something like that requires an ungodly amount of effort and dedication. Someone would have to commit years of their life to solely working on that.