Do Open Source Projects Ignore You? DistroTube
video description
Date: 2022-03-30
Related videos
Comments and reviews: 10
danihp
Hey DT I agree with your discourse, but I think that the truth is always in the middle in this cases.
If all devs make their personal fork of something, then no one of these software could really become mature and usable by many people in future.
In the open source community many times happen that a developer, an administrator or a big contributor of a determinated software act like a queen disrespecting suggestion or the work of other people cause they think that they are the only ones that detain the truth.
I just want to take as example an episode happened to myself sometime ago, I was working with an open source tool and in noticed that this tool missed an integration with another software that could have expanded a lot the utilization of the tool, so I ask the developer if in his roadmap he thinked to insert that integration, and the dev just ignore me (at the time i see the dev write on the other issue and simply skip and ignore my one), so I decided to develop this integration by myself making a fork.
In short after almost a year, I received an email where the dev of the tool was requesting me a PR about my integration done in my fork, this because another user more popular than me have requested the same integration that I firstly asked almost a year ago and where i simply get ignored.
Moral of the story, in IT and open source world there are a lot of very talented and skilled people, and very frequently some of this people are stopping by their presumptions and arrogance. I think that the right mix in an open source project is yes fixing a precise set of problems, but keep the ears open (in the right measure) about what the community suggest, I think this is a killer feature for every successful project
reply
Hey DT I agree with your discourse, but I think that the truth is always in the middle in this cases.
If all devs make their personal fork of something, then no one of these software could really become mature and usable by many people in future.
In the open source community many times happen that a developer, an administrator or a big contributor of a determinated software act like a queen disrespecting suggestion or the work of other people cause they think that they are the only ones that detain the truth.
I just want to take as example an episode happened to myself sometime ago, I was working with an open source tool and in noticed that this tool missed an integration with another software that could have expanded a lot the utilization of the tool, so I ask the developer if in his roadmap he thinked to insert that integration, and the dev just ignore me (at the time i see the dev write on the other issue and simply skip and ignore my one), so I decided to develop this integration by myself making a fork.
In short after almost a year, I received an email where the dev of the tool was requesting me a PR about my integration done in my fork, this because another user more popular than me have requested the same integration that I firstly asked almost a year ago and where i simply get ignored.
Moral of the story, in IT and open source world there are a lot of very talented and skilled people, and very frequently some of this people are stopping by their presumptions and arrogance. I think that the right mix in an open source project is yes fixing a precise set of problems, but keep the ears open (in the right measure) about what the community suggest, I think this is a killer feature for every successful project
reply
Mind
Time is a limited resource and maintainers are not working full time in the project and are often not earning any money from it, good thing open source gives everyone the ability to make pull requests to fix bugs ; )
Also making pull requests to add features that differ too much from the original design is a problem, new features add complexity to the project and will have to be maintained for the years to come, so its important that the creators of the project are interested in the features you want to add.
I find it very selfish for programmers to ask someone to code for free when they could also be helping with the project, it's of course fine to open issues and report bugs and propose new features, but becoming upset because something you asked is not being done is very childish.
reply
Time is a limited resource and maintainers are not working full time in the project and are often not earning any money from it, good thing open source gives everyone the ability to make pull requests to fix bugs ; )
Also making pull requests to add features that differ too much from the original design is a problem, new features add complexity to the project and will have to be maintained for the years to come, so its important that the creators of the project are interested in the features you want to add.
I find it very selfish for programmers to ask someone to code for free when they could also be helping with the project, it's of course fine to open issues and report bugs and propose new features, but becoming upset because something you asked is not being done is very childish.
reply
nox
I've seen certain large social media projects discussing issues and talking points, with the majority of the community seemingly wanting one thing, and then a top contributor would step in and completely close down the conversation because it goes against what they want for the project. I've found that smaller projects are a lot more receptive to feedback and discussion. If I find the former to be the case, I'll fork the code and develop my own branch instead, just without those particular changes and merge in the later changes into my fork.
The most receptive project I've found so far is Obsidian(not open source though). Nearly all the changes I've requested have been added into the client.
reply
I've seen certain large social media projects discussing issues and talking points, with the majority of the community seemingly wanting one thing, and then a top contributor would step in and completely close down the conversation because it goes against what they want for the project. I've found that smaller projects are a lot more receptive to feedback and discussion. If I find the former to be the case, I'll fork the code and develop my own branch instead, just without those particular changes and merge in the later changes into my fork.
The most receptive project I've found so far is Obsidian(not open source though). Nearly all the changes I've requested have been added into the client.
reply
Jimi
Some of the open source maintainers do the job for themselves, they may need the software for their own purposes and that-s why they maintain them. Maintaining free software isn-t always a paid job either. For example I have been developing a custom content management system and I was planning to release it as open source, so my work could benefit as many people as possible. I still need the software to do what I want, so therefore I may be one of the assholes who-s not listening to feedback, because I rather write code than debug problems I-m not facing. It probably is selfish, but even free software doesn-t mean people are going to work for others for free
reply
Some of the open source maintainers do the job for themselves, they may need the software for their own purposes and that-s why they maintain them. Maintaining free software isn-t always a paid job either. For example I have been developing a custom content management system and I was planning to release it as open source, so my work could benefit as many people as possible. I still need the software to do what I want, so therefore I may be one of the assholes who-s not listening to feedback, because I rather write code than debug problems I-m not facing. It probably is selfish, but even free software doesn-t mean people are going to work for others for free
reply
hogstudio
I don't think that you captured the reality of how open source works. There are cases, like neovim, where a project is forked to take another direction but that is the minority, 99% (totally made up number) of the forks are to implement a feature to then try to merge it back. In my experience, the maintainers have always been very helpful, explaining their views and thoughts on the propositions, and if an issue is not accounted is not because the maintainer is an a...hole, it is usually a matter of having limited human resources to tackle it. Don't forget that devs are humans too.
reply
I don't think that you captured the reality of how open source works. There are cases, like neovim, where a project is forked to take another direction but that is the minority, 99% (totally made up number) of the forks are to implement a feature to then try to merge it back. In my experience, the maintainers have always been very helpful, explaining their views and thoughts on the propositions, and if an issue is not accounted is not because the maintainer is an a...hole, it is usually a matter of having limited human resources to tackle it. Don't forget that devs are humans too.
reply
Linux
I don't bother the developer's. Most the time, I find something better. But as soon I find one almost the way I want it. And if there is anything that could be better for me. As in changing something or adding something. Then I just do it myself. I really don't consider myself a developer. But I do know enough to be dangerous. I dab in some much programing languages. I do consider myself a Jack of all trades, but master at none of them. There are a few things I really do know, but it's just a handful. I mean it's open source, meaning you can do your own maintenance on that project.
reply
I don't bother the developer's. Most the time, I find something better. But as soon I find one almost the way I want it. And if there is anything that could be better for me. As in changing something or adding something. Then I just do it myself. I really don't consider myself a developer. But I do know enough to be dangerous. I dab in some much programing languages. I do consider myself a Jack of all trades, but master at none of them. There are a few things I really do know, but it's just a handful. I mean it's open source, meaning you can do your own maintenance on that project.
reply
Brodie
I've found that small projects tend to be very receptive to any feedback I bring up in a video, obviously there are times when these are more to do with user preference where I can understand why a project wouldn't do something but when I bring up actual flaws in the design I've noticed that most devs are very willing to change what they're doing. The problem with large projects is that so many different people are telling you so many different things, that they need to filter out what's actually important.
reply
I've found that small projects tend to be very receptive to any feedback I bring up in a video, obviously there are times when these are more to do with user preference where I can understand why a project wouldn't do something but when I bring up actual flaws in the design I've noticed that most devs are very willing to change what they're doing. The problem with large projects is that so many different people are telling you so many different things, that they need to filter out what's actually important.
reply
The
I had listened yesterday. After rediscovering Arch after 8 years I have to say I can see why people love it. The alacritty terminal is awesome. If I were to have a Linux distro it would be called icecreamOS with different versions a basic vanilla configuration of Arch, Debian, Ubuntu, BSD and whatever else so people can install what they want without having to do any extras but it's a good way to learn when you have to configure everything. Just my two cents.
reply
I had listened yesterday. After rediscovering Arch after 8 years I have to say I can see why people love it. The alacritty terminal is awesome. If I were to have a Linux distro it would be called icecreamOS with different versions a basic vanilla configuration of Arch, Debian, Ubuntu, BSD and whatever else so people can install what they want without having to do any extras but it's a good way to learn when you have to configure everything. Just my two cents.
reply
Terminalforlife
I think they do. I've made comments which have led to friendly, constructive communication with distribution developers. I've had authors of software comment in reply to issues I've had. I'm sure you have this much more. Then there's GitHub (and similar, I assume) where people, not too surprisingly, seem more welcome to criticism.
I think 'they' listen, but at the end of the day, it's their project.
reply
I think they do. I've made comments which have led to friendly, constructive communication with distribution developers. I've had authors of software comment in reply to issues I've had. I'm sure you have this much more. Then there's GitHub (and similar, I assume) where people, not too surprisingly, seem more welcome to criticism.
I think 'they' listen, but at the end of the day, it's their project.
reply
Sam
Forks are good though. More options is better. By the source code being open and easily forkable, we create the breeding ground for the evolution of software. A form of natural selection will cause the best code to rise to the top in the long run. So more forks and more code and choice is always good.
reply
Forks are good though. More options is better. By the source code being open and easily forkable, we create the breeding ground for the evolution of software. A form of natural selection will cause the best code to rise to the top in the long run. So more forks and more code and choice is always good.
reply
Add a review, comment
Other channel videos
