Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@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.
-
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.
-
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. -
@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.
-
@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". -
@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 -
@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. -
@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.
Related Rants
That's a good one!
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?
rant
opensource
github