joshuaboniface
/
blog
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Fix odd wording

This commit is contained in:
Joshua Boniface 2022-12-07 16:46:35 -05:00
parent 9d3592ffd2
commit 35edb2a7e4
1 changed files with 1 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/problems-in-floss-3.md
View File

@ -71,9 +71,7 @@ We have seen this happen with Jellyfin in near real-time. Earlier on in the proj
The Tragedy of the Commons has a slightly more tenuous connection to FLOSS projects, but I think it is still relevant here, though causing a slightly different result than the Bystander Effect.
This issue is more on the side of users who are also developers. Each individual user-developer has their own ideas about what the project should do. This is especially pronounced in very large, sprawling projects with many features, like Jellyfin. For each feature the developer may want, they have an incentive to implement it. But the size and complexity of the project - both in terms of code and of userbase - makes it difficult to justify the work. Because the user-developer is not a part of the tight-knit community, there is no particular social pressure on them to follow the road-map of the project.
Thus, you can get into a situation where a user-developer *does* move past the Bystander Effect and start working on a feature or bugfix. They might even finish it. The tragedy of the commons comes into play when said feature is shared with the project at large.
This issue is more on the side of users who are also developers. Each individual user-developer has their own ideas about what the project should do. This is especially pronounced in very large, sprawling projects with many features, like Jellyfin. For each feature the developer may want, they have an incentive to implement it. And the user-developer *does* move past the Bystander Effect and start working on a feature or bugfix. They might even finish it. The tragedy of the commons comes into play when said feature is shared with the project at large.
Depending on the "cost" of the feature, in many terms - developer effort, review effort, migration paths, etc. - the project as a whole might not be interested in the feature. Either in general, or in specific implementation. This results in a major discouragement to the user-developer-turned-new-contributor, as their pull request languishes in the purgatory of "waiting on review", with no one being willing to dismiss it nor to actively accept it.