1. 9

  2. 2

    Why would it matter? In open source software, if you care enough about something, you can just make it happen. If there is a mismatch between what you need and what you have, either you do as every person does and craft a workaround, or you shop for a better solution, or you fix it yourself.

    There is no sense in even acknowledging the gap between what a volunteer written program does and what professionals need it to do. If professionals actually needed a change, they have full ability to volunteer as well.

    1. 3

      If the original author or maintainer has become inactive, then it can be difficult getting your changes merged upstream so others may benefit. I have a few stale PRs left hanging on Github for this reason. Most developers have an aversion to forking a project. It does happen (see htop), but it is rare.

      It is possible to maintain a set of patches on top of upstream code, like the packages some distributions provide (e.g. BSD Ports and Debian-like security backports), but this does not scale as well as merging upstream would.

      Is i understand the abstract, this is a method to identify which project could use some more love. Initiatives like hacktoberfest and the generous work of redhat and debian does could be better focused by employing such a technique. These may also be some sexy numbers to show to your boss if you want to argue for time dedicated to opensource work. “It’s not philanthropy, it’s risk mitigation”

      1. 2

        There are many non-professional users, who don’t have ability to volunteer. At the end of the day, open source is for users, it is all for naught if it doesn’t benefit users. Since you are a professional, you are absolutely right if you focus on your own use (selfish motivation) of open source. Underproduction means many users rely on the software but not many developers work on the software. It is relevant if you want to know where the help is most needed to improve user’s use (altruistic motivation) of open source.