... | ... | @@ -66,7 +66,7 @@ In the following the references to interview quotes are the first two letters of |
|
|
|
|
|
### The forge ecosystem
|
|
|
|
|
|
The interviewees use multiple forges for a variety of reasons but they mainly work on their software development project on a single forge. In the past years they came to experience and know about a variety of forges (GitHub, GitLab, Gitea, Phabricator, sourcehut, Heptapod, Redmine, etc.) (ref. AR, CJ, CP, DA, DO, GR, MA, NA, PO, ZA). All of them have (or had in the past) a GitHub account and they acknowledge the monopolistic position it occupies because it hosts the majority of Free Software projects (ref. ZA44) (ref. DA54) (ref. MA67) (ref. DO61) (ref. GR39). Although they are concerned and have reservations about GitHub (ref. NA93) (ref. DA45) (ref. MA64) (ref. CP57), none of them refuse to use it (ref. PO80). The Free Software forges (GitLab CE, Gitea) are considered to be quality software that can easily be installed and maintained (ref. CP19). In the past years, the number of self-hosted forges instances grew substantially (ref. GR93). However the interviewees noticed that only a few are open to the general public (ref. MA4) (ref. CP57) (ref. GR75): most of them have a specific focus (ref. CP57). For instance the [GitLab CE instance of Gnome](https://gitlab.gnome.org/).
|
|
|
The interviewees use multiple forges for a variety of reasons but they mainly work on their software development project on a single forge. In the past years they came to experience and know about a variety of forges (GitHub, GitLab, Gitea, Phabricator, SourceHut, Heptapod, Redmine, etc.) (ref. AR, CJ, CP, DA, DO, GR, MA, NA, PO, ZA). All of them have (or had in the past) a GitHub account and they acknowledge the monopolistic position it occupies because it hosts the majority of Free Software projects (ref. ZA44) (ref. DA54) (ref. MA67) (ref. DO61) (ref. GR39). Although they are concerned and have reservations about GitHub (ref. NA93) (ref. DA45) (ref. MA64) (ref. CP57), none of them refuse to use it (ref. PO80). The Free Software forges (GitLab CE, Gitea) are considered to be quality software that can easily be installed and maintained (ref. CP19). In the past years, the number of self-hosted forges instances grew substantially (ref. GR93). However the interviewees noticed that only a few are open to the general public (ref. MA4) (ref. CP57) (ref. GR75): most of them have a specific focus (ref. CP57). For instance the [GitLab CE instance of Gnome](https://gitlab.gnome.org/).
|
|
|
|
|
|
* **CP19**: "We converge towards the notion of 'I have a software component and it runs'".
|
|
|
* **CP57**: "[...] as any respectable Free Software developer trying to minimize their internal conflicts [...] you cannot be on GitHub nor GitLab.com"
|
... | ... | @@ -97,7 +97,7 @@ Key takeaways: |
|
|
|
|
|
When a software project moves from a forge to another, it is not just about the content of the [DVCS](https://en.wikipedia.org/wiki/Distributed_version_control). Participants share the opinion that the past and present issues should also move with it: they are part of the history that helps future development. The issue tracker is also a place where users who do not contribute to the codebase can actively participate by reporting problems (ref. AR14) (ref. DA30).
|
|
|
|
|
|
When on-boarding new developers, it is useful to browse the discussions from older issues to understand how a particular part of the codebase came to be. This is also true for pull and merge requests, forums and mailing lists. Even the CI artifacts and the description of the CI: a complex pipeline that relies on features specific provided by a given forge (ref. ZA22) (ref. DA35) (ref. AM28) may be difficult to migrate to another forge that does not support them (for instance moving from [travis](https://docs.travis-ci.com/user/tutorial/) to [GitLab CI](https://docs.gitlab.com/ce/ci/yaml/README.html)).
|
|
|
When on-boarding new developers, it is useful to browse the discussions from older issues to understand how a particular part of the codebase came to be. This is also true for pull and merge requests, forums and mailing lists. Even the CI artifacts and the description of the CI: a complex pipeline that relies on features specific provided by a given forge (ref. ZA22) (ref. DA35) (ref. AM28) may be difficult to migrate to another forge that does not support them (for instance moving from [Travis](https://docs.travis-ci.com/user/tutorial/) to [GitLab CI](https://docs.gitlab.com/ce/ci/yaml/README.html)).
|
|
|
|
|
|
The scope of what defines a software is fuzzy (ref. ZA19) (ref. PO42) (ref. CJ44) and should be considered on a case by case basis (ref. PO39). It is a web of dependencies that are not confined to the boundaries of a forge (ref. AR17) (ref. NA16) (ref. DA52). It includes every data, web service that is stored and put to work when the software project moves forward. As an example, a developer mentioned that when they want to modify a software they use on their machine "most of the time it is not installed in a way that allows modifications: the first step is to get the code. If it's a Debian package, I look into he package metadata to find the source code, if it is a Python project, I tend to look on PyPI: I rely on the package manager to locate the source code" (ref. ZA11). Another example is how the software is packaged and distributed as it often involves resources external to the forge (ref. AR20).
|
|
|
|
... | ... | |