OSS | B101nfo

Packaging R: getting in repositories

Sun, 05 May 2024 00:00:00 +0000

After the previous post collecting information about repositories I want to collect here my thoughts on adding a package in a repository and how repositories are recognized. As in the previous post this is built on the assumption that one already has a package or more and wants to distribute it.

This is meant as a reflection of what is an R repository and not intended for R package developers. However, their feedback is appreciated to consider how an ideal repository would be.

Package submission

An R repository will have a way to incorporate a package. CRAN submission process starts with a form, while Bioconductor is done through a Github issue.

The process will usually then start with an automated process. Until the automated process check hasn’t passed probably no one will look into the package submission. This reduce the hours a human must dedicate to manage submissions. If a man is kept in the loop one could appeal the automatic process contacting them, or if it is a random failing re-submitting the package again.

Package submission checks: first a check of the package, if it is not new a dependency check from the repository if all checks pass the package is added to the repository.

Generally a package must first pass a package quality check before it is considered for further integration test. This integration test is usually checking the new version of a package with packages that depend on it, also known as reverse dependencies.

Package maintenance

Once a package is included in a repository it usually needs to be maintained.

There are many moving pieces, chips architecture, OS, R, other packages. This all lead that authors need to maintain the packages in good shape if they want it to remain useful to users. Of course, if one doesn’t want to do that they do not need to create a repository to share their package.

Graphic showing time and different R versions and checks. Repositories check the packages on them on multiple levels.

This leads that at any given time point there must be some tests for any given package under different conditions as shown in image 2. This leads to the possibility of having a package archived from the repository for failing the checks in place.

Repositories provide these checks as a service to the users. They guarantee that R packages in the repository work well together and pass the same set of packages (mostly). This is what leads to their reputation and usage among users (this is true beyond R, DEBIAN, Ubuntu, …).

Closing remarks

There are several official repositories how the package submission works when a package is submitted to one but it is related, via dependencies to other repositories is a matter of another post.

There are some discussion on what is an R repository. The importance of CRAN and Bioconductor has lead to some confusion. There are generally two meanings of what a cran-like repository is:

One where install.packages() works (This is defined by how the files and binaries are organized and will be a theme for another time).
One were all the checks described here are in place and install.packages() works too.

r-universe is using the first definition but could be used to generate repositories with checks that comply with the second definition. Other repositories that use that are the Posit Public Package Manager, or the R4Pi repository (which provides binaries for Raspberry Pi OS).

As the second definition is more strict I’ll focus on it as this post has explained.

PS: This post might be edited as it has been siting in my computer for several months. I prefer to post it and be improved with feedback, so let me know if you have any addition.

Packaging R: repositories

Sat, 09 Dec 2023 00:00:00 +0000

In this post I want to collect some thoughts about R repositories. In R we have multiple repositories that store packages for users. In this post I want to write about the purpose, functionality, benefits and drawbacks of R repositories and how packages are managed. The goal is to summarize what I’ve learnt these last years about them. I’ll also collect some information about them from various sources to make it easier for myself to find it later on.

I am writing this because I am worried about the future of CRAN and R. Due to multiple circumstances, the current position is not sustainable as is. I hope that this post, will help me to understand the past, present and create some concrete steps to do.

History

I was not there, but the first repository started around April 1997. This repository is CRAN: the Comprehensive R Archive Network. The first mention I found is already about changes in it, but it was not until the end of the month when it was announced.

CRAN was created by a few volunteers, some of which are still mainting it 25 years later. The current team is listed on their website. From the beginning it was “a collection of sites which carry identical material, consisting of the R&R R distribution(s), the contributed extensions, documentation for R, and binaries.”

Omegahat was another repository created shortly after CRAN:

The Omega project began in July, 1998, with discussions among designers responsible for three current statistical languages (S, R, and Lisp-Stat), with the idea of working together on new directions with special emphasis on web-based software, Java, the Java virtual machine, and distributed computing.

Many developers of Omegahat were in the R Core or CRAN team. It was available as a repository from the R source code but was removed definitely in version R 4.1, in 2021¹.

Bioconductor, was the next major repository that appeared. It was funded by Robert Gentleman and others in 2004 (it started the mailing list). A paper describing it appeared in late 2004:

an initiative for the collaborative creation of extensible software for computational biology and bioinformatics.

Through its history repositories have evolved with R and R with them. For example: R was released twice a year at the beginning, and Bioconductor did too. But when R moved to be released once per year (in 2013 with version 3.0) Bioconductor kept using two releases a year. This introduced some problems when installing packages from Bioconductor, when a single R release can be compatible with two Bioconductor releases².

In other cases, checks have evolved. For instance Solaris was used to test packages in CRAN until 2021, if I recall correctly, because it allowed to test in a proprietary C or C++ compiler. This lead to discover bugs but also to more distress in R-package developers which had difficulties checking their packages in that environment.

Other checks evolve with R, becoming more strict with time: In the early versions of R the use of NAMESPACE was not regulated. But since R version 2.15, 2012 it was compulsory even for data-only packages³. This was synchronized with repositories checks.

Last, some goals/desires of CRAN are not fulfilled (or where abandoned). For example, from the start CRAN aimed to have packages authenticated (see the bottom of the announcement). This might be due to lack of time, resources or that the plans are in progress but require (volunteer) time.

With time, different repositories arose:

MRAN, which was available since September 17th, 2014 to July 1st, 2022.
The Rstudio Public Package Manager later renamed Posit Public Package Manager has binaries for several OS since 2019.
There is the R4pi repository with binaries for Raspberry Pi.
I remember a proteomics repository available.
rOpenSci started its own repository which later evolved into the r-universe. The r-universe currently can provide binaries of packages that are hosted in a git repository.

Literature

The role and prominence of the repositories has lead to many articles being written about it. I wanted to link and collect some of them for easier retrieval.

I was wondering how CRAN is described by the volunteers that built it. From the announcing email:

CRAN is a collection of sites which carry identical material, consisting of the R&R R distribution(s), the contributed extensions, documentation for R, and binaries.

From the website (at 2023/12/09):

CRAN is a network of ftp and web servers around the world that store identical, up-to-date, versions of code and documentation for R.

Initially there was R NEWS, with an article dedicated to CRAN and one to Omegahat too. These articles usually describe new package additions but sometimes they also provide information about changes:

CRAN-2001-1: It list new packages, CRAN-2001-2, CRAN-2001-3, Omegahat-2001-3
CRAN-2002-1, CRAN-2002-2, CRAN-2002-3
CRAN-2003-1, CRAN-2003-2, CRAN-2003-3
CRAN-2004-1, CRAN-2004-2
CRAN-2005-1, CRAN-2005-2

Since 2006 there is also an article about Bioconductor.
CRAN-2006-2, Bioc-2006-2
CRAN-2007-1, CRAN-2007-2, Bioc-2007-2, CRAN-2007-3
CRAN-2008-1, Bioc-2008-1 CRAN-2008-2, Bioc-2008-2

Later it became the R Journal:

CRAN-2009-1, CRAN-2009-2
CRAN-2010-1, CRAN-2010-2
CRAN-2011-1, CRAN and Bioconductor 2011-2. In the bioconductor section it mentions conference, and important directions for the Bioconductor core.
CRAN-2012-1, CRAN and Bioconductor 2012-2: Mentions biocLite() to install packages.
CRAN-2013-1 Bioc-2013-1: mentions better integration of parallel evaluation.
CRAN-2013-2, Bioc-2013-2: Mentions again AnnotationHub
CRAN-2014-1, Bioc-2014-1: Mentions the git-svn bridge to synchronize git and svn repository.
CRAN-2014-2, Bioc-2014-2: Bioconductor 3.0 release, besides some packages Amazon Machine Image are offered as well as docker images. Packages are required to pass BiocCheck, checks in a different package specific for Bioconductor.
CRAN-2015-1, Bioc-2015-1: Same mentions as the previous and encouragement to guidelines an package submission.
CRAN-2015-2, Bioc-2015-2
CRAN-2016-1: on this article there is a plot of the number of CRAN packages and time, and doesn’t list all packages listed. It explicitly mentions that the CRAN team asked for help processing package submissions and some people stepped up. Bioc-2016-1

CRAN-2016-2, Bioc-2016-2
CRAN-2017-1: mentions changes in CRAN checks, adding new memory access and static code analysis checks. It mentions that the submission has moved to a more automated one. It also mentions changes in the CRAN Repository Policy. Bioc-2017-1
CRAN-2018-1: checks in alternative BLAS/LAPACK implementations, the submission pipeline is defined. First time the amount of action taken by CRAN reviewers is listed in two categories automatic and manual. Changes in repository policy are listed. Changes in location of package repository archive , Bioc-2018-1
CRAN-2018-2: Changes in policy; packages should not give a check warning nor error. Bioc-2018-2: Moved to BiocManager to install packages.
CRAN-2019-1: More mentions to CRAN mirror security.

CRAN-2019-2: Updates in checklist for CRAN submissions, Bioc-2019-2
CRAN-2020-1: Many changes in CRAN policies. CRAN-2020-2: Many changes to CRAN policies. Bioc-2020-2: Announces the Technical and Community advisory boards (as well as the project-wide Code of Conduct).
CRAN-2021-1, Bioc-2021-1: Mentions conferences that will be virtual.
CRAN-2021-2: Shows an incomig path [See this friendly viewer, Bioc-2021-2: Mentions AnVIL and two online workshops to develop workflows.
CRAN-2022-1: List a change in CRAN policy and the CRAN Task View Initiative.
CRAN-2022-2: List some more repository policies. Bioc-2022-2: Lists infrastructure updates (and its funding), changes in the core team and new initiatives.
CRAN-2022-3, Bioc-2022-3
CRAN-2022-4, Bioc-2022-4: default branch renaming, partnership with Outreachy and blog are featured. Several working groups provide updates
CRAN-2023-1

In addition, several articles and blog posts have appeared. From those I found it is worth mentioning the following:

And my own posts:

Reasons CRAN packages are archived
CRAN files part 1
CRAN files part 2
CRAN maintained packages
CRAN review (and the talk at useRs 2021)
Bioconductor review
rOpenSci reviews
Bioconductor reviews
The article “Aspects of the Social Organization and Trajectory of the R Project”, from the R Journal 2009, also has a section about CRAN, noting that it “is challenged by its own success”.

Characteristics

The predominance of CRAN and its role as primary and default R repository has lead to some special treatment of the repository.

CRAN checks are in the R source code itself. While other repositories have their own checks in different tools. In addition, the CRAN environmental variables used are documented in the R-internals (they are more or less accessible in the svn repository too).

Others who know more have stated the benefits of CRAN too: This text is copied from Henrik Bengstsson in Bioconductor Slack:

FOREVER ARCHIVE:

The first one is that it publishes packages and versions of them until the end of time. When a package has been published on CRAN, it takes a lot for it to be removed from there. I don’t know if it ever happened, but I can imagine a package can be fully removed if it was illegally published in the first place (e.g. copyright, illegal content, ...) or malicious.

INSTALLATION SERVICE:

Then CRAN also provides a R package repository service for installing packages on CRAN using built-in R functions. The set of packages in the package repo is a subset of all packages on CRAN. The CRAN package repo makes a promise that all packages listed in PACKAGES can be installed. If they cannot make that promise, they’ll archive the package (=remove it from PACKAGES). I should also say, install.packages(url) can be used to install from the set of packages that are archived. Technically, old package versions are always archived.

CHECK SERVICE:

The content of the R package repository is guided by the CRAN package checks that run on R-oldrel, R-release, and R-devel across multiple platforms. The minimal requirement is that no package should remain in the package repository if the checks detects ERRORs (and those errors are not due to recently introduced bugs in R-devel). WARNINGs can also cause a package to be archived, but that process often takes longer. AFAIK, NOTEs are not a cause for a package being archived (but I could be wrong). The CRAN incoming checks, which you have to pass when you submit a new package, or an updated version, will make sure that the published package pass with all OKs. (It’s possible to argue for NOTEs being false positives, or for them not to be fixed, but that requires a manual approval by the CRAN Team).

I think there are many more resources discussing R repositories. If you know more I’ll be happy to update this post.

I think before I drag too much on the steps I’ll post this and collect some more articles I might have missed.

Last, Uwe Liegges presented about CRAN in useR!2017, thanks Tim Taylor for sharing it. In this video there is an explanation of why the solaris OS was used.

It has come to my attention that there is an article, by G. Brooke Anderson and Dirk Eddelbuette, about the R package repositories structure (among other things): Hosting Data Packages via drat: A Case Study with Hurricane Exposure Data

Reproducibility

## ─ Session info ───────────────────────────────────────────────────────────────────────────────────────────────────────
##  setting  value
##  version  R version 4.3.1 (2023-06-16)
##  os       Ubuntu 22.04.3 LTS
##  system   x86_64, linux-gnu
##  ui       X11
##  language (EN)
##  collate  en_US.UTF-8
##  ctype    en_US.UTF-8
##  tz       Europe/Madrid
##  date     2024-01-15
##  pandoc   3.1.1 @ /usr/lib/rstudio/resources/app/bin/quarto/bin/tools/ (via rmarkdown)
## 
## ─ Packages ───────────────────────────────────────────────────────────────────────────────────────────────────────────
##  package     * version date (UTC) lib source
##  blogdown      1.18    2023-06-19 [1] CRAN (R 4.3.1)
##  bookdown      0.37    2023-12-01 [1] CRAN (R 4.3.1)
##  bslib         0.6.1   2023-11-28 [1] CRAN (R 4.3.1)
##  cachem        1.0.8   2023-05-01 [1] CRAN (R 4.3.1)
##  cli           3.6.2   2023-12-11 [1] CRAN (R 4.3.1)
##  digest        0.6.33  2023-07-07 [1] CRAN (R 4.3.1)
##  evaluate      0.23    2023-11-01 [1] CRAN (R 4.3.2)
##  fastmap       1.1.1   2023-02-24 [1] CRAN (R 4.3.1)
##  htmltools     0.5.7   2023-11-03 [1] CRAN (R 4.3.2)
##  jquerylib     0.1.4   2021-04-26 [1] CRAN (R 4.3.1)
##  jsonlite      1.8.8   2023-12-04 [1] CRAN (R 4.3.1)
##  knitr         1.45    2023-10-30 [1] CRAN (R 4.3.2)
##  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.3.2)
##  R6            2.5.1   2021-08-19 [1] CRAN (R 4.3.1)
##  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.3.1)
##  rmarkdown     2.25    2023-09-18 [1] CRAN (R 4.3.1)
##  rstudioapi    0.15.0  2023-07-07 [1] CRAN (R 4.3.1)
##  sass          0.4.8   2023-12-06 [1] CRAN (R 4.3.1)
##  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.3.1)
##  xfun          0.41    2023-11-01 [1] CRAN (R 4.3.2)
##  yaml          2.3.8   2023-12-11 [1] CRAN (R 4.3.1)
## 
##  [1] /home/lluis/bin/R/4.3.1
##  [2] /opt/R/4.3.1/lib/R/library
## 
## ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

In version 3.1.2 Omegahat didn’t provide Windows binaries and in 4.1 from the default repositories (See 4.1 in NEWS(.4)).↩︎
This lead to the need of having a special function to install packages from Bioconductor. Initially a function biocLite and later with the BiocManager package.↩︎
NEWS in 2.15 section ↩︎

rtweet future

Thu, 16 Feb 2023 00:00:00 +0000

Background: how I became the maintainer of rtweet

I didn’t want to maintain rtweet. It might sound strange coming from its maintainer, but I didn’t want the responsibility of writting software 12k people install it monthly. My offer was always to help with it so that the users could benefit from improvements and bug fixes on the package. I initially thought that having permissions to close issues, label them would help the community and the maintainer.

I was not totally altruistic. As recently recommended by Maëlle and Steffi, I had some interest in the package. I had a bot posting some plots daily. I wanted to have alt text in the tweets. There was a pending PR for just that. I could fork and use my own version or help with the package.

I got in touch with rOpenSci about the package. After some time waiting hearing back from the author of the package (Many thanks Michael W. Kearney, I was given edit permissions to the repository (under the helping eye of Scott Chamberlain). At the time, I got permission from rOpenSci there were 167 issues and PR open.

As I started going through them and changing the source code, people showed up to help (Thanks!). New contributors helped with closing issues via new PR or simply advising about naming functions or asking for its future. Another developer gained access to repository and contributed with their expertise (resulting in some funny moments). Despite all (breaking) changes, we tried to make the package easier to maintain. After waiting some time, for further community feedback, I released a new version through CRAN.

Shortly after, for some reasons my bot got less views and engagement. It made me realize that it might be an opportunity to start a professional project around the content of what this bot did. In addition, although I learn a lot from the online communities I decided to connect more with the local community. I am currently involved with re-launching the Barcelona R user group and organizing the Spanish R conference. These activities take time an energy away from package maintenance (not just rtweet). However, my support for the users of rtweet remains.

The community support I received was great. I hope to pass on it. CC-BY-4.0 Artwork by @allison_horst.

Current situation: supporting the v1 and adding support to the v2 API

To maintain rtweet I needed to adapt and understand the Twitter’s API (v1) documentation. The documentation didn’t always match the functionality. rtweet follows the API tightly, any change might break the package. For instance, the addition of the edit field broke the parsing of the tweets.

At the same time one of the oldest issues in rtweet is moving to the new API v2. With the 1.0 release, I decided it was time to stop adding features relying in it. It was clear that Twitter was moving to deprecate and replace it with the newer API. There are many benefits of the new API to developer and users. But as I realized that I should still fix bugs related to them.

The 1.1 release have recently provided some bug fixes and support for the v2. There is also an outstanding issue preventting new users of connecting to Twitter (fixed in github). The streaming endpoint in v1 stopped working before the announced date. So the new release included support for the replacement endpoint in v2.

As you have guessed, between releases I had been thinking and working to support API v2. The foundations to support the new endpoints were already set and easily expanded to new endpoints. In the development version of the package (in the devel branch), it is possible to retrieve bookmarks, retrieve the archive if you have academic access, among other endpoints.

Going forward: supporting rtweet users of v2 API

Recently (~3 weeks), there have been anouncements of future changes in who and how will be able to access the API. Simultaneously, there have been unannounced restrictions affecting other tools using the API. Recent changes and announcements are driven by need of money to sustain Twitter. To maintain rtweet with its current functionality it might need funds.

I will continue supporting rtweet and the freely accessible endpoints. But given that I will have less time and energy for rtweet, I am looking for a co-maintainer to help me:

Supporting new endpoints, using httr2, testing an API in CI, …
Review changes to avoid new bugs.
Help with issues and questions that the transition to API v2 and the current uncertainty bring.

Get in touch with me in this issue.

From time to time, I receive bug reports and petitions from premium API users. Currently, premium users get access to more data, elevated request rates and other endpoints. Helping them is usually challenging, and developing support for these endpoints will be difficult. To continue supporting these users I’ve set up a ☕ buymeacoffee and I, and my co-maintainer, will be open to consulting jobs about rtweet. With these jobs and funding we will be able to support them and implement new endpoints for all the users.

There is scarce information about the API changes and prices. Changes might come suddenly. We’ll do our best to keep up and inform all users. I hope this will be a good way to continue supporting the package an the community of users. Let me know if you have other suggestions.

Decorating/contributing to R. CC-BY-4.0 artwork by @allison_horst.

Thanks Maëlle for your support and reviewing the post.

Leadership in open source projects

Fri, 27 May 2022 00:00:00 +0000

This is the second part of the previous post about concepts around open source/free software.

Since last book, I also read Uncurled which recommended “The Making and maintenance of open source software” (I will short it to MMOSS) and “Producing Open Source Software” (POSS), which provide first hand experiences about how those maintainers handled different projects.

This post is about projects, growth and management of the project (I don’t want to make them about R but I will also use my experience within R to reflect on these ideas).

Projects

It is common to say refer to open source as projects. While it is true that open source/free software is a project with limited resources it doesn’t have a fixed end date. I don’t think they fit the criteria of the PMBOK.

Software “projects” run from the usefulness for the maintainer and the feedback received. If a maintainer does no longer use a piece of software and doesn’t receive any feedback they might choose to not update the public version. The software is still up there but the valuable resource (maintenance) is no longer there.

This explains why it is so common to look up for activity on a “project”. If a developer/maintainer hasn’t committed or reacted in a long time the “project” is no longer active. The code might still be used, it might have more users, but it is no longer a project.

Another characteristics of projects is that there is a leadership. It might be a team or an individual like a benevolent dictator for life as explained by POSS. This leadership most important role is communication. It is not enough to have commit access or a foundation but to communicate and steward the community towards a direction or following some guidelines.

This communication is usually done by NEWS and changelog, in bug reports feedback on mailing list (and by the lack of communication too).

These leaders are those who can steward with contributor growth, support, ease of participation and technical improvements. Particularly POSS mentions the distinction between commit access and maintainer; also considering maintainers those that organize conferences, set up infrastructure and participate even if not committing code.

All the activities of the maintainers (and others) help with the project status and growth.

Growth?

There seems to be in the MMOSS book a tendency to only mention growth, which is very hard to measure. Just fo give an example focusing on users: Is LAPACK user base growing or not? I would say it is, because R uses it and more people is using R. But there isn’t, to my knowledge, a growth on users claiming to be experts on LAPACK, although there are several LAPACK optimizations.

MMOSS mentions that the (long term) contributors tend to lurk and just chime in when they can propose something of value or given the room. This is echoed by POSS, which even says that one of the roles of maintainers is to encourage other contributors to become maintainers.

Casual contributors post when they have an issue/bug while using it but they are not interested on the long term health of the software. Presumably on the classification on table 1 of the previous post refers to both. However, as acknowledge by the author it is hard to measure users and contributors.

The books always focus on the very positive outcome growth, not stagnation or reduction of users/contributors. I think it is important to acknowledge this happens too and find the causes to avoid them.

On python the support of python 2.7 had to be extended multiple times due to slow uptake of python 3.x. It might have similar effects than the upgrade from perl4 to perl5, which (besides many other reasons) left perl outside the curriculum of the universities, so without many new users.

Probably the best indicator is the relationship between users, contributors and maintainers. If these are three different groups of people, there are more users than contributors and less maintainers while the dynamics are good and the software is in good healthy status.

End

I haven’t touch much the status of code but this is also important it can be status as in quality of code and status of the software and community. The first is easier to measure and compare while the second one is much harder, more subjective and thus less general.

Whatever the status of a software is don’t forget to be nice to users, contributors and help them become more familiar with the code in a friendly manner.

Concepts around open source/free software

Wed, 16 Mar 2022 00:00:00 +0000

This post is to lay out some concepts I picked up after reading “The Making and maintenance of open source software”. Having these concepts in mind might help me on my contributions to R and OSS in general. I write these thought to come back to in future posts.

The book classify projects by two axis, contribution growth and user growth:

	High user growth	low user growth
High contributor growth	Federations	Clubs
Low contributor growth	Stadiums	Toys

And classify projects according to the following characteristics :

Technical
Support
Ease of participation
User adoption
Contributor growth

Code seems like a common good which require the following characteristics:

Intrinsic motivation
Modular
Granular
Low cost of coordination

On the author’s opinion only maintainers are interested in the success of the whole community and need to make trade off between different interest of the community around the project.

Motivation is very important and I classify based on the source of motivation and the sign of it:

	Positive	Negative
Intrinsic	Learn skills	Burn out
Extrinsic	Social benefits	Friction, or lack of feedback

Following the book, contributors can be grouped in two:

Invested: Lurk before making a contribution, learn the quirks of the community
Casual: Adding value to themselves and other

Contributors might spend many time learning about the community before making their first contribution (or show themselves). That’s why only knowing if this is the first contribution of someone doesn’t mean they will continue contributing on the project.

Users, can be classified in two groups: passive, they use the software and nothing else, or active. Active users might do one of the following:

Educate others: write a blog post, or material
Spread the word: Announce they use the software
Support: Solve other’s users questions
Fill bug reports

The health of the project depends on the popularity dependencies and active and future maintenance of the software.

However, the book says that one contributor is not the same as the other. For instance removing a maintainer causes more harm than a casual contributor.

The source of this is that software is like a puppy. The value of the code is how live it is, static code has null value. but once it is being used it is very valuable.

For this reason the maintenance costs once there are users is very high. However, in general there are few ways to know how many users does a piece of software have.

This produces marginal costs to maintainer, which are driven by how are these goods:

	Excludable	Non-Excludable
Rivalrous	Private goods	Commons good
Non-Rivalrous	Club goods	Public goods

Costs are mainly attention from the maintainers from the users and contributors. Users are like a cars in a highway initially there is no problem, but at high levels of traffic adding new lanes don’t solve traffic jam.

However, the cost increase with more request, the bandwidth to download software and hosting

More users leads to more requests, which lead to a competition for maintainers to do less proactive work and do more reactive work.

This leads to start on very simple organiztion and evolve to more disorganized complexity and then to a organized complexity to just cope with the costs of the project. On this organization complexity relationships with maintainers become important.

Value = usage+dependencies-maintenance+substitutability+switching cost+enabling while Cost = development +maintenance+attention.

The common (and scarce) good is the attention of both maintainers and developers. Which requires judgement call on which kind of requests dedicate their time: extractive or non-extractive requests.

The benefit for maintainers once the reputation/recognition is enough is almost non existent.

The book cites several communities Python, ruby, Linux, javascript, java, but I don’t think they used R community as a source. So what are the implication of these concepts to the R community? How do we help maintainers to keep up with their work or let in new maintainers?

Reproducibility

## ─ Session info ───────────────────────────────────────────────────────────────────────────────────────────────────────
##  setting  value
##  version  R version 4.1.2 (2021-11-01)
##  os       Ubuntu 20.04.4 LTS
##  system   x86_64, linux-gnu
##  ui       X11
##  language (EN)
##  collate  en_US.UTF-8
##  ctype    en_US.UTF-8
##  tz       Europe/Madrid
##  date     2022-03-16
##  pandoc   2.17.1.1 @ /usr/lib/rstudio/bin/quarto/bin/ (via rmarkdown)
## 
## ─ Packages ───────────────────────────────────────────────────────────────────────────────────────────────────────────
##  package     * version date (UTC) lib source
##  blogdown      1.8.1   2022-02-19 [1] Github (rstudio/blogdown@9af7733)
##  bookdown      0.24    2021-09-02 [1] CRAN (R 4.1.2)
##  bslib         0.3.1   2021-10-06 [1] CRAN (R 4.1.2)
##  cli           3.2.0   2022-02-14 [1] CRAN (R 4.1.2)
##  digest        0.6.29  2021-12-01 [1] CRAN (R 4.1.2)
##  evaluate      0.15    2022-02-18 [1] CRAN (R 4.1.2)
##  fastmap       1.1.0   2021-01-25 [1] CRAN (R 4.1.2)
##  htmltools     0.5.2   2021-08-25 [1] CRAN (R 4.1.2)
##  jquerylib     0.1.4   2021-04-26 [1] CRAN (R 4.1.2)
##  jsonlite      1.8.0   2022-02-22 [1] CRAN (R 4.1.2)
##  knitr         1.37    2021-12-16 [1] CRAN (R 4.1.2)
##  magrittr      2.0.2   2022-01-26 [1] CRAN (R 4.1.2)
##  R6            2.5.1   2021-08-19 [1] CRAN (R 4.1.2)
##  rlang         1.0.2   2022-03-04 [1] CRAN (R 4.1.2)
##  rmarkdown     2.13    2022-03-10 [1] CRAN (R 4.1.2)
##  rstudioapi    0.13    2020-11-12 [1] CRAN (R 4.1.2)
##  sass          0.4.0   2021-05-12 [1] CRAN (R 4.1.2)
##  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.1.2)
##  stringi       1.7.6   2021-11-29 [1] CRAN (R 4.1.2)
##  stringr       1.4.0   2019-02-10 [1] CRAN (R 4.1.2)
##  xfun          0.30    2022-03-02 [1] CRAN (R 4.1.2)
##  yaml          2.3.5   2022-02-21 [1] CRAN (R 4.1.2)
## 
##  [1] /home/lluis/bin/R/4.1.2/lib/R/library
## 
## ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────