4
Nmeri17
2y

I wonder how many github issues have been closed by asking the author to implement the feature they've requested for. In the past, I was confident my issue will be resolved by opening a new one when there's no answer in earlier questions. I can't tell whether the nature of my questions advanced or whether it's a new trend. But I've opened maybe 4/5 issues in recent memory, and each time, the collaborators suggest the feature is one I should contribute to their project by implementing. Isn't this their job as maintainers? I'm already working on something that barely gives me breathing space. I encountered a challenge using your library, and your idea of helping is that I dissent from my own trajectory, acquaint with your project /how to implement what I want, wait for it to get merged etc, before continue what I originally intended. Do they think that's worth it?

Is it just me or is this a common occurrence, lately?

Comments
  • 4
    is it the job of a "maintainer" to "implement new features" or is their job to "maintain" the current features.

    I think the hint is in the name
  • 0
    I’ve run into the same problem on various occasions. If it’s a simple fix, I’ll open a MR. If they drag their feet to get it merged, I’ll use patch-package to fix it locally for my team
    (talking about js dependencies here…)
  • 0
    @Hazarth features on the project are stable, hence, it gets released. That's how it garners users. What are you maintaining then if you're not attending to requests for new features? Adding new ones you feel are more important than the ones your users requested? Refactoring? Can't possibly do that all year round and shouldn't be prioritized over new requests
  • 3
    @Nmeri17 Well, you maintain nothing if there's nothing to maintain, you work on other projects or if it's an open source project you do whatever you want. When you sign up to maintain a project you don't necessarily sign up to satisfy the users every whim, in fact the nice thing about open source is that if you want a feature, you can contribute it yourself, otherwise you have no other choice than to wait for someone to "feel like" doing it.
  • 6
    Unless it's a commercial project, it's no one's job to add new features, and the maintainers also have their own "job" which puts bread on the table. The existing feature set of the package is probably enough for their purposes, so implementing your precious feature is actually closer to your job than to theirs.
  • 4
    There is a sense of entitlement in a lot of the issues being created on open source projects.

    People spend either their free time working on a public library or they are, at best, paid by some stakeholder to maintain the project in a certain direction which need not align with yours.

    If you want, you may ask for the feature. Yet at no point are you entitled for them to implement it for you.

    I also understand it's not always feasible to implement it yourself, or sometimes some projects shoot feedback down in a way that feels unwelcome.

    Yet there is a level of abuse here that a lot common programmers just seem oblivious of.

    If you really need it: Code it yourself, pay them to code it for you, pay somebody else to code it for you.
  • 6
    @Nmeri17 The project, as maintained, already solves a certain problem and vision. While it might seem that "if it can do x it should also do y", it also means adding another layer of complexity making the entire thing harder to maintain. Ever heard of "feature creep"? It's sometimes hard enough to keep a project grounded in a certain way as it is. A lot of libraries are very focused to actually keep their scope to a minimum and outright say what they will never do. You might not agree with their stance, your use case might be very valid, still it's their prerogative on how to progress with their project and it's your prerogative to fork them and push the project in a different direction.
  • -1
    Have I mentioned that I'm still alive and healthy ? Haha
  • 2
    You sound like someone who lacks empathy.

    If YOU need it, then it is YOU that will code it, and share with everyone else so that they can benefit from your work. Open source is about collaboration, it is not about getting free stuff. That is just a byproduct of altruism.
  • 0
    @hardCoding I don't lack empathy, pal. I've built tons of open source components. That's just your perspective. My own perspective is calling for assistance, it has nothing to do with entitlement. The open source world should be all about division of labour. Instead of reinventing wheels or rolling out everything on my own, I intend to leverage existing tools already moving toward that target destination. When the supposed maintainers push me back, it defeats the aim of division of labour. At that moment, their library isn't useful to me and there's no promise to meet me at the point of need in future
  • 2
    @Nmeri17 You may call for assistance. The called upon may flatly refuse you. Why is this such a hard concept for you? They also are not required to promise you a feature that you need. The sooner you really understand that, the less frustrated you'll be in the future.

    What you call "division of labor" I would call coercing people to work, free of charge, in a direction you want under the open source umbrella.

    Also, if you don't want to be perceived unempathic and entitled, start by not calling other people that provide you with feedback as "pal".
  • 0
    @Nmeri17 if that lib isn't meeting what you need, find another one. Ideally you should fork repo, fix it/add feature and make PR. If you don't want to do that, why should someone who doesn't give jack5h1t about the functionality you need?

    In one of the companies I worked before we often forked and extended libs to our own needs, sometimes did PR, sometime just used own forked and extended repo.

    don't be one of those entitled devs everyone hates working with
  • 0
    @Nanos well for one.. stay tuned
  • 0
    Embarrassing. I guess we can call it a day. Question answered: everyone who experiences this bites the bullet, whether they're solo devs or backed by a fleet of rockstars. I'm in the minority of unpleasant, ungrateful and entitled curmudgeons. Can we move on now?
  • 1
    @Nmeri17 well kinda yes, I've been there more than enough times when I was junior dev, so I decided to take sh1t in my hands rather than waiting for Godot.

    Sometimes it is hard to accept reality.
  • 2
    @Nmeri17 Your picture of open source is very idealistic. If the entire world worked on the same principle - free access to resources according to need, and a mutual promise to strive to be useful to each other - this idea would be feasible. But the reality is that the library you're using is at best someone's side gig or a module extracted from a commercial project, most likely a module extracted from a specific abandoned hobby project, which means that it has neither its own scope nor its own resource pool.

    Open source, excluding the hottest 100 projects, is about the safety of being able to do it yourself if the maintainer won't. This applies to features, maintenance and auditing alike.
  • 0
    @Nanos i am sorry I am saying just what a bot is saying
    I'll try to do better
Add Comment