• 0 Posts
  • 79 Comments
Joined 10 months ago
cake
Cake day: September 25th, 2023

help-circle
  • pixelscript@lemmy.mltoOpen Source@lemmy.mlKrita FTW
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 months ago

    I mean, you’re free to continue using your crescent wrench as a hammer if you find it drives nails for you decently well and you are comfortable using it that way. But it was neither designed with that purpose in mind, nor does anyone expect you to use it that way, so no one will be writing how-to guides on it.


  • My thoughts exactly when reading this.

    I believe people when they claim to develop free software. Often because it’s software the dev wants for themselves anyway and they’ve merely elected to share it rather than sell it. The only major cost is time to develop, which is “paid” for by the creation of the product itself.

    You (OP) are proposing a service. Services have ongoing fees to run and maintain, and the value they create goes to your users, not you. These are by definition cost centers. You will need a stable source of funding to run this. That does not in any way mix with “free”. Not unless you’re some gajillionaire who pivoted to philanthropy after a life of robber baroning, or you’re relying on a fickle stream of donations and grants.

    You indicate in other comments you will not open the source of your backend because you don’t want it scooped from you and stealing your future revenue. That’s fine, but what revenue? I thought this was free? What’s your business model?

    It sounds like what you want to do here is have a free tier anyone can use, supported by a paid tier that offers extended features. That’s fine, I guess. But if you want to “compete with DuckDuckGo”, you are going to need to generate enough revenue to support the volume of freeloaders that DDG does. If your paid tier base doesn’t cover the bill, you will need to start finding new and exciting ways to passively monetize those non-revenue-generating users. That usually means one or more of taking features away and putting them behind the paywall to drive more subscriptions, increasingly invasive ads on the platform, or data-harvesting dark patterns.

    Essentially what I’m saying here is, as-proposed, the eventual failure and/or enshittification of your service seems inevitable. Which makes it no better than DDG long term.

    It is, at any rate, a very intriguing project.






  • People tend to contribute to the projects they already have the skills for.

    People also tend to pick up new skills when they have a driving incentive to do so, like supporting a project they have a vested interest in seeing improved.

    You need to learn the language’s structures

    Most of the bread and butter ones have analogues in other languages you should readily understand. More language-unique structures are rare; the more niche they are, the lower the odds your ability to contribute in a meaningful way hinges on your understanding of them.

    you need to learn how the compiler works

    You really don’t, though? Modern compilers, particularly the Rust compiler, are designed to abstract away as much of the details of compilation as possible. If the project really does need to tickle the compiler a certain way to get it to build, it will almost certainly have a buildscript and/or a readme.

    you need to learn the libraries that the FOSS project is using

    This is true regardless of the language in use. I’m not sure why you brought it up.

    you need to learn the security pitfalls for the language

    I would imagine most of these language-specific security footguns are either A) so specific that you will never hit the conditions where they apply, B) are so blazingly obvious that code review will illuminate what you did wrong and you can learn how to fix it, or C) so obscure that even the project owner doesn’t understand them, so you’d be at minimum matching the rest of the codebase quality.

    Mind, I am not insinuating that one can simply bang out a whole new submodule of a project in an unfamiliar language with minimal learning time. Large contributions to large projects can be hard to make even when you’re a veteran of the language in use, as the complexity of the project in and of itself can be its own massive barrier. But not every contribution needs to be big. And for most contributions, I don’t believe the language is the most significant barrier to entry. It’s a barrier, sure. But not the biggest one.

    I’d wager it’s not having a significant impact on the volume of contributions to Lemmy in particular.



  • It’s a huge win, but not the kind of win people reading the statistic with no context (like me) probably thought.

    I’m sure a lot of us looked at “15 percent of desktop PCs in India run Linux” and, regardless of whether it was hasty and irresponsible for us to do so, extrapolated that to, “15 percent of Indian PC users are personally selecting Linux and normalizing its paradigms”.

    But in reality, it sounds more like “15 percent of Indian PC users use Linux to launch Google Chrome”. Which is impressive, but not the specific kind of impressive we wanted.

    It feels a bit like how I imagine, say, a song artist feels when they pour their heart and soul into a piece of music, it gets modest to no traction for a while, and then years later a 20 second loop becomes the backing track for a massive Tiktok meme, and almost zero of that attention trickles back to their other work.



  • This is a tremendous amount of cope. Implying there are Lemmy users just lining up to contribute PRs if only it wasn’t written in Rust. Give me a break!

    If someone was competent enough to author code that’s fit to pull into a project like Lemmy, they’re more than capable of translating those skills to Rust. No language seeing modern significant use is so esoteric that a reasonably seasoned developer couldn’t make something competent in it within a week of starting to learn its syntax. Maybe a day, even, if the language you are trying to learn is highly similar to one you already know.



  • I like KeePassXC because it’s written in C and is thus cross platform, while KeePass is written in C# and relies on Windows UI libraries. You can run KeePass on Linux (and I did without usability issue for years) but it will look god awful.

    I won’t knock plugins, everyone has weird use cases, but I don’t know what people need KeePass to do that it doesn’t already do out of the box. I’ve certainly never felt the need for any.



  • You’d certainly think so. But never underestimate a user’s ability to jury-rig a piece of software into doing something it wasn’t designed to do, ignoring any and all obviously better solutions as they do so.

    I don’t think I’ve ever actually seen documentation published on Discord and nowhere else. But I do very often see no documentation whatsoever except a “just ask around on the Discord” link serving the role.

    Discord probably isn’t used as a robust ticketing system either; usually if anything it’s a bot that will push all tickets to an actual GitWhatever issue, which is fine. But again, what I do see often is projects with no ticketing system whatsoever, and a Discord link to just dump your problems at. If the issue tracker on the repo isn’t outright disabled, it’s a ghost town of open issues falling on deaf ears.

    Announcements can be pretty bad. Devs can get into a habit of thinking the only people who care about periodic updates are already in the Discord server, so they don’t update READMEs, wikis, or docs on the repo as often as they should, allowing them to go out of date.

    Fwiw I’ve also seen several projects that have Discord servers with none of these problems, because they handle all those other parts properly.


  • pixelscript@lemmy.mltoOpen Source@lemmy.mlPlease don't use Discord for FOSS projects
    link
    fedilink
    English
    arrow-up
    27
    arrow-down
    1
    ·
    edit-2
    4 months ago

    I don’t mind Discord being a centralized platform for open source project discussion, if and only if the only roles it serves specifically play to its one strength, which is real time discussion. Asking for live support (from the dev if they are there, or the community if they are not) and doing live bug triage are the two big use cases.

    Should contact for these things be real time? Maybe, maybe not. Async discussion like you get on forums or via email can do the job. But if you value real-time chat, Discord does it well.

    Everything else? Do it elsewhere. Do not make Discord your only bug tracker. Do not make it your only wiki. Do not make it your only source of documentation. Do not make it the only place you broadcast updates or announcements. Do not make it your only distribution platform for critical downloads. And for the love of god please do not make it the only way to contact you. I don’t care if you allow Discord to additionally do these things using integrations, that’s fine, just stop trying to contort Discord into your only way of doing these.

    Is Discord the only capable option for real time chat? No. But it has several things going in its favor, namely how one can reasonably expect a good sum of their target user base is already using it independently for other purposes, in addition to its numerous QoL features.

    It can also better integrate into the dev’s personal routine if they already use it independently. Like, do I have an email address? Yeah. Do I read my email on any reasonable interval? Hell no. My email inbox is little more than a dustbin for registration confirmations and online order receipts. I’ve had email for decades and I think I can count the number of non-work, non-business conversations I’ve held over it in that whole span of time on one hand. Meanwhile, I’m terminally online on Discord. So if I’m gonna be a small independent FOSS project developer, am I gonna want to interface with everyone over email? No. I’ll still make it an option, because being only contactable on Discord is cringe, but it will not be fast. Discord will be my preferred channel.

    Should I put more effort into being contactable on other platforms, because it’s the right thing to do? Meh. I have no duty of stewardship to be available on platforms available to anyone in particular. I maintain this hypothetical project for free, on my own time, of my own volition, and I provide it to you entirely warranty-free. I have the courtesy to make all static resources available in sensible public places, and I provide email as a slow, async way to reach me. But if you want to converse with me directly in real time, you can come to me where I’m hanging out.



  • It amazes me how every time a for-profit company that provided a free service goes mask-off and starts aggressively monetizing it so many people put on a shocked Pikachu face.

    This is exactly how this works, people! The free shit is always bait to draw you in and get you invested. The trap was designed from the start to snap shut once there was enough of you in it. They fully intend to not just extract value from you to run the service, but also to retroactively pay for all the free shit they gave you. It was always a loan. An investment.

    Oh, sure, you can always be sly by taking the free shit and ditching once monetization comes over the horizon. But do so knowing that every time you need to do this is the rule, not the exception. Companies aren’t suddenly slighting you one by one out of the blue, it was always the strategy from the beginning for all of them.