From d2ca728a4aabeda91e184e3e929400e2b0e5a26f Mon Sep 17 00:00:00 2001 From: "Joshua M. Boniface" Date: Wed, 7 Dec 2022 16:48:14 -0500 Subject: [PATCH] More wording cleanups --- content/problems-in-floss-3.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/problems-in-floss-3.md b/content/problems-in-floss-3.md index 2073bff..3994f4c 100644 --- a/content/problems-in-floss-3.md +++ b/content/problems-in-floss-3.md @@ -81,9 +81,7 @@ In the Jellyfin project, we have a relatively small number of core "server" deve In this situation, "the commons" is the codebase as a whole. -The tragedy comes because there is a conflicting incentive for the user-developer-turned-new-contributor. Without saying anything about their actual skill level, it is a lot more work for them to (a) get up to speed on the codebase, *and* (b) learn the rules and processes of the project, *and* (c) ensure that their code follows the often-institutionalized-and-undocumented knowledge practices that the current contributors have developed, all on top of the work of actually implementing the feature. - -Thus, there is incentive for the user-developer to implement the feature they want quickly, so they can use it, without too much concern for how it fits into the larger codebase (the "commons" of the project). +The tragedy comes because there is a conflicting incentive for the user-developer-turned-new-contributor. Without saying anything about their actual skill level, it is a lot of work for them to (a) get up to speed on the codebase, *and* (b) learn the rules and processes of the project, *and* (c) ensure that their code follows the often-institutionalized-and-undocumented knowledge practices that the current contributors have developed, all on top of the work of actually implementing the feature. However, there is incentive for the user-developer to implement the feature they want quickly, so they can use it, without too much concern for how it fits into the larger codebase (the "commons" of the project). This can have two effects, both of which are alienating: first, if the project "doesn't care" about "the commons", you can end up with a situation where cleanup work is discarded, the codebase becomes messy as new contributions add code-paths that do not align with the structure, and this alienates those developers doing the cleanup; or, second, if the project *does* "care" about "the commons", this can alienate the new user-developer, who sees the constant requests for rewrites as "nitpicking" their contributions, alienating them and making them at best less likely to see their contribution through, and at worse cause them to fork and implement things their way.