I’ve read this comment on lemmy’s github repository by sbordeyne:
I closed it cause I have no interest in having to battle dessalines on minor nitpicks. Feel free to take the branch and reopen the pull request.
My thought process was that since lemmy is open source, we should be free to add new features without having to battle over philosophies, which was made apparent to me with his reviews and very strong opinions over which features to greenlight and which features to debate at length over (see infinite scrolling, and this very issue which was only approved on the condition we make it a setting that is off by default). I just don’t have the energy to contribute and be challenged on every little thing, I’ll just remain a plain user of the platform and not bother contributing to the project anymore.
Originally posted by sbordeyne in #282 (comment)
Instead of contributing to a project where only @dessalines@lemmy.ml, lionirdeadman and @nutomic@lemmy.ml dictate what gets approved, why not make a fork with the settings most people agree on?
My stance is that I wouldn’t contribute to a project hosted on GitHub, or a project that considers a few opinions more important than the majority.
Controversial takes
dessalines doesn't want SEO so we get URLs for robots
It might makes sense for the semantic web, but IMO it really doesn’t add that much value… look at how silly this type of thinking has gotten w/ reddit: https://www.reddit.com/r/aww/comments/glenz4/cute_baby_bunnies_think_the_golden_retriever_is/
Its gotten to
reddit/community/comments/post_id/weird_lengthened_post_name, when it should be justreddit/post/postid_Originally posted by @dessalines@lemmy.ml in https://github.com/LemmyNet/lemmy/issues/875#issuecomment-652165036_
:::
In my opinion, open-source projects should follow a set of principles to ensure transparency, community engagement, and effective development. Here are some key points that encapsulate these principles:
-
Clear Decision-Making Process for Future Releases: Open-source projects should have a well-defined process for deciding what features and improvements make it into each release. This process should be documented and accessible to the community. (For example, you can read about how Discourse decides what goes into each release here).
-
Complaint-Driven Development: Embrace the concept of “complaint-driven development,” where user feedback and complaints guide the prioritization of issues and features to address.
-
Transparent Donation Management: Be open about how donation money is allocated. Implementing a bounty system can further enhance transparency, enabling contributors to work on specific tasks for financial rewards.
-
Inclusive Community Involvement: Encourage active participation from the community in brainstorming and voting on potential features before finalizing the project roadmap. Community input can be invaluable in shaping the project’s direction.
-
Public Roadmap: Maintain a publicly accessible roadmap that outlines what is planned for upcoming releases. This roadmap should include the status of each feature or enhancement to keep users informed.
-
User-Friendly Feature Request Process: Provide a public feature request forum where users can submit their ideas. Clearly outline the process for how these requests will be reviewed and prioritized, ensuring transparency in the decision-making.
-
Effective Communication Channels: Avoid using disorganized or private communication platforms for project-related discussions. Instead, opt for well-structured, publicly accessible channels that don’t require users to log in to access information.
-
Document with a Blog: Utilize a blog or similar documentation platform to keep users and contributors informed about important project updates, changes, and developments.
Because now you have to maintain that fork. If it was as simple as pressing the little fork button on GitHub and importing a few PRs in than there’d already be several forks right now.
The Lemmy codebase is a beast that’s evolved over several years. Not everybody can just jump in and throw anything they want just because of how complex a system it is internally. (I learned that the hard way.)
Across the fediverse all the major successful forks have a motivating factor. Glitch social is maintained by the only other paid developer hired to work on Mastodon and acts as an unstable branch / “feature fast track” of sorts, Akkoma exists because upstream Pleroma has sided with the freeze-peach crowd too many times to count. Firefish and Iceshrimp had a whole… thing… (too much drama to explain) (oh and upstream Misskey is way too Japanese for western developers to contribute, including commit messages and code comments) What’s the motivation to start a Lemmy fork? And what’s the motivation to keep maintaining it?
I really want to see a Lemmy fork. Particularly one that attempts to prioritize instances as their own individual communities (rather than the Redditesque “instances as free horizontal scaling” view of the fedi a lot of people seem to have). Hell I might end up attempting to contribute a quality of life feature or two of my own if a viable fork were to exist. Yet there isn’t any.
So, I guess what I’m trying to say is, the only reason no fork exists is because nobody has stepped up to the challenge.
EDIT: And of course with ActivityPub in the mix you also have to consider how it will affect federation with other instances, and building consensus among other projects (not necessarily just Lemmy) regarding any extensions you might decide to add to the protocol (though you’d have much easier time implementing extensions from other projects if they solve your issue)
Completely agree with everything you’ve written, and will also add that any fork will need to either constantly keep up with and stay compatible with the upstream Lemmy repo, or if the fork decides to make breaking changes, it will need to port over security and other QoL changes that upstream gets.