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 just reddit/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.

  • rglullis@communick.newsEnglish
    60·
    1 year ago

    Can you tell me any successful open source project where the lead developers take a “merge everything with little fuss over quality, principle and overall design” approach?

    Maybe PHP? When you think of PHP, do you think “that’s a project I’d like to work on”?

    • jonne@infosec.pub
      14·
      1 year ago

      PHP doesn’t accept any random PR, where did you get this idea? They have a whole proposal process for any substantial change

      • rglullis@communick.newsEnglish
        17·
        1 year ago

        That’s not what I mean.

        I mean that Ramus Lerdorf (creator of PHP) by his own account was never worried about big architectural thinking or consistent design, and it shows. PHP3 is just a pile of functionality thrown together, and it wasn’t until PHP 4 or 5 (depending on who you ask) that things started to get cleaned up.

          • rglullis@communick.newsEnglish
            5·
            1 year ago

            I am asking if you know of any project of lasting value that was successful by giving total freedom to its contributors.

            • jonne@infosec.pub
              0·
              1 year ago

              I don’t think there is any. I agree with your original point, just not with your characterisation of PHP.

              • jarfil@beehaw.org
                1·
                1 year ago

                Modern PHP is like modern Python; they’re not the same as 20 years ago, and they both were a mess.

  • davehtaylor@beehaw.org
    35·
    1 year ago

    • “Why not just …” is always said from a place of ignorance (innocent or willful), and completely dismisses the complexities of the system in question

    • Someone has to have final say. You cannot just accept any PR/MR that comes in. There has to be a design, architectural, and philosophical vision guiding a software project, and contributions need to adhere to those. There have to be review processes, testing processes. And if you don’t like it, and you feel you have the resources to fork it so that your vision is the one in control, then go right ahead.

  • star_nova@beehaw.orgEnglish
    34·
    1 year ago

    A very direct answer to any “Why not just fork X?” question is, would you want to develop and maintain the fork in your free time and for no pay? Forking any project is deeper than just copying a repo and then making a few changes.

    This would involve finding a group of people intimately familiar with the codebase who also don’t mind committing all of their free time to development.

    When you fork a project, you also lose whatever payment/donation structure the original project had setup. Asking for some kind of payment to develop a larger project should not come as a surprise. You want to be able to attract halfway decent developers and they want their work to be valued. Beyond just approving PRs, you need a team to verify additions and work out all the conflicts and errors that arise.

    There very well may be a lot of settings people all agree on. But who is going to bite the bullet and put in all the time to add those features, potentially for the fork to be abandoned?

    I hope this doesn’t sound condescending because it’s not intended to be. I’m just trying to explain that the scope of “Just do this” is a lot larger than what it first seems.

    • jarfil@beehaw.org
      3·
      1 year ago

      would you want to develop and maintain the fork in your free time and for no pay

      I hereby offer myself to maintain a fork for a minimal pay. Any takers?

      • wahming@monyet.ccEnglish
        1·
        1 year ago

        You can get it started as your first step, and see how many were serous about joining in

  • PenguinCoder@beehaw.orgEnglish
    34·
    1 year ago

    The problem with forking Lemmy is in starting from all the bad that is inherently there, and trying to make it better. That is way more work than starting fresh with more developers. IE, not using Rust for a web app and UI, better database queries from the start, better logging/functions from the start; not adding on bandaids.

    A fork of Lemmy will have all of Lemmy’s problems but now you’re responsible for them. No thank you.

    • T0RB1T@beehaw.org
      12·
      1 year ago

      For those of us who have never used Rust, and mostly just heard good things… why is Rust bad for a web app and UI? I’ve heard it’s safer from memory vulnerabilities, and easier to code than most low-level languages, and much faster than high-level languages.

      I chose Lemmy because it’s written in Rust, and kbin is written in PHP.

      • 1stTime4MeInMCU@mander.xyzEnglish
        19·
        1 year ago

        My opinion, hopefully I don’t get downvoted into oblivion lol: Rust is great for lots of things and its to be commended for forward thinking on so many neglected areas of software development from the last 20 years. I use it almost every day for hobby stuff and have used it from time to time professionally (among Java, python, typescript, c++).

        That being said amongst many of its users it has an almost cult like belief in its supremacy and imho attracts some bad people (not all). Because of how much it protects you, many bad developers find it and fall it love with it because it forces them to code correctly and then they can’t imagine that anybody else doesn’t need the guard rails they do. They also see that some of the smartest and best developments in software engineering happen in this space and want to attach themselves to it, and then use it as a bludgeon against others. Lots of very important software was written in languages that are not rust and they work just fine, were able to meet deadlines / be profitable Etc etc. but there is this attitude from many that if you aren’t picking Rust these days what are you even doing???

        Rust is great but it’s sometimes messy and not the right tool for the job. The whole “slower to develop but faster to correct” (which I’d say needs some real data to prove out, but for the sake of argument let’s say is true) is a trade off, not something that automatically makes it better. Sometimes due to circumstances way beyond your own control as a developer, you won’t know what the right answer is until halfway into development and there are languages that accommodate that scenario much better (imo). This is one of many of rust’s short comings. For a website, it’s just an unusual tool that even if equally useful from a language standpoint doesn’t have as much tooling and community support around it as other web languages. But I’d say it’s not equal even from a baseline level (again, my opinion. I’ve used rust plenty but I’ve never used it for web dev so I’m talking out my butt). Philosophically, does it make sense to over engineer a super powerful Ferrari of a website when a Toyota Camry will do? Especially when the Camry is tried and true and will likely let you be more agile.

        You can do anything in any language, but should you?

        • T0RB1T@beehaw.org
          6·
          1 year ago

          That all makes a lot of sense. I really only ever got remotely competent with Python, and the one university course I did in c was rough. I passed it, but felt like I barely understood what I was doing the whole time.

          I can understand how ease of writing and general community mindshare can be the most important factors.

          • 1stTime4MeInMCU@mander.xyzEnglish
            7·
            1 year ago

            That’s too bad, I feel like mastering C is the key to having a super solid foundation for all things how computers work. (Not blaming you, most courses just blast through C without exploring the what and whys). There is something to be said for just getting people productive and for that Python is excellent and immediately engaging. Python is probably my best and favorite language, but I think from a wholistic understanding point of view its hard to beat a solid C foundation to build out from.

            • MasterBuilder@lemmy.one
              2·
              1 year ago

              Lower level languages are definitely helpful in learning how computers work. When I was in college, I was not taught C, but our algorithms course was in C. We were expected to learn it on our own.

              lisp and Prolog were used for AI - those we learned in class. Assembly was the ultimate “get intimate with the machine” language, and we wrote a simple compiler for VMS.

              All of this is meant to help us understand how to work with machines. It doesn’t mean that that’s how we should work with machines. Sometimes the higher level language is the better choice. Sometimes it is not. We are expected to make that decision based on the situation at hand.

      • PenguinCoder@beehaw.orgEnglish
        15·
        1 year ago

        I had a bunch of stuff typed here (probably too much), clicked a damn icon on this UI and POOF when my entire comment…

        These are my opinions, probably not shared with others and surely not the end all be all to ‘why not Rust?’

        Rust is hard. Rust is slow to iterate with and compile. Here’s a highlevel overview of the things you’d need to learn to effectively understand Rust code; not even speaking to learning enough of that to write it. Rust gets touted as secure, and it is more secure than other low level languages like C/C++. That does not make it invulnerable to exploits. It gives a false sense of security to developers who think My app can’t be hacked, it’s written in Rust!!. While Rust is better at memory management and protecting against run time errors related to memory issues, that doesn’t make it 100% safe. That removes almost one class of potential exploits, not all of them, and can’t protect the developer against other developer created issues. Rust code is still written by people. People still write insecure code even in Rust. Computers are dumb as hell; but fast. People are smart as hell, but SLOW. Combine the two and you get stupid things faster; not smarter things better.

        • Rust development is hard, hard to learn, very hard to do right
        • Rust is not suited for a web application. Would you tell someone to go write the web application and web page in C/C++? Nope. There’s a reason for that. Not suited to it. Square peg, round hole
        • There’s always exploits being discovered. Rust handles some things better, but uhhh… Go look at some Lemmy Rust code. Definitely still has vulnerabilities; Rust won’t save you from yourself.

        Something like Golang is much better choice for development of a web service that has sane API handling. By the time to add in more error handling, more type checking, more passing around of this function or that data, and more checking it on the sender and receiver side…etc. By the time you’re writing Rust safely and correctly; it is much slower than what you may be lead to believe.

        Go is primarily designed for speed of development (including compilation times), rather than speed of execution. Go programmers tend to value clear code over fast code. Why does a microsecond longer matter for a website? Maybe in some backend PLC land there’s a damn good use for that performance. For a networked web application; it’s a pointless metric. That is not going to be your bottleneck.

        Rust is hard to understand just reading it let alone determine why it’s doing something.

        Rust

        fn does_what(n: u64) -> bool {
    match n {
        0...1 => false,
        _ => !(2..n).any(|d| n % d == 0),
    }
}

        Golang

        func doesWhat(value int) bool {
    for i := 2; i <= int(math.Floor(float64(value)/2)); i++ {
        if value %i == 0 {
            return false
        }
    }
    return value > 1
}

        Not talking about the functionality merits of the two, but in comparing the _code itself. One of those is much easier to determine what’s going on and what it should be doing versus the other. I don’t feel like fighting my code. Programming is a tool to help. If it takes more work to use the tool to achieve your goal, it’s the wrong tool. Rust is the wrong tool for web development.

          • 1stTime4MeInMCU@mander.xyzEnglish
            8·
            1 year ago

            You can write anything in anything. The downsides have to be outweighed by the positives and OP is suggesting there isn’t enough positive.

          • MasterBuilder@lemmy.one
            6·
            1 year ago

            I suppose the question is whether Rust is worth the extra work. I know nothing of rust. I know C#, JavaScript, and some other web app tools. Is Rust significantly better than those? Are there enough developers interested in Rust to encouage robust participation?

            Can Lemmy handle plugins in a language agnostic way? If so, that might be a better route. Again,I am not advocating anything, just raising questions that can lead to an informed decision.

            • Dark Arc@social.packetloss.ggEnglish
              2·
              1 year ago

              This is the problem I always run into. I’m very skilled with C++ and Python, a little rusty (though I’ve written hundreds of thousands of lines) with Java and Ruby… Rust hasn’t offered me anything to justify the learning curve.

              It also scares me as it’s evolving quickly… perhaps too quickly. It seems like a complicated language that’s just getting more and more complicated.

              I’ve had the same issue with Go (module the ever increasing complexity/rapid evolution). For Rust C++ or Java better suit my experience, for Go it’s Java and Python.

        • jarfil@beehaw.org
          3·
          1 year ago

          Why does a microsecond longer matter for a website?

          Because some more microseconds later, it’s the difference between being able to serve 1k requests per second and dropping connections, vs. 100k requests per second and working smoothly.

          Rust is a great tool for backend development, which is all that Lemmy server is. The frontend Lemmy-UI is written in JavaScript.

          BTW, in your example, I find the Rust version easier to understand 🤷

      • kopper [they/them]@lemmy.blahaj.zoneEnglish
        14·
        1 year ago

        A long-running web thing like Lemmy doesn’t need the processing benefits of native compilation, and can avoid memory vulnerabilities with a garbage collector. Most things it does are IO bound (receive data from other servers, send data to other servers, occasionally render some HTML, interact with a database…) so you’re really not benefiting from anything specific to Rust, but you are losing a significant amount of developer effort into things like working with the borrow checker or the infamously long compilation times that could instead go into implementing functionality.

        You could make something just as performant as Lemmy is today with Python or JS (JS would particularly work well given the prevalance of JITs).

        • Square Singer@feddit.de
          10·
          1 year ago

          but you are losing a significant amount of developer effort into things like working with the borrow checker or the infamously long compilation times that could instead go into implementing functionality.

          And into learning the language. With Rust still being a very rare skill, you are losing out on many good developers who could help out but don’t, because they don’t know Rust. And many of those who do help out, don’t know Rust well and will just stumble trough it and write Rust code as if they were writing their main language.

          It’s kinda like getting people from all over the world to contribute to the welsh Wikipedia. Most will just give up. Many will use a dictionary or Google translate. And only a tiny portion actually know Welsh.

        • PenguinCoder@beehaw.orgEnglish
          8·
          1 year ago

          Most things it does are IO bound […] so you’re really not benefiting from anything specific to Rust,

          Preach.

        • Neshura@bookwormstory.socialEnglish
          3·
          1 year ago

          I agree that Rust is definitely not ideal for server backends (imo it’s not bad, just fine but then again I use it a lot for private projects) but I disagree with your take on JS/Python. Sure that would work but given the performance issues on large instances already going for either of these two, even with JITs, is a bit of a hot take imo. Go probably would have been a way better choice given its relatively low entry bar.

          • kopper [they/them]@lemmy.blahaj.zoneEnglish
            3·
            1 year ago

            AFAIK the issues l.w et al are struggling with are to do with the database. The language you’re calling out to Postgres doesn’t really matter when it’s Postgres that’s taking a lifetime computing through your hell-query.

            I don’t know much about Go (I should really take a closer look at it) but it’s definitely also a valid candidate. (Perhaps a bit too bare bones for my personal liking, but hey you can’t win em all)

      • bedrooms@kbin.social
        10·
        1 year ago

        The benefits of Rust turned out to be irrelevant for Lemmy. Then the downside kicks in. To give you some context, sone people Rust is more difficult than C++, which was indeed one of the most difficult (if not the most).

      • 🦊 OneRedFox 🦊@beehaw.orgEnglish
        7·
        1 year ago

        Unless you have a Google-tier workload, it’s probably not worth the effort to deal with the learning curve and manual memory management of Rust. Not to mention that the language isn’t particularly common among web devs, so finding developers for it will be annoying compared to something else. Logic errors will be a more relevant issue with a web app (things like not setting your JSON Web Tokens to expire) and Rust won’t save you from that.

        Rust is great if you’re building something like a browser engine where there’s big performance requirements, a huge attack surface, and you’d benefit from explicitly marking where memory errors can occur (also compiler-managed concurrency/parallelism).

        • kopper [they/them]@lemmy.blahaj.zoneEnglish
          1·
          1 year ago

          Logic errors will be a more relevant issue with a web app (things like not setting your JSON Web Tokens to expire) and Rust won’t save you from that.

          I’m sure there is some arcane feature of Rust that’d let you encode that in the type checker somehow. Yeah it’d be completely unreadable and unmaintainable but knowing the Rust community there’s probably someone mad enough to take a crack at it.

          • 🦊 OneRedFox 🦊@beehaw.orgEnglish
            2·
            1 year ago

            Well, there are some things you can do if you’re familiar with functional programming, Domain Driven Design, and Railway Oriented Programming where you can use the type system and structural pattern matching to make your life easier when it comes to designing program logic, but it still requires competence and there’s easier languages than Rust that also have the necessary features.

    • kopper [they/them]@lemmy.blahaj.zoneEnglish
      8·
      1 year ago

      I’d been eyeing azorius.net lately considering it’s much smaller/younger than Lemmy and already federates (and might make an interesting foundation to build something out of before it grows too large, hint hint to anyone who actually knows Go) but I don’t have the Go experience to actually go through its code.

      I’ve been experimenting with ActivityPub on my own time and I am kinda starting to understand why all AP projects end up being large messes. It’s spaghetti code all the way across the fedi.

  • Rentlar@beehaw.org
    33·
    1 year ago

    I mean, go ahead, fork it, I can’t stop you from doing that.

    The reason why people still use the main fork is that at least someone is there fulltime making sure lemmy works. Now all the issues that were in Lemmy are now the responsibility of you and the people you convinced to develop for your fork to fix. On top of that, problems caused by the fixes you made also have to be fixed.

    • potterman28wxcv@beehaw.org
      2·
      1 year ago

      I would also add that maintaining a fork means either missing out on the new features from the fork or have a lot of trouble rebasing every now and then (the more the fork is different from upstream, the higher the cost of rebasing)

      • jarfil@beehaw.org
        3·
        1 year ago

        That highly depends on how tightly coupled is the code. Rebasing can be mostly automatic with properly modular code, or a total nightmare if each feature is intertwined with all the others.

  • MasterBuilder@lemmy.one
    27·
    1 year ago

    I don’t know the backstory to this. My view in General on open source projects is that the people who initiate those projects and manage those projects generally have final say. If enough people disagree a fork will naturally occur.

    However I’m a little uncomfortable with the idea of claiming that they should not curate and control how their own project is managed. I’m here labor of love should not be forcefully taken from them. They have reasons for their decisions and it is their baby.

    If you believe that a large number of users want the features that you want, then by all means Fork it. We will find out over time if you are right. And that is how it works. There should be no animosity.

    • Neshura@bookwormstory.socialEnglish
      6·
      1 year ago

      The problem here is, imo, that the curation is in a lot of cases based on the devs personal usage of lemmy. Meaning if Nutomic or Dessalines don’t think they need a feature you’re already facing an uphill battle to just get them to understand that even if they don’t want it, other people do. Best example I can think of is how lengthy the debate about post tags was until they relented and switched from “won’t implement” to “if somebody else does the work” (I’m still skeptical they won’t block any actual work there with nitpicks about implementation details) see this GitHub Issue for what I mean. It really takes away a great amount of motivation if you have to convince the devs about what you plan to implement. Instead of “Gauge Community need for feature” -> “Write Proposal” -> “Implement” it now is “Gauge Community need for feature” -> “Argue with GitHub Mods for a few months” -> “Write Proposal” -> “Implement”

  • kopper [they/them]@lemmy.blahaj.zoneEnglish
    22·
    1 year ago

    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)

    • Anony Moose@lemmy.caEnglish
      3·
      1 year ago

      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.

  • A10@kerala.party@kerala.party
    19·
    1 year ago

    BTW the PR to open links on new tabs was finally merged today last month #1546

    Lemmy devs are at least open to discussion and have changed their initial stance on many changes based on community feedback (Unlike mastodon)

    • BrikoX@lemmy.zipEnglish
      13·
      1 year ago

      I mean they were never against it in this case. They asked to make a specific change and instead of doing that the author just closed the PR and then proceded to say how it will never get merged…

  • alyaza [they/she]@beehaw.orgM
    17·
    1 year ago

    Instead of contributing to a project where only dessalines, lionirdeadman and nutomic dictate what gets approved, why not make a fork with the settings most people agree on?

    rest assured: our admin here has basically no say over the project’s priorities, and we’ve also been fighting tooth and nail like the person you’re quoting to get anything productive done (including priorities we think are vital to the project’s long term success like better mod tools). cc: @Lionir@beehaw.org and @Penguincoder@beehaw.org for more details on that.

    • Neshura@bookwormstory.socialEnglish
      3·
      1 year ago

      Can chime in as well on that. I sorta get where they’re coming from not wanting to merge tech debt but I feel like their going a but too far at times. Especially when it comes to the “I don’t want this” type of ‘reasosn’ for denying PR’s or closing Issues. I had a very lengthy debate with Nutomic about CW’s and Spoiler tags to even get them to understand why that is needed.

      When a great deal of time is spent making a github mod come around to just let you put in the work you know is wanted by a lot of people it really takes the wind out of your sails. I think that sort of personal bias will be more of a long term detriment to lemmy than any problem with the tech stack it uses.

  • d3Xt3r@beehaw.org
    16·
    1 year ago

    If people really felt strongly about this, we would’ve seen it being done already. Perhaps the state of Lemmy right now is “good enough” so folks don’t care too strongly about a lack of a minor feature, or maybe they find it easier to just migrate to something like Kbin instead and still be federated to Lemmy. Or maybe they prefer to just write a simple patch, which can be maintained and distributed separately, instead of forking the entire code. Afterall, it’s easy enough to make a fork, but a PITA to maintain one. Much more easier to just make a separate patch set or standalone utilities or something.

    Also, frontend features, like the infinite scrolling one which was quoted, are basically non-issues, considering so many good alternative frontends exist, such as Photon, Alexandrite, mlymm, LemmyBB etc. There’s no rule you have to use the default frontend. In fact many Lemmy instances have decided to host these frontends on their own servers, and if they wanted to, they could easily switch to it and make it the default landing page.

    • Die4Ever@programming.dev
      12·
      1 year ago

      so many good alternative frontends exist

      don’t forget the mobile apps are frontends too, which shows how flexible we can be while keeping the backend intact

    • Neshura@bookwormstory.socialEnglish
      2·
      1 year ago

      I think a large reason for why there are no forks (yet) is that so far we’re still in the “let’s try to make this work without a fork” part. Widespread interest in Lemmy is only pretty recent but there are already a lot of bad experiences when it comes to contributing to the project. If the two lead devs keep being as inflexible as they have been so far when it comes to popular requests I think a fork is sort of inevitable.

  • targetx@programming.dev
    12·
    1 year ago

    Well you could, it’s just the usual pros and cons. How will you get momentum and community around the fork and how will you get a sufficient amount of instances to switch to a fork to have any impact. Not sure we’re at that point yet.

    Edit; checked the PR you referenced and it’s just a stylistic issue apparently. While a bit pedantic imho, I think a fork reaction to this is overblown. It was merged later in another PR; https://github.com/LemmyNet/lemmy-ui/pull/2032

    • Neshura@bookwormstory.socialEnglish
      2·
      1 year ago

      Forking over the mentioned PR is definitely overblown but there is an issue with nutomic and dessalines blocking wanted features due to personal reasons. Mild example but stuff like

      Also, its not difficult to right click -> open in new tab, or middle mouse click.

      is not a rarity from my personal experience, horrible implementation details aside I had to waste a great amount of time to get nutomic to understand that people do indeed want Spoiler Tags. My idea for how that would work was ultimately idiotic but my experience up to that point made me really not want to interact with them. Instead of talking about issues with the implementation you have to first spend weeks arguing that the feature is actually a good idea in the first place despite multiple open issues with people asking for that particular feature. I’m currently working on a new proposal for post tags that should work a lot better but I really don’t look forward to having nutomic or dessalines review the proposal. Bit of a rant but the two lead devs on this project being what I can only describe as extremely stubborn is not helping this entire endeavor one bit and probably has chased away a lot of potential contributors, I know that once I’m done with post tags I probably won’t contribute again.

      • trashhalo@beehaw.org
        3·
        1 year ago

        Fwiw I’ve had small interactions with dessalines on issue reports and didn’t get great vibes and have stopped filing frontend issues. Nothing huge just didn’t get the sense I was welcome here.

        Sharing so you know it’s not just you.

  • brie@beehaw.org
    11·
    1 year ago

    As far as I can tell, the main problem with such a fork is that it must be maintained. A fork wont survive if nobody has the time, interest, and skill to keep it working, especially since with Lemmy there is compatibility with other instances to be considered.

    However, even without a fork of Lemmy itself, there are things that can be independently developed. Since Lemmy has an API, people can and have implemented features such as infinite scrolling in their own clients or forks of the official UI.

  • bedrooms@kbin.social
    8·
    1 year ago

    My thought process was that since lemmy is open source, we should be free to add new features without having to battle over philosophies

    Off-topic, but reminds me how Mao-ists and Lenin-ists were dictators in disguise of people with principles.