B G Giraud
email: bertrand.giraud@cea.fr

Laboratory Density Functionals

We compare several definitions of the density of a self-bound system, such as a nucleus, in relation with its center-of-mass zero-point motion. A trivial deconvolution relates the internal density to the density defined in the laboratory frame. This result is useful for the practical definition of density functionals.

Recently [1], Engel pointed out that the usual form of nuclear Hamiltonians,

H = A i=1 p 2 i 2m + A i>j=1 v ij , (1)
forbids a proper definition of the nuclear density. Indeed, the center of mass (CM) of the system delocalizes in a plane wave; the nucleus is everywhere, the density is flat. The conclusion holds whether the two-body interaction v is local or non local and still holds if three-body forces are also present in H, as long as any explicit density dependence is avoided; Galilean invariance must be ensured. An elementary modification of H,

H = H + A ω 2 R 2 /2, R = A -1 i r i , (2)
traps the CM. The ground state of H now factorizes as a product of a Gaussian for this CM and an "internal" wave function of the (A -1) Jacobi coordinates,

Ψ(r 1 , r 2 , ..., r A ) = Γ(R) ψ int (ξ 1 , ξ 2 , ..., ξ A-1 ) , ξ 1 = r 2 -r 1 , ξ 2 = r 3 - r 2 + r 1 2 , ... , ξ A-1 = r A - r A-1 + r A-2 + ... + r 1 A -1 . (3)
Calculations in the {r i } representation are much more convenient than those in the {R, ξ j } one, for obvious symmetrization reasons. The laboratory density,

ρ(r) = A dr 1 dr 2 ... dr A-1 |Ψ(r 1 , r 2 , ..., r A-1 , r)| 2 , (4)
1 is much easier to calculate than the "internal" density,

σ(ξ) = A dξ 1 dξ 2 ... dξ A-2 |ψ int (ξ 1 , ξ 2 , ..., ξ A-2 , ξ)| 2 , (5)
Throughout this note, we shall use the word "internal" instead of "intrinsic" when we refer to properties independent from the CM. This is because we retain the word "intrinsic" for those states out of which rotation bands and/or parity vibrations are modelized. Our understanding is that the adjectives "internal" and "intrinsic" belong to completely distinct concepts and models. Three remarks are in order at this stage, i) The density of interest for a density functional theory (DFT) is ρ, not σ. Indeed the Hohenberg-Kohn theorem derives from embedding the system in an external field, namely replacing H by

K = H + A i=1 u(r i ) , (6)
then considering the density τ (r) of the ground state Ξ of K,

τ (r) = A dr 1 dr 2 ... dr A-1 |Ξ(r 1 , r 2 , ..., r A-1 , r)| 2 , (7)
and finally proving that there is a one-to-one map between u and τ. The ground state energy of K receives the contribution dr u(r) τ (r), out of which u and τ are recognized as conjugate Legendre coordinates, hence the functional Legendre transform which defines the density functional. When u vanishes, ρ is that limit of τ which minimizes the functional. It seems obviously very difficult to set any similar chain of arguments in the Jacobi representation! ii) Despite this priority of ρ for a DFT, the internal nature of σ is compelling for a physical interpretation. It is tempting to calculate σ in the {r i } representation. With the Gaussian Γ square normalized to unity, one finds

A -1 σ(ξ) = dR dξ 1 dξ 2 ... dξ A-2 [Γ(R)] 2 |ψ int (ξ 1 , ξ 2 , ..., ξ A-2 , ξ)| 2 = dR dξ 1 ...dξ A-2 dξ A-1 δ(ξ A-1 -ξ) [Γ(R)] 2 |ψ int (ξ 1 , ξ 2 , ..., ξ A-2 , ξ A-1 )| 2 = dr 1 ...dr A-1 dr A δ r A - r 1 + r 2 + ... + r A-1 A -1 -ξ |Ψ(r 1 , r 2 , ..., r A )| 2 . (8)
iii) the last Jacobi coordinate also reads

ξ A-1 = A r A -(r 1 + r 2 + ... + r A-1 + r A ) A -1 = A A -1 (r A -R). ( 9
)
The density σ therefore also represents, except for a trivial rescaling factor, the density referring to the internal degree of freedom, r A -R.

Finally, according to Eqs. ( 4) and ( 9), the density ρ reads,

A -1 ρ(r) = dr 1 dr 2 ... dr A-1 dr A δ(r A -r) |Ψ(r 1 , r 2 , ..., r A-1 , r A )| 2 = dR dξ 1 ...dξ A-1 δ R + A -1 A ξ A-1 -r [Γ(R)] 2 |ψ int (ξ 1 , ..., ξ A-2 , ξ A-1 )| 2 = dR dξ 1 ...dξ A-2 [Γ(R)] 2 ψ int ξ 1 , ..., ξ A-2 , A A -1 (r -R) 2 = A -1 dR [Γ(R)] 2 σ A A -1 (r -R) . (10)
The convolution transforming σ into ρ is transparent, with again an inessential rescaling factor A/(A -1). The zero-point motion of the CM blurrs the internal density in a way which can be easily inverted, via a deconvolution. The bottom line is, ρ contains the same information as σ. It is thus possible, and likely much easier, to design a DFT with laboratory densities τ. At the end one recovers the internal σ by a deconvolution of ρ, that solution obtained by the minimization, with respect to τ, of such a "laboratory Hohenberg-Kohn functional".

It will be noticed that the presence in K of external potentials u(r i ) couples the CM degree of freedom R and the internal ones ξ j . There is, in general, no CM factorization for eigenstates of K. The factorization occurs at the limit u = 0. Then one must verify that the Fourier transform of ρ shows the factorized, Gaussian decay at large momenta, implied by the convolution, Eq. (10). Otherwise, deconvolution will fail. This "deconvolution syndrome" is very well documented in the literature about generator coordinates. For the DFT, expansions of the density in harmonic oscillator functions and related polynomials, constrained [2] to satisfy matter conservation, make a useful precaution to avoid the deconvolution syndrome.

For atoms and molecules, CM traps factorizing other wave packets Γ than Gaussians might be convenient, but the link between σ and ρ remains the same.

We conclude by claiming that a density functional theory for self-bound systems is available with densities in the laboratory system, without any loss of information about the internal, physical density. Acknowledgement: The author is indebted to B.K. Jennings for calling his attention to the work of Engel [1].


Théo Zimmermann
email: theo@irif.fr

A first look at an emerging model of community organizations for the long-term maintenance of ecosystems' packages

Keywords: Software and its engineering → Maintaining software, Open source model, Software libraries and repositories package ecosystem, maintenance, open source, fork, community

One of the biggest strength of many modern programming languages is their rich open source package ecosystem. Indeed, modern language-specific package managers have made it much easier to share reusable code and depend on components written by someone else (often by total strangers). However, while they make programmers more productive, such practices create new health risks at the level of the ecosystem: when a heavily-used package stops being maintained, all the projects that depend on it are threatened. In this paper, I ask three questions. RQ1: How prevalent is this threat? In particular, how many depended-upon packages are maintained by a single person (who can drop out at any time)? I show that this is the case for a significant proportion of such packages. RQ2: How can project authors that depend on a package react to its maintainer becoming unavailable? I list a few options, and I focus in particular on the notion of fork. RQ3: How can the programmers of an ecosystem react collectively to such events, or prepare for them? I give a first look at an emerging model of community organizations for the long-term maintenance of packages, that appeared in several ecosystems.

INTRODUCTION

Efficient software engineering and the conception of large software systems critically rely on reusable code [START_REF] Sametinger | Software Engineering with Reusable Components[END_REF]. Since the rise of open source ecosystems and package managers, software reuse has become a systematic coding practice, even for small and medium-sized software projects. Decan et al. [START_REF] Decan | An empirical comparison of dependency network evolution in seven software packaging ecosystems[END_REF] found a majority of packages depend on other packages in all seven ecosystems they studied. Indeed, modern application-specific package managers have reduced the cost of sharing pieces of reusable code (libraries) that a programmer can extract from their project so that others can benefit from it. It has also made it much easier to rely on such a library in one's project. The consequence is that, nowadays, programmers will always look for a package solving their problem before considering tackling it by themselves. The extreme case is the one of trivial packages [START_REF] Abdalkareem | Why do developers use trivial packages? An empirical case study on npm[END_REF], which contain only one (sometimes very straightforward) function, and yet still get many users.

While creating and sharing a new package has now become very easy, does not cost much to the package author, and may even be beneficial to them, maintaining a package long-term can be a real burden [START_REF] Miller | Why do people give up flossing? A study of contributor disengagement in open source[END_REF]. Furthermore, authors may have little incentive to maintain some of their packages, considering that in some cases, they are not even using them anymore [START_REF] Doglio | The latest npm breach[END_REF]. On the other hand, users that are currently using the library have much more incentive to contribute to maintaining it, but this is not always as easy for them as it is for the author.

The question of who should be responsible for maintaining an open source library is therefore far from trivial. And the answer may actually depend a lot on the way the ecosystem is structured.

This paper begins by asking a first research question (RQ1): how prevalent is the threat to ecosystems' health coming from packages that are used by multiple projects but could suddenly stop being maintained because a single person was responsible for them?

Next, we explore the various mitigation paths that projects can follow when faced with such a situation (RQ2).

The paper concludes with a last research question (RQ3): what can be done at the level of the ecosystem to mitigate such threats when they occur, or reduce their chances of occuring in the future? We will focus on a model of community organization, which emerged in several ecosystems, that can simplify the process of hard forking and provide a new home for unmaintained packages.

ESTIMATING THE PREVALENCE OF SINGLE-MAINTAINER PACKAGES

The main issue of small libraries is generally that they have fewer maintainers, most often a single maintainer, who might become less active or outright missing for a number of reasons. While the extreme case of trivial packages [START_REF] Abdalkareem | Why do developers use trivial packages? An empirical case study on npm[END_REF] can be trivially solved by copypasting the code and maintaining it within a larger source code base, I am interested in the frequent case of non-trivial libraries that are worth keeping as separate dependencies (to avoid duplicating innovation and maintenance work in the various projects depending on them) but are still small enough to have a single maintainer.

More specifically, I propose to focus on non-trivial libraries which are depended upon directly by at least two actively maintained software projects by distinct developers or developer teams: these libraries are thus worth maintaining separately. The goal of this section is to estimate the proportion of such libraries which have a single person maintaining them (i.e., a single developer has push-access, even if changes might be contributed by others through pull requests or e-mailed patches). Given that it can happen that maintainers of such libraries stop responding to requests and updating their library for extended periods of time, I claim they represent a very specific threat to the health of ecosystems. This estimation will be based on the dataset provided by Libraries.io [START_REF] Nesbitt | Libraries.io Open Source Repository and Dependency Metadata[END_REF] (cf. the first companion Jupyter notebook [START_REF] Zimmermann | Evaluation of the prevalence of single-maintainer packages[END_REF]). This dataset includes a table of packages with source repositories, containing more than 3,000,000 entries. For this estimation, we focus on the 2,500,000 packages whose repository is located on GitHub, because the dataset contains more complete data for these.

A first filtering step of packages with more than one reverse dependency and a repository size of at least 10 KB (in an attempt to filter out trivial packages), makes this number go down to 257,000 packages, including 116,000 npm packages and between 10,000 and 30,000 PHP, Ruby, Python, and Maven packages.

To further filter only packages that are used in actively maintained projects from different owners (individual developers or teams), we extract the 800,000 GitHub repositories that were pushed to in the last six months (before the Libraries.io dataset was published) from a table which contains about 34,000,000 entries.

Finally, these data are joined by relying on Libraries.io's dependency table, which includes about 390,000,000 entries. This results in about 65,000 packages that are depended upon by two actively maintained projects from distinct owners.

Sometimes, many packages come from a single repository (more than 1,500 packages in the DefinitelyTyped repository 1 and 286 packages in the Babel repository -the next biggest monolithic repository). In this case, it is hard to estimate different maintenance indexes for the different packages, and giving the same index to thousands of packages would completely bias the results, so we keep only one package per repository (the most depended upon).

Out of the remaining 50,000 packages, 18% have just a single contributor (which is worse than having a single maintainer).

For each package owner, we can query GitHub to know whether it is an organization and how many public members it has. About 33% of these 50,000 popular packages belong to organizations with at least two public members. Belonging to an organization does not guarantee that the package will keep being maintained, but it should prevent against a maintainer disappearing without notice and no one having access to the repository.

For the rest of the package owners, I approximate the number of maintainers by querying for the number of assignable users. Assignable users are a super-set of collaborators with write-access:2 they correspond to organization members with read-access (when the owner is an organization ) and collaborators that were manually added to the repository itself [START_REF]Assigning issues and pull requests to other GitHub users[END_REF]. Of the remaining packages that were not part of an organization with two public members, only 33% have two or more collaborators. This leaves a large proportion of packages at risk.

Threats to validity

The goal of this section was to estimate the proportion of packages that are sufficiently popular to be used in two maintained projects by different owners, and yet have a single maintainer. Two kinds of errors could have affected the results: errors in the computation of popular packages and errors in the computation of single-maintainer packages.

Popular packages could have been missed, and in fact it is certain that this was the case, since some popular packages are hosted outside of GitHub. Another possible error could have been with the maintenance criterion. Some projects should be considered maintained even if they were not pushed to during a six-month period (some feature-complete packages may need less frequent updates [START_REF] Valiev | Ecosystem-level determinants of sustained activity in open-source projects: A case study of the PyPI ecosystem[END_REF], especially in a slowly evolving ecosystem). Furthermore, some projects may have been pushed to after Libraries.io last refreshed GitHub's meta-data about them, and thus the dataset may have contained outdated information that could have resulted in marking these projects as unmaintained. Therefore, the number of maintained packages depending on a given package could have been underestimated, and the package excluded because of this. However, the resulting sample of popular packages is still rather large (50,000 packages). Bias in this sample could result mostly from the exclusion of non-GitHub projects and of many packages hosted in monolithic repositories.

I computed dependencies between packages irrespective of package version numbers, so this could also lead to considering former dependencies that were dropped or replaced.

Then, the criterion that was used to approximate the number of maintainers is bound to have introduced some errors as well. However, I believe that it is more likely to have resulted in overestimating the number of maintainers of a package, rather than underestimating it. Indeed, it is not because someone can be assigned issues in a repository that they have access to all the required tools and credentials to be considered an actual maintainer of the package. Even if they are an actual maintainer, and are ready to take over from the previous maintainer for a while, if they do not have admin-access, they may not be able to nominate new maintainers, and this can harm the maintenance of the package after some time, in particular if they want to step down eventually.

Overall, I believe that these threats do not put much doubt on the main conclusion of my analysis which is that many popular packages have a single maintainer.

Related work

2.2.1 Project maintainers and developers. Yamashita et al. [START_REF] Yamashita | Revisiting the applicability of the Pareto principle to core development teams in open source software projects[END_REF] analyzed the proportion of core developers in 2,496 GitHub projects. They used various criteria to define core developers, one of them using GitHub's collaborator API endpoint (through the GHTorrent dataset [START_REF] Gousios | GHTorrent: GitHub's data from a firehose[END_REF]). Unfortunately, access to this API has been restricted since then and GHTorrent does not include this data anymore. This is why I used the assignable users information instead. My analysis is different from studies computing metrics such as bus factor (also called truck factor) [START_REF] Ferreira | Algorithms for estimating truck factors: a comparative study[END_REF][START_REF] Torchiano | Is my project's truck factor low? Theoretical and empirical considerations about the truck factor threshold[END_REF], and more generally estimating turnover risks [START_REF] Nassif | Revisiting turnover-induced knowledge loss in software projects[END_REF][START_REF] Peter C Rigby | Quantifying and mitigating turnover-induced knowledge loss: Case studies of Chrome and a project at Avaya[END_REF] within a software project, because I am focusing on the problem of who is able to integrate changes and publish new versions of a package. It can happen that popular packages receiving pull requests from many contributors still have a single maintainer that suddenly disappears. On the other hand, a project that is not subject to such risks, because it belongs to an active organization or has several maintainers, can still be subject to knowledge loss risks. Therefore, the two types of studies are complementary, and highlight different, but related, health risks that can affect a package ecosystem.

Avelino et al. [START_REF] Avelino | On the abandonment and survival of open source projects: An empirical investigation[END_REF] have found a significant proportion of projects having faced the event of a "truck-factor" developer stepping down, despite having only analyzed about 1,900 popular repositories. Less than half of the projects survived, generally because a new or preexisting contributor took over. They interviewed these contributors that helped projects survive, and identified the difficulty of getting access to the repository as a significant barrier (when project maintainers had become unresponsive).

Unmaintained projects.

Several studies have highlighted the fact that many open source projects are dormant or abandoned [START_REF] Kalliamvakou | An in-depth study of the promises and perils of mining GitHub[END_REF][START_REF] Khondhu | Is it all lost? A study of inactive open source projects[END_REF]. However, a project threatening to become dormant does not pose the same risk to open source ecosystems depending on whether it has a lot of users, very few, or none beyond its author.

Valiev et al. [START_REF] Valiev | Ecosystem-level determinants of sustained activity in open-source projects: A case study of the PyPI ecosystem[END_REF] have found clear evidence that packages that have been able to gather a large community of users over time are much less likely to become dormant. This expected result does not contradict the observation that this risk is still present and strong for a number of popular packages.

Ecosystem health.

Measuring ecosystem health is an important and active research question [START_REF] Jansen | Measuring the health of open source software ecosystems: Beyond the scope of project health[END_REF][START_REF] Mens | Towards an interdisciplinary, socio-technical analysis of software ecosystem health[END_REF]. My work relates to this literature by highlighting a health risk factor (single-maintainer projects) that could be integrated in health assessment frameworks.

COPING WITH UNMAINTAINED PACKAGES

When a package becomes unmaintained (the maintainer does not respond anymore to issues and pull requests and does not push new commits or versions), what can the projects using it do?

Removing or replacing the dependency

Upon discovering that a project depends on an unhealthy dependency, it can be time to reevaluate the usefulness of the latter. Sometimes, the functionality brought by the dependency is not that useful, or an alternative, healthier package could be used instead.

Removing or replacing the dependency can, in such case, turn out to be beneficial, although the migration can bear significant costs to the project, not necessarily at the best of time. Furthermore, this is a solution that each project has to evaluate on their own, and while it might be feasible for some projects to drop the dependency, it might be significantly harder for others. Having many projects migrate away from an unhealthy library can further reduce its chances of surviving, thus threaten other projects for which migrating is too costly.

Previous studies have mined data from projects having performed library migrations to suggest candidate libraries to migrate to [START_REF] Teyton | Mining library migration graphs[END_REF] and to map between methods of two libraries [START_REF] Alrubaye | Migration-Miner: An Automated Detection Tool of Third-Party Java Library Migration at the Method Level[END_REF][START_REF] Teyton | Automatic discovery of function mappings between similar libraries[END_REF].

Vendoring

Vendoring a dependency is the process of copying its sources within the project's sources and building the whole thing, instead of installing the dependency with a package manager first and building the project by relying on the installed dependency.

Vendoring dependencies allows integrating patches proactively. Some of these patches might have been found in unmerged pull requests from external contributors. However, this solution cannot be a long-term solution because it is more work for everyone to have to integrate patches manually, and at some point new pull requests cannot continue to be based on an unchanged base branch. Early academic works which studied forking considered only what is usually denoted today as hard forks. For instance, in their 2012 paper [START_REF] Robles | A comprehensive study of software forks: Dates, reasons and outcomes[END_REF], Robles and González-Barahona give a definition of a fork that includes requirements such as having a new project name and a disjoint community. The Hacker's Dictionary [START_REF] Eric | The new hacker's dictionary[END_REF] even specifies that the two code bases must be developed in parallel and have irreconcilable differences between them.

Forking

The "right to fork" is qualified by Weber [45, page 64] as an essential freedom of free software. Nyman and Lindman [START_REF] Nyman | Code forking, governance, and sustainability in open source software[END_REF] claim that forking is the most important tool to guarantee sustainability in open source development, and that the right to fork has a major effect on governance, even in the absence of any forks.

With the rise of GitHub, forking has taken a new meaning. Development forks [START_REF] Fogel | Producing open source software: How to run a successful free software project[END_REF]Chapter 8] are copies of the sources where a contributor makes changes to the code in order to submit them for review through the pull request mechanism.

But even before GitHub, forking was much more common and much less definitive than hackers and researchers alike seemed to believe. Nyman and Mikkonen [START_REF] Nyman | To fork or not to fork: Fork motivations in SourceForge projects[END_REF] observed the presence of many forks on SourceForge, including forks claimed to be temporary and hoping to get their changes integrated upstream (that can therefore be classified as development forks). They also noticed the phenomenon of forking a project because it seemed to be abandoned, and not because of some disagreement. While this should still be denoted as a hard fork, there is only one project under development after the fork, contrary to the definition of the Hacker's Dictionary [START_REF] Eric | The new hacker's dictionary[END_REF]. This is the kind of forks that we are interested in, in this section. We denote this sub-type of hard forks as friendly forks.

Socio-technical issues when forking a package.

When to advertise a friendly fork? While it is easy for anyone to maintain a personal fork of a project, which contains the original code with some modifications on top, it may be difficult to decide when to advertise this project as a friendly fork intending to take over the place of the original, unmaintained project.

First, maintaining a fork of an unmaintained project for a long time without doing any advertisement is likely to result in duplicated work, as other persons interested in the project, but who are not aware of the fork, run in the same issues and prepare their own fixes. Zhou et al. [START_REF] Zhou | What the fork: a study of inefficient and efficient forking practices in social coding[END_REF] studied inefficiencies that may arise mainly due to lack of awareness of the work that was done in forks.

Besides, putting efforts into advertising a fork can pay back by bringing an influx of new contributions from developers that were interested in the project but were discouraged by the absence of feedback from the maintainer. Still, it requires time and commitment. The model of community forks that is discussed in Section 4 can help reduce the level of commitment required.

The time to wait until the source project is considered unmaintained can also vary depending on community expectations, and is rarely clear to anyone. While SourceForge's "Abandoned Project Takeover" page set a 90-day delay to get an answer, 3 CPAN's FAQ [START_REF] Hietaniemi | CPAN Frequently Asked Questions[END_REF] informally sets a delay of one year without response before considering transferring maintenance of a module.

How to fork on GitHub? On GitHub, forking a project is as easy as clicking on a button. But, when preparing a hard fork, the new maintainer may wonder whether this is the right choice.

By default, forks on GitHub are not meant to take over a project: issues are disabled (but they can easily be switched on) and a prominent link to the source project is displayed under the project's name. Besides, code is not searchable in a fork unless it has more stars than its source [START_REF]Searching in forks[END_REF] (which can take quite some time to get).

GitHub does not make discovering maintained forks very easy: the only way to learn about them is to display the fork tree, which is often very large. When the forks are too numerous, GitHub will not display the full list and the most important ones may be missing. The "Lovely forks" browser extension [START_REF] Upadhyay | Lovely forks[END_REF] helps developers discover notable forks by querying for them and showing them prominently, where GitHub would display a fork's source.

An alternative solution is to create a new repository manually, and to push the content of the original repository in it. It is also possible to contact GitHub staff to remove the fork status from an existing repository. They can also change the base directory in a fork network, but this requires consent from the original owner. 4Migrating issues and pull requests. GitHub does not provide any support for easily duplicating issues between two repositories. Doing so is nonetheless possible using a tool such as github2github [START_REF] Berestovsky | github2github[END_REF]. Reusing the exact same numbers for imported issues is technically feasible. The advantage of doing this is that the code and the commit message frequently reference issues by their number, and importing preexisting issues ensures that these numbers continue to make sense. On the other hand, new maintainers might appreciate the ability to duplicate only a subset of issues they intend to solve.

If the fork was created using GitHub's fork button, it is also possible to manually recreate pull requests for every pull request that is still opened on the original repository.

How to publish updates to the package registry? Different registries and different ecosystems have different views regarding the transfer of a package to a new maintainer. Most support voluntary transfers, and some also support transfer to a new maintainer when the previous maintainer is completely unresponsive.

In some registries, all packages are scoped (the package name is prefixed by the name of the author), so unless an author explicitly gives access to a new maintainer, there is no way to continue using the package full name, and everyone will have to update their dependencies. On the other hand, it means the source project does not get a special status in the package index compared to its forks.

In some registries that support both non-scoped and scoped package names, keeping the same base name while adding a scope can be a way of marking the affiliation of the package to the original one. 5 This is also the technique that is used by the DefinitelyTyped repository (cf. Footnote 1) to publish type definitions corresponding to untyped Javascript packages.

In registries based on a shared repository of manifest files, it is technically easy to change the source of a package when publishing an update. The question of whether it gets accepted will depend on the registry's policy. For instance, MELPA's policy [START_REF]Contributing a new recipe to MELPA[END_REF] says that forks will not be accepted except in "extreme circumstances".

Early archives where sources (and sometimes even bug trackers) are located on the platform make it technically even easier to change the maintainer of a package: CTAN, CPAN, CRAN and PEAR all have documentation regarding unmaintained / orphaned packages. CTAN specifies that modifications to a package should come from the package author or maintainer, new maintainers can be accredited by the current maintainer, but leaves the door open to discussing a solution when a package is unmaintained and the author is unresponsive [START_REF]How can I take authorship of a package?[END_REF]. CPAN administrators can transfer maintenance of a package to a new volunteer after sufficiently many steps have been taken to reach the previous maintainer and advertise the intent to take over the package [START_REF] Hietaniemi | CPAN Frequently Asked Questions[END_REF]. CRAN has a formal orphaning process, after which volunteers can request to become the new maintainers [START_REF]CRAN repository maintainers[END_REF]. For non-orphaned packages, transfer requires written agreement of the previous maintainer. PEAR packages can be marked as unmaintained, and may then be transferred to a new lead maintainer [START_REF]Taking over an unmaintained package[END_REF].

In general, there is a trust issue associated to allowing a change of maintainer for a package (as this means that someone can update a dependency to a new version without realizing the change of ownership), but this pertains to a much more general trust question in code reuse and package ecosystems. Because of this issue, npm is even considering restricting the rules for voluntary transfers [START_REF] Baldwin | The security risks of changing package owners[END_REF].

We can see that forking, while often the best solution for the user community, puts a very large cost on the new maintainer when they do things right and try to organize the community around the new fork. And when forks are created but not properly advertised, it can only lead to duplication of effort. In the next section, I present a solution that alleviates the cost of forking.

ECOSYSTEM-LEVEL SOLUTIONS 4.1 Community forks to increase sustainability

While hard forks are a possible solution to the problem of unmaintained packages, we have seen that this solution puts a significant cost on the new maintainer. It can also put a significant cost on the user community when the package registry does not make it easy to switch the maintainer of a package, because a possibly large number of users will need to learn about the hard fork, evaluate if it is likely to be viable, and update their dependencies.

The transition period, which starts when people become aware that the previous maintainer has disappeared and only ends when the user community has massively adopted a hard fork, is a time during which it is likely that efforts are duplicated, potential contributions as pull requests or bug reports are wasted because they are being ignored or users stop submitting them, the package user base stops growing, or even shrinks, as people look for alternatives to migrate to, or even start their own from scratch, etc. This cost can be deemed too high, especially if the hard fork itself also has a single maintainer, and thus risks suffering from the same issues a few years later. It is natural that the user community can anticipate this and will be reluctant to move massively to a hard fork that does not take steps to prevent this scenario to repeat.

A preventive measure would typically be the creation of a community fork. When a package raises sufficient interest and enough people are motivated to keep maintaining it together, they can host the new repository in a dedicated GitHub organization instead of a personal account and ensure that, at any time, there will be several administrators of this organization and several persons with credentials to publish a new version of the package.

However, most popular single-maintainer packages are likely to be too small for such a community fork to happen. To facilitate the creation of community forks, a possible model is to host them in a community organization dedicated to the long-term maintenance of important packages. This is the model that I present now.

A model of community organizations

In this model, a single informal organization is created (typically as an organizational account on GitHub) to host community forks in a specific ecosystem (typically around a programming language or framework). A place is dedicated to discussing organizational aspects of the community and to proposing new packages for inclusion (for instance the issue tracker of a meta-repository). The criteria for accepting a package may vary, but generally include having at least one person who volunteers to maintain the package.

Maintenance may actually be a community effort, but the advantage of having a designated maintainer for a package is to avoid diluting responsibility. However, volunteering to be the principal maintainer of a package is not a long-term commitment. The point of hosting packages within a community organization is that the maintenance responsibility can easily be transferred if a maintainer wants to step down or becomes unresponsive, as long as there are responsive organization owners and a new volunteer maintainer.

Such community organizations can also facilitate collaboration and encourage maintainers to share best practices. If all maintainers are given commit access to all projects, one can easily help with another package while its own maintainer is temporarily unavailable.

Hosting hard forks in such community organizations is likely to be a factor that will help users adopt them faster, as it guarantees against the risks associated with a new single-maintainer package.

Finally, the existence of such community organizations provides an exit strategy for authors of popular packages that would like to step down from maintaining them. They can submit their package for inclusion and transfer them to the community if accepted. Again, inclusion criteria may vary depending on the specific organization.

The case of elm-community

One early instance of this model is elm-community (https://github. com/elm-community), which was founded in November 2015. On July 5 th , 2019, I interviewed Ryan Rempel, the founder of the organization, who explained to me how this organization came about.

The Elm package ecosystem had already got a culture of package forking and updating every time a new version of the Elm language was published and some original package authors failed to react. This was made easier by the fact that all package names are scoped in the Elm package registry. Consequently, the source package does not have a special status compared to its forks.

However, some impure Elm packages (containing what people used to call native code and now call kernel code [START_REF] Czaplicki | Native Code[END_REF], i.e., JavaScript) had to go through a formal "blessing" (whitelisting) process to be published in the Elm package registry. For such packages, forking and updating could not be done so casually, because it would additionally require going through this formal approval process. This specific issue was discussed on the Elm users' mailing list 6 after the author of a widely used package, containing native code, had been unresponsive for two months. During that time, a pull request with a trivial patch required to upgrade the package to the new version of the language (Elm 0.16) had been left unanswered.

Max Goldstein, an active community member who is now part of Elm's core team, suggested the creation of an "elm-community" GitHub organization "to steward the most important non-official packages". Ryan Rempel, another active community member and the author of the unmerged pull request, jumped on the idea, created the organization, forked the package, and submitted a whitelisting request for it, on the same day. Two days later, he created a metarepository named "Manifesto" in which he described the purpose of the organization in a README and whose issue tracker served to host organizational discussions and package adoption requests.

Ryan told me that the reason he had reacted so quickly after the idea was first proposed was because he had viewed this as an opportunity to foster a new form of collaboration, that would be less disciplined and less centrally controlled than what was common in the Elm community. Indeed, he told me, the Elm community is unusually disciplined for an open source community, around a core team that has very specific ideas about what kind of participation is welcome. All his previous attempts to advocate a more open community had failed, and left him tired. So in this case, he started the community organization without really leaving any time to anyone to discuss the idea, invited five or six people from the beginning, and it turned out to be successful pretty quickly.

Shortly after, it gained some repositories that made more sense to develop collaboratively, e.g., a series of standard library extensions. 7The creation of a Manifesto repository was initially meant as a way of explaining the philosophy of the project, but also to allow issues to be used for organizational questions. The word "Manifesto" was slightly political, but the text of the README avoided any provocative content. According to Ryan, the text was rather abstract at the beginning, and others helped make it more concrete over time. The governance, in particular, remained voluntarily informal.

The idea to have a principal maintainer for each repository to avoid dilution of responsibility (which leads to issues and pull requests being left unanswered) was introduced about six months later by a member of the organization. 8 This change made explicit the rule that issues and pull requests are normally handled by the repository's principal maintainer, but in case of unresponsiveness, any other member can step in, and in case of long-term unresponsiveness, the maintainer is changed.

An emerging model

Elm-community is not the only, nor the first, instance of this model.

Vox Pupuli (https://voxpupuli.org) was founded in September 2014 to maintain Puppet modules (initially under the name of puppetcommunity) and currently hosts over 176 repositories and 139 collaborators. They have precise migration documentation [START_REF]Migrating a module to Vox Pupuli[END_REF] which clearly states a preference for repository transfer, but supports hard forks when package authors are completely unresponsive. They have also made efforts in recent years to promote their model so that other communities can inspire from it to create their own [START_REF] Galić | Building Puppet's unofficial forge community[END_REF][START_REF] Hollinger | Vox Pupuli -The Importance of Working Together[END_REF].

Sous Chefs (https://sous-chefs.org/) was founded in May 2015 9 to maintain Chefs "cookbooks" (initially under the name of the Chef Brigade) and had a meta-repository from the start. 10 They also have a clearly documented forking and transfer policy [START_REF] Webb | Forking to Sous Chefs[END_REF][START_REF] Webb | Transferring to Sous Chefs[END_REF]. In particular, their forking policy states that hard forks are republished to the package registry under the original name with a "sc-" prefix.

Both organizations are pretty open to any repository transfer from members of the organization.

DLang-community (https://github.com/dlang-community), founded in December 2016, has stricter inclusion criteria than Vox Pupuli or Sous Chefs: packages are not transferred or created in the organization without it being discussed with other members, and the package being important to the community.

The following are direct or indirect elm-community descendants:

• ReasonML-community (https://github.com/reasonml-community) was founded in January 2017 under the name Buckletypes (inspired by the DefinitelyTyped repository, cf. Footnote 1). It was renamed in July 2017, and got a meta-repository influenced by elm-community in January 2018. 11 However, it has failed to get clear adoption guidelines, its meta-repository is almost unused, and it has recently taken almost a full year to host a fork of the very popular graphql_ppx package after its author had stopped responding. • Coq-community (https://github.com/coq-community), founded in July 2018, was directly influenced by elm-community. • OCaml-community (https://github.com/ocaml-community), founded in August 2018, was influenced by coq-community and elm-community. Similarly to DLang-community, it only accepts popular OCaml packages. 8 Cf. https://github.com/elm-community/Manifesto/issues/16 9 Cf. http://lists.opscode.com/sympa/arc/chef/2015-05/msg00091.html 10 The first issue (https://github.com/sous-chefs/meta/issues/1) and the first commit (efb426f) were created three days after the initial mailing list announcement. 11 See https://github.com/glennsl/reasonml-community-meta-proposal and https:// github.com/reasonml-community/meta/issues/1.

• React-native-community (https://github.com/react-nativecommunity) was founded in July 2016, but got a "renaissance" period starting in December 2018 that was influenced by OCaml-community. 12 Some organizations are similarly structured and intend to ease package maintenance after their maintainer has left or lost interest but do not explicitly support hard forks. Examples include the F# Community Incubation space (https://github.com/fsprojects/ FsProjectsAdmin), Electron Userland (https://github.com/electronuserland), the Elytra group (https://github.com/elytra) which does not have a meta-repository or general guidelines, but does list the maintainers of each repository in their description, and advertise when a module is looking for a new maintainer. The Fluent Plugins Nursery (https://github.com/fluent-plugins-nursery) is explicitly intended for plugins that are not maintained by their original author but also states "we don't want to fork original authors' ".

Identifying community organizations. In the following, I present a process I used to discover such organizations (cf. the second companion Jupyter notebook [START_REF] Zimmermann | Automatic discovery of community organizations for long-term package maintenance[END_REF]).

First, I listed 75 keywords that could be expected to appear in the name or the description of such organizations. This included keywords expressing collaborative work such as "collective", "maintain", "participate", but also keywords expressing what is being worked on such as "library", "module", "package".

I used GitHub's search, via the GraphQL API [START_REF]GitHub GraphQL API v4, GitHub Developer Guide[END_REF], to query for organizations which matched one of these keywords, and which had at least 5 repositories. GitHub's search only gives access to 1000 results, so when the number of results was above this limit, I further split the search using language filters. This first step yielded over 30,000 organizations (this is close to 15% of all GitHub organizations with at least 5 repositories).

The second step consisted in applying some filters on the results. Since I was only interested in community organizations, I filtered out the ones that had less than 10 public members and less than 10 assignable users on the most starred repository (as a way of estimating the number of collaborators for organizations with mostly private members). Since I was interested in organizations maintaining important packages, I also filtered out the ones whose most popular repository had less than 10 stars.

The third step was intended to further reduce the list to organizations that have received repository transfers. Unfortunately, GitHub does not give access to this information. I used a trick which consists in comparing the creation date of the organization to the creation date of its repositories. If an organization contains repositories that predate its creation, they have necessarily been transferred. Obviously, the converse is not true, so it could have resulted in underestimating the number of transferred repositories.

I manually browsed the resulting table of 938 organizations with at least two such transferred repositories. I used the name and description of the organization to infer its purpose. I eliminated many organizations whose description was something like "community packages for X" when the organization's website was actually the website of X. Indeed, this case is too frequent, and the reuse of the main product's website is a good indicator of the absence of a website or meta-repository specific to the community organization.

When an organization seemed to correspond to the type I was searching, I opened its website or GitHub page and looked for more information about it. It was frequent to find organizations with many repositories but no information on its principles and whether it accepted new members or new projects.

I am well aware that applying this series of filters is very likely to have resulted in missing out organizations that still fit the model I presented in Section 4.2. Nevertheless, the number of examples that I found, and the absence of relationship between many of them (in particular, between elm-community and the two organizations that predate it) leads me to think that this model of organization is naturally emerging in open source package ecosystems in answer to the recurring problem of single-maintainer libraries that I presented in Section 2. The fact that such organizations frequently got inspiration from one another shows that, while the need for such an organization is natural, the exact way of structuring it is not. Therefore, this contribution is important because, by surveying existing instances, we can bring useful information to practitioners wondering about the opportunity of founding such organizations, and how to structure them.

How does it compare to earlier models?

The idea of shared infrastructure to develop several projects together is not new. For instance, PEAR [START_REF] Pear Group | PEAR: PHP Extension and Application Repository[END_REF] was PHP's first package registry, but it was also much more. Packages had to go through a formal submission process to get accepted. Once they were, they got a repository and bug tracker. Finally, when a package was left unmaintained by its author, a new maintainer could be appointed [START_REF]Taking over an unmaintained package[END_REF].

However, there was an important difference in the motivations of authors applying to get their packages accepted into PEAR compared to authors, or interested users, proposing a package to a community organization today. As PEAR was PHP's only package manager and registry at the time (until support for alternative registries was introduced, starting in 2005 13 ), authors submitted their packages to get it distributed, rather than for the shared maintenance model. For some maintainers, the model and infrastructure were convenient, but others preferred to host their projects elsewhere. Another well-known example is the Apache Foundation, which hosts many open source projects and provides shared processes and infrastructure. The main difference with the model of community organization presented in this paper is that the Apache Foundation only accepts larger projects (all the projects have several maintainers and their own mailing lists [START_REF]How it works[END_REF]). The Apache Foundation model is therefore not suited to solve the issue of single-maintainer packages, and does not support hard forking (despite the Apache web server being itself a community fork of an unmaintained project).

Open issues, future work

I have presented a model of community organization for the collaborative, long-term maintenance of an ecosystem's packages, and 13 Cf. http://php-pear.1086190.n5.nabble.com/Questions-about-PEAR-amp-Composer-td36854.html.

I have identified numerous instances of this model. However, the method I used to find these examples is not exhaustive.

The use of GitHub's search to list possible candidates is good for exploratory work, but cannot be used beyond that: I have observed that the results obtained are very unstable when trying to fetch them again, and I have also found a number of bugs in GitHub's search filters. According to GitHub staff, this is because the search index is sometimes out of date.

Finding more examples will require coming up with more precise criteria to detect automatically this kind of organizations, probably starting from the complete list of about 2,000,000 GitHub organizations. Then, we could try to identify which characteristics of an ecosystem favor the emergence of such organizations.

Given that this is an emerging model, each instance is unique and it would be useful to come up with a number of parameters that can be used to describe them. Interviewing founders and participants would be helpful in that regard. Then, the next step would be to identify which of these parameters are associated with successful community organizations. For instance, it would seem that documenting the adoption process is helpful to ensure that people know what to do when a useful package in the ecosystem has been abandoned and would be a candidate for adoption, whereas the absence of such guidelines can lead to a lack of reactivity and duplication of effort with multiple people starting forks (as happened with the graphql_ppx library in the ReasonML ecosystem).

Finally, it seems important to systematically assess the impact of such community organizations on an ecosystem and, in particular, on the packages that get transferred or forked in the organization. For instance, Zhou et al. [START_REF] Zhou | What the fork: a study of inefficient and efficient forking practices in social coding[END_REF] studied inefficiencies in fork-based development, such as duplication of work or community fragmentation. We could try to evaluate whether the presence of a community organization helps reduce these inefficiencies, and under which conditions. This would provide concrete incentives to practitioners to create more instances of this model.

CONCLUSION

Modern and attractive package ecosystems are made of a multitude of small and large open source libraries. When a popular package is depended upon by many projects but has only a single maintainer, it creates a risk of the maintainer suddenly becoming unresponsive and the package not being updated anymore. I have shown that a large proportion of popular packages are single-maintainer packages and I have presented some mitigation paths that users of these packages can follow in such situations of unresponsiveness. Among them, the creation of a friendly fork is often the best for the community, but it can be costly to start a fork, and it does not help very much if the new fork is also a single-maintainer package. This is why users can create community organizations for the collaborative, long-term maintenance of an ecosystem's packages. Such organizations can reduce the cost of forking, while creating better guarantees for the future of the fork. I have shown that this model of community organizations has emerged in a number of package ecosystems and, as a first step toward a more systematic analysis, I have presented the case of elm-community in greater details.

3. 3 . 1

 31 Definition. Forking has a broad meaning today in open source.

DefinitelyTyped is a community repository gathering TypeScript type definitions for otherwise untyped Javascript packages: http://definitelytyped.org/.

For privacy reasons, GitHub does not share the list of collaborators or people with write-access on a repository, but it does share the list of assignable users nonetheless.

Cf. https://web.archive.org/web/20100609115535/http://sourceforge.net/apps/trac/ sourceforge/wiki/Abandoned%20Project%20Takeovers

As I was told in a private mail by a member of GitHub staff.

As recommended in this Open Source Stack Exchange answer about npm: https: //opensource.stackexchange.com/a/7025/5858

Cf. https://groups.google.com/forum/#!topic/elm-discuss/-GQJkWGdMvg/discussion

Cf. https://groups.google.com/forum/#!topic/elm-discuss/wJPvZUql6v0/discussion


Simon Cornée
email: simon.cornee@univ-rennes1.fr

How Costly is Social Screening? Evidence from the Banking Industry

Social banks screen loan applicants by using both social and financial criteria, and social screening implies an extra workload. To check the costs involved in this type of screening we use balance-sheet information on European banks, and compare the operating costs of social banks with those of other banks. Surprisingly, our first results suggest that social banks' costs are not significantly higher than those of their mainstream counterparts. Next, we uncover that the extra costs of social screening are offset by a cheaper workforce. Despite their need for specific screening, social banks are financially sustainable in a market dominated by for-profit institutions.

Introduction

Nonprofit and hybrid organizations are accountable to their stakeholders [START_REF] Tacon | Accountability in Nonprofit Governance: A Process-Based Study[END_REF].

They need to demonstrate that they efficiently spend the funds earmarked for carrying out their social mission, which could be jeopardized by high costs [START_REF] Reichert | A Meta-Analysis Examining the Nature of Trade-Offs in Microfinance[END_REF]). Yet, little is known about the costs of assessing the social orientation of projects. This paper addresses the issue through the lens of social banks, which carry out social screening of loan applications [START_REF] Cornée | The Relevance of Soft Information for Predicting Small Business Credit Default: Evidence from a Social Bank[END_REF]Szafarz 2014, Cornée et al. 2018). Using balance-sheet information, we compare the operating costs of social banks with those of their mainstream counterparts.

Social banks-sometimes called "ethical" or "alternative" banks-are value-based financial intermediaries that prioritize social goals over financial returns, and fund community-oriented projects and social enterprises. 1 They signal their social commitment in three ways. First, they keep their operations as transparent as possible by favoring direct intermediation and refraining from sophisticated speculative transactions [START_REF] Cornée | Selectivity and Transparency in Social Banking: Evidence from Europe[END_REF]. Second, they operate under rules of stakeholder governance [START_REF] Becchetti | Credit Rationing and Credit View: Empirical Evidence from Loan Data[END_REF][START_REF] San-Jose | Are Ethical Banks Different? A Comparative Analysis Using the Radical Affinity Index[END_REF]. Third, they assess the social orientation of loan applications by conducting specific screening, which implies the time-consuming task of gathering "soft information" about applicants, their values and business practices [START_REF] Willis | The Role of the Global Reporting Initiative's Sustainability Reporting Guidelines in the Social Screening of Investments[END_REF].

Since social banks conduct dual screening of social and financial characteristics, their operating costs could be expected to exceed those of mainstream banks, which screen borrowers solely on a financial basis. Yet, social banks themselves are social enterprises whose value-laden orientation can attract a cheaper and better motivated workforce [START_REF] Mason | Putting Charity to the Test: A Case for Field Experiments on Giving Time and Money in the Nonprofit Sector[END_REF]. As [START_REF] Ellingsen | Paying Respect[END_REF] put it: "idealistic workers appreciate the respect of an idealistic employer" (p. 135). Evidence indicates that nonprofits pay below-market wages to their employees, who tend to value non-monetary (or "warm glow") compensation [START_REF] Andreoni | Impure Altruism and Donations to Public Goods: A Theory of Warm-Glow Giving[END_REF][START_REF] Benz | Not for the Profit, but for the Satisfaction? Evidence on Worker Well-Being in Non-Profit Firms[END_REF]). In the extreme case, volunteers work for a zero wage because they are motivated by the organization's social orientation [START_REF] Menchik | Volunteer Labor Supply[END_REF][START_REF] Freeman | Working for Nothing: The Supply of Volunteer Labor[END_REF][START_REF] Meier | Is Volunteering Rewarding in Itself?[END_REF]). 2 This, in turn, would make these institutions' operations more cost-efficient than those of mainstream banks. Our paper assesses the resulting trade-off between the extra cost due to social screening and the wage reduction associated with staff motivation.

Data and Methods

Based on the Bankscope database provided by Bureau van Dijk, our sample is made up of the unconsolidated balance-sheet information of 5,448 banks located in Western European countries where social banks are active, over the 1998-2013 period. 3 As screening costs cannot be isolated from other operating costs, we use two proxies: the cost-to-income ratio (CIR, operating costs to operating income) and overhead (operating costs to total assets). Both are standard indicators for cost efficiency in banking analysis [START_REF] Weill | Measuring Cost Efficiency in European Banking: A Comparison of Frontier Techniques[END_REF][START_REF] Beck | Islamic vs. Conventional Banking: Business Model, Efficiency and Stability[END_REF]. We interpret higher values of any of these proxies in social banks as evidence of costly social screening. To check whether lending in social banks is more labor-intensive, we use two labor-1 Albeit niche institutions, social banks have grown considerably in the last two decades, especially in Europe [START_REF] Benedikter | Social Banking and Social Finance[END_REF]. They make a difference in the banking sector [START_REF] Barigozzi | Credit Markets with Ethical Banks and Motivated Borrowers[END_REF].

2 [START_REF] Lovera | Debts, Differently: Alternative Finance Organizations in Italy and France[END_REF] shows that social banks do indeed attract volunteers. In a lab experiment setting, [START_REF] Cornée | Credit Relationships: Evidence from Experiments with Real Bankers[END_REF] show that social bankers exhibit stronger social preferences than do their mainstream counterparts.

3 Our sample comprises 11 European countries: Denmark, France, Germany, Great Britain, Italy, Malta, Norway, Spain, Sweden, and Switzerland (see also [START_REF] Cornée | Selectivity and Transparency in Social Banking: Evidence from Europe[END_REF].

related cost measures: number of employees and personnel expenses, both scaled by total assets. Higher values for both metrics in social banks relative to other banks would indicate that social screening necessitates more staff and incurs higher personnel expenses. However, the equivalence of more staff and higher personnel expenses across two groups of banks holds only if wage costs are similar. For this reason, we also scrutinize the wage differential between social and conventional banks. Our regression analysis replicates the empirical strategy used by [START_REF] Beck | Islamic vs. Conventional Banking: Business Model, Efficiency and Stability[END_REF] to compare the cost performance of Islamic and conventional banks. We estimate four cost-related models with the following structure:

= + + + + + + , (1)
where is the value taken by our cost-related dependent variable for bank i in country j in year t. Our independent variable of interest is a dummy variable: takes value 1 if bank i is social, and 0 otherwise. The control variables in vector X are chosen in line with the banking literature. They include an array of time-variant bank characteristics that could muddy the relationship between bank type (social or not) and screening costs. First, we account for the ownership structure using a dummy variable for stakeholder banks-i.e. cooperative and savings banks. The empirical literature points out that stakeholder banks are often more costefficient than shareholder banks [START_REF] Altunbas | Bank Ownership and Efficiency[END_REF][START_REF] Ferri | Organizational Structure and Performance in European Banks: A Reassessment[END_REF]. 4 Second, we use the log of assets to control for bank size. The theoretical literature suggests that scale economies are easier to achieve in larger banks, while the empirical literature is mixed on this issue [START_REF] Bertay | Do We Need Big Banks? Evidence on Performance, Strategy and Market Discipline[END_REF]. Third, the bank's business orientation is captured by its asset composition, proxied by the loan-to-asset ratio (in short, Loans). Previous research shows that a business orientation affects bank performance [START_REF] Claessens | How Does Foreign Entry Affect Domestic Banking Markets?[END_REF][START_REF] Demirgüç-Kunt | Bank Activity and Funding Strategies[END_REF]. Last, the ratio of fixed-to-total assets controls for the opportunity costs associated with non-earning assets [START_REF] Bertay | Do We Need Big Banks? Evidence on Performance, Strategy and Market Discipline[END_REF]. Eq. ( 1) comprises country-fixed effects C, year-fixed effects Y, as well as macroeconomic characteristics M, namely the Herfindahl-Hirschman market concentration index (HHI), the inflation rate, the overnight interbank interest rate, and GDP growth rate.

Table 2 reports summary statistics for social banks and conventional banks separately. 5 The values taken by CIR are similar for social banks and conventional banks but, surprisingly, ttests for equal means show that three cost-related indicators (Overhead, Employees to assets, and Personnel expenses to assets) exhibit lower values for social banks. The regression analysis will reveal whether controlling for bank characteristics and macro conditions affects these exploratory outcomes. The relevance of unconsolidated data for comparability purposes is attested by similar means of total assets (in log) obtained for the two groups of banks. Meanwhile, significant differences in means confirm the need to include the other controls in the regressions.

Regression Results

Table 3 examines whether social banks, which undertake dual screening, have higher costs than other banks. In line with the descriptive statistics, the regressions explaining the cost-to-income ratio, and featured in columns (1)-(3), fail to deliver significant coefficients for the social-bank dummy. By contrast, the coefficient of the stakeholder-bank dummy is significant, confirming that cooperative and savings banks have lower costs [START_REF] Weill | Measuring Cost Efficiency in European Banking: A Comparison of Frontier Techniques[END_REF]. Table 2 reports that there are proportionally more stakeholder banks among non-social banks than among social ones,6 which rules out the possibility that our regression results are distorted by overlap between stakeholder banks and social banks. Likewise, the overhead regressions in columns ( 4)-( 6) detect no extra costs associated with social screening. In all the estimations, the loadings of the controls are in line with those found by [START_REF] Beck | Islamic vs. Conventional Banking: Business Model, Efficiency and Stability[END_REF], which adds relevance to our empirical design. Overall, Table 3 suggests that social screening is neutral from an operating cost standpoint. If so, how do social banks manage to run dual screening at no extra cost? Table 4 addresses this question by scrutinizing labor costs, since personnel expenses represent the lion's share of operating costs in banking Table 4 reports the outcomes of regressions explaining Employees to assets and Personnel expenses to assets columns (1)-( 3) and ( 4)-( 6), respectively. The left side shows that the number of employees per asset unit is not significantly different in social banks and other banks, which is puzzling since social banks rely on relational, labor-intensive technologies [START_REF] Cornée | The Relevance of Soft Information for Predicting Small Business Credit Default: Evidence from a Social Bank[END_REF]. Activity-specific workloads help rationalize the findings. Social banks have fewer intermediation activities on the lending side of the balance sheet (proxied by Loans in Table 4), and intermediation activities are typically more labor-intensive than market activities and investment [START_REF] De Young | Borrower-Lender Distance, Credit Scoring, and Loan Performance: Evidence from Informational-Opaque Small Business Borrowers[END_REF]. The non-intermediation activities of social banks are also purposefully simple and transparent, in line with their foundational principles [START_REF] Cornée | Selectivity and Transparency in Social Banking: Evidence from Europe[END_REF]. The right-hand side of Table 4 reveals that personnel expenses are significantly lower for social banks than for conventional banks, thereby suggesting that the former's workforce is paid less than the latter's. Altogether, Table 4 solves the apparent puzzle of costless social screening. The rationale would be that the extra costs of dual screening are offset by a cheaper workforce.7 Social banks apparently take advantage of intrinsically motivated personnel, who accept lower wages in exchange for working in a social enterprise. The results suggest that despite laborintensive dual screening stemming from their mission, social banks' operating costs are comparable to those of their non-social counterparts.8 Our findings are in line with those of [START_REF] Borzaga | Worker Motivations, Job Satisfaction, and Loyalty in Public and Nonprofit Social Services[END_REF], who show that nonprofit banks pay lower wages than for-profit ones, possibly because of non-pecuniary compensation and higher satisfaction.

Conclusion

Our findings suggest that social banks manage to assess the social contribution of the projects presented by loan applicants without significantly adding to their costs. Since social screening is expensive, some compensation is required. Our regression results are consistent with the presence of volunteers and workers who accept below-market wages for working with sociallyoriented institutions. They also suggest that the cost of screening depends on its institutional context.

While social banking is still a niche in financial intermediation, it elucidates the mechanisms underlying the sustainability of pro-social organizations faced with capitalistic competition in their business sector. In one way or another, pursuing a social mission can harm financial performance by requiring additional screening for the sake of accountability to stakeholders. The additional burden materializes as a screening cost that could jeopardize the survival of the organization. This paper shows that the extra cost is offset by the altruistic behavior of the workforce. Arguably, non-pecuniary compensation, such as the "warm glow", could ultimately make companies that perform social screening as cost-efficient as purely commercial firms. However, further work is needed to assess this hypothesis in non-financial industries.

Social banks are hybrid organizations. Their business model combines sacrifices from stakeholders, such as owners and depositors, with soft loans to fund socially-oriented projects. This paper underlines that, on top of the financial sacrifices made by funders, social banks also benefit from labor donations, which may be total, as in volunteering, or partial, as in working for below-market wages. In sum, even if this latter factor is hardly visible at first sight, social banks evolve like other nonprofits and hybrid organizations: they fund the accomplishment of their social mission by means of donations in both the capital factor and the labor factor.

Table 1 : Definition of Variables

 1

		DEPENDENT VARIABLES
		Cost efficiency measures
	CIR (%)	Cost-to-income ratio (=operating costs / operating income)
	Overhead (%)	Operating costs / total assets
		Labor-related cost measures
	Employees to assets	Number of employees / total assets
	Personnel expenses to assets	Personnel expenses / total assets
		INDEPENDENT VARIABLES
		Bank-specific variables
	Social bank	Dummy=1 if the bank is a social bank
	Stakeholder bank	Dummy=1 if the bank is a cooperative or savings bank
	Bank size	Log of assets
	Loans (%)
		Macroeconomic variables
	HHI	Herfindahl-Hirschman index for assets
	Interbank rate (%)	Overnight interbank rate
	Inflation (%)	Inflation rate
	GDP growth (%)	Growth rate of gross domestic product

Asset composition: Loans / total assets Fixed assets (%)

Opportunity cost for non-earning assets: Fixed assets / total assets

Table 2 : Summary Statistics

 2

	Variables	Social banks (SBs)	Conventional banks (CBs) T-test for equal
				means
	CIR (%)	69.53 (18.11), [N=283]	68.35 (13.29), [N=45,669]	-1.47
	Overhead	1.96 (1.23), [N=233]	2.34 (1.22), [N=40,291]	4.79***
	Employees to assets	0.17 (0.10), [N=248]	0.23 (0.11), [N=38,026]	8.23***
	Personnel expenses to assets	10.71 (5.88), [N=269]	13.40 (6.47), [N=45,098]	6.80***
	Stakeholder bank	0.61 (0.48), [N=457]	0.75 (0.72), [N=86,172]	7.01***
	Bank size	6.15 (5.93) [N=307]	6.38 (1.178), [N=56,612]	2.20**
	Loans (%)	54.48 (21.40), [N=296]	61.15 (19.64), [N=47,307]	5.81***
	Fixed assets (%)	1.04 (0.90), [N=268]	1.33 (0.86), [N=46,033]	5.34***
	HHI	0.17 (0.10), [N=457]	0.12 (0.10), [N=86,172]	-11.33***
	Interbank rate (%)	2.40 (1.75), [N=457]	2.17 (1.58), [N=86,172]	-3.01**
	Inflation (%)	1.89 (0.92), [N=457]	1.64 (0.85), [N=86,172]	-6.15***
	GDP growth (%)	1.48 (2.19), [N=457]	1.34 (2.20), [N=86,172]	-1.30
	Note: Standard errors are in parentheses. Number N of point-observations is in brackets. ***: p<0.01, **: p<0.05,
	*: p<0.1.

Table 3 : Operating Cost Regressions

 3

	VARIABLES		CIR			Overhead
		(1)	(2)	(3)	(4)	(5)	(6)
	Social bank	3.92	3.56	3.46	-0.27	-0.38	-0.38
		(2.963)	(2.891)	(2.912)	(0.220)	(0.271)	(0.270)
	Stakeholder bank		-2.31***	-2.42***		-1.00***	-1.00***
			(0.617)	(0.620)		(0.071)	(0.071)
	Bank size		-1.32***	-1.35***		-0.23***	-0.22***
			(0.102)	(0.103)		(0.010)	(0.010)
	Loans		-0.08***	-0.08***		-0.01***	-0.01***
			(0.011)	(0.011)		(0.001)	(0.001)
	Fixed assets		3.12***	3.09***		0.30***	0.30***
			(0.165)	(0.164)		(0.020)	(0.020)
	Constant	55.47*** 57.88***	61.52***	1.36***	3.12***	3.15***
		(3.588)	(4.805)	(5.224)	(0.155)	(0.339)	(0.382)
	Year dummies	Yes	Yes	Yes	Yes	Yes	Yes
	Country dummies	Yes	Yes	Yes	Yes	Yes	Yes
	Macro variables a	No	No	Yes	No	No	Yes
	Observations	45,952	44,803	44,803	40,524	39,547	39,547
	R-squared	0.07	0.15	0.16	0.08	0.32	0.32
	Adj. R-squared	0.07	0.15	0.16	0.08	0.32	0.32
	*** p<0.01, ** p<0.05, * p<0.1. Standard errors (in parentheses) are heteroscedasticity and cluster robust.

a

The macro variables include: HHI, interbank rate, inflation, and GDP growth.

Table 4 : Labor-Related Cost Regressions

 4 Standard errors (in parentheses) are heteroscedasticity and cluster robust. a The macro variables include: HHI, interbank rate, inflation, and GDP growth.

	VARIABLES		Employees to assets	Personnel expenses to assets
		(1)	(2)	(3)	(4)	(5)	(6)
	Social bank	-0.02	-0.03	-0.03	-2.06*	-2.78**	-2.76**
		(0.020)	(0.018)	(0.018)	(1.056)	(1.368)	(1.364)
	Stakeholder bank		-0.02***	-0.01***		-4.82***	-4.79***
			(0.005)	(0.005)		(0.364)	(0.364)
	Bank size		-0.02***	-0.02***		-1.28***	-1.27***
			(0.001)	(0.001)		(0.050)	(0.050)
	Loans		-0.0003*** -0.0002***		-0.04***	-0.04***
			(0.0001)	(0.0001)		(0.006)	(0.006)
	Fixed assets		0.03***	0.03***		1.65***	1.65***
			(0.002)	(0.002)		(0.102)	(0.102)
	Constant	0.13***	0.38***	0.36***	7.78***	16.65***	14.26***
		(0.013)	(0.055)	(0.055)	(0.860)	(0.824)	(1.070)
	Year dummies	Yes	Yes	Yes	Yes	Yes	Yes
	Country dummies	Yes	Yes	Yes	Yes	Yes	Yes
	Macro variables a	No	No	Yes	No	No	Yes
	Observations	38,274	37,519	37,519	45,367	44,444	44,444
	R-squared	0.34	0.51	0.51	0.11	0.33	0.33
	Adj. R-squared	0.34	0.51	0.51	0.11	0.33	0.33
	*** p<0.01, ** p<0.05, * p<0.1.

Beyond cost efficiency, the distinctive features of stakeholder banks include: relying on basic, relationship-based intermediation, restricted trading of shares, and other objectives besides profit maximization[START_REF] Iannotta | Ownership Structure, Risk and Performance in the European Banking Industry[END_REF][START_REF] Ferri | Does Bank Ownership Affect Lending Behavior? Evidence from the Euro Area[END_REF].

To prevent our results from being contaminated by outliers, we drop the 1 st and 99 th percentiles for all variables except Bank size and the macroeconomic variables[START_REF] Ferri | Does Bank Ownership Affect Lending Behavior? Evidence from the Euro Area[END_REF].

Using unconsolidated data magnifies the number of stakeholder banks among conventional banks[START_REF] Cornée | The Business Model of Social Banks[END_REF], since many cooperative banks are structured as networks of small and legally separate entities.

The evidence is further assessed in Appendix A.

Stakeholder banks take also advantage of motivated personnel, but they do not carry out dual screening. It follows that their activity is systematically less costly than that of shareholder banks (see Tables3 and 4).

This work has been supported by the Fondation Rennes 1 Chair of Banking and Finance. The research has also received funding from the Academy of Finland (grant #269130) and OP Research Foundation (recipient Panu Kalmi). The authors thank Tony Bulger for excellent proofreading, as well as Roy Mersland, the participants at the CERMi Seminar, ULB

Appendix A

Table A1 shows that the average wage (total personnel expenses to number of employees) in social banks is lower than in other banks. Columns (1) to (3) replicate the specifications displayed in Tables 3 and4. For robustness, Fixed assets is replaced in specifications ( 4) and ( 5) by the return on assets (ROA), which is more easily interpretable and accounts for the typically positive link between wages and firm performance (Bell and Van Reenen 2012). Like [START_REF] Philippon | Wages and Human Capital in the US Finance Industry: 1909-2006[END_REF], we find that wages depend negatively on the loan-to-asset ratio, as credit granting is less profitable than market-oriented activities. Specifications (4) and ( 5) are consistent with wages being higher in larger banks [START_REF] Brown | The Employer Size-Wage Effect[END_REF].


B G Giraud

B K Jennings
email: jennings@triumf.ca

B R Barrett
email: bbarrett@physics.arizona.edu

Existence of a Density Functional for an Intrinsic State

A generalization of the Hohenberg-Kohn theorem for finite systems proves the existence of a density functional (DF) for a symmetry violating intrinsic state, out of which a physical state with good quantum numbers can be projected.

I. INTRODUCTION

Density functional [1] theory (DFT) was initially defined for ground states. These have good quantum numbers. Every nuclear physicist knows that, for instance, the ground state of 20 Ne is a 0 + and that its density is, thus, isotropic, not an ellipsoid. Every molecular physicist knows that, for instance, the ground state of the ammonia molecule is a good parity state, not just the pyramid described by the Born-Oppenheimer approximation. In particular, the nuclear DF must generate spherical solutions for the some thousand 0 + nuclear ground states, whether nuclei are intrinsically deformed or not. The same need for isotropic solutions extends to the non-local generalization of the DFT [2] -[3]. But the theory of rotational bands and/or parity vibrations, whether in nuclear, atomic or molecular physics, most often relates ground states to wave packets, often named "intrinsic states", which are symmetry breaking, namely do not transform in an irreducible representation (irrep) of the symmetry group S of the Hamiltonian. Therefore, one may raise the question of DFT for intrinsic states rather than eigenstates.

. Energy density and particle density are different concepts.

It turns out that the particle density which has been used for the foundation of DF theory mainly concerns eigenstates of the physical Hamiltonian, in principle at least, while the energy density, used for Skyrme force calculations in nuclear physics for instance, mainly provides intrinsic states. This note presents a particle DF theory for intrinsic states, not for eigenstates of the Hamiltonian. We show how the physical Hamiltonian can be reconciled with the proper definition of a DF for an intrinsic state and how the resulting intrinsic state can be accepted as a useful wave packet, out of which states with good quantum numbers can be projected. In particular, in the case of molecules, our approach will consider both the electrons and the nuclei. Our intrinsic state can take into account both kinds of degrees of freedom. Section II describes a functional out of which a variational principle derives for an intrinsic state, and out of which a DF for the intrinsic density is obtained. Section III gives an example of variational equations to be solved in practice. Section IV rewrites the formalism into a slightly simpler form. Section V contains a discussion of our result and suggests an ansatz for intrinsic Hamiltonians.

II. BASIC FORMALISM

For a first argument, dealing with one kind of identical particles only, let H be their physical Hamiltonian and φ, φ|φ = 1, be a trial wave packet, most often not transforming under an irrep of the symmetry group S of H. For instance, for fermions, φ may be an arbitrary Slater determinant, but we let φ be also a more general wave function, including some amount of correlations. States ψ ∝ P φ with good quantum numbers can then be projected out of φ by a projector P, a fixed operator. In the following, we shall systematically use the properties, P 2 = P and

[P, H] = 0. It may happen that φ|P |φ vanishes, but such cases usually make a domain of zero measure in the usual variational domains, where φ evolves. In any case, since H is an operator bounded from below, the functional of φ, φ|P H|φ / φ|P |φ , is bounded from below. Embed now the system in an external, local field, U = i u(r i ). The local, real potential u is taken bounded from below, but is otherwise arbitrary. In particular, it may usually have none of the symmetries of H. Then, given u, the following functional of φ,

F [φ] = φ|P H|φ φ|P |φ + φ|U |φ , (1)
is bounded from below. To find the lowest energy with the quantum numbers specified by P one can use a constrained search [START_REF] Levy | Proc. Natl. Acad. Sci[END_REF], in which one first considers only states that show a given density profile τ (r), then one lets τ vary,

The process goes in two steps, namely, i) a minimization within a given particle density profile, τ (r) ≡ φ|c † r c r |φ , for N particles, with c † r and c r the usual creation and annihilation operators at position r, then, ii) a minimization with respect to the profile. The inner minimization clearly defines a DF, F [τ ] ≡ Inf φ→τ ( φ|P H|φ / φ|P |φ ) .

Actually, it is more general [START_REF] Lieb | [END_REF] - [13] to use many-body density matrices B in N -body space, meaning mixed as well as pure states, and yielding a density τ (r) in one-body space,

Inf τ Inf B→τ Tr B P H Tr B P + Tr B U , (3)
but we shall use wave-functions in the following, namely B = |φ φ|, for obvious pedagogical reasons. We shall assume that this Inf φ actually defines an absolute minimum, Min φ , reached at some solution Φ of the corresponding variational principle. Moreover, we shall assume, temporarily at least, that the solution Φ is unique. Uniqueness is not obvious, however, if only because many φ's can give the same P |φ , and, when u vanishes, this variational principle, Eq. ( 2), reduces to the well-known "variation after projection" [14] method for Hartree-Fock calculations for instance. Anyhow, τ and u are clearly conjugate in a functional Legendre transform, with δF/δτ = -u. Finally, if ρ(r) denotes the profile of Φ when u → 0, then the lowest energy with good quantum numbers is nothing but F [ρ]. The minimization, with respect to τ, of the functional, F [τ ], provides simultaneously the density of the intrinsic (unprojected!) state and the projected energy. Notice, incidentally, that F [τ ] depends on the choice of the variational set of trial functions φ where the "inner minimization" is performed. Furthermore, it obviously depends on P.

A more general argument is possible, with more than one kind of identical particles. Trial states can be, for instance, products of determinants, one for each kind of fermions, and permanents, one for each kind of bosons. Consider for instance the ammonia molecule, with i) its active electrons, ii) its three protons and iii) its nitrogen ion. It is trivial to include a center-of-mass trap into H to factorize into a spherical wave packet the center of mass motion of this self-bound system and avoid translational degeneracy problems. The complete Hamiltonian H, trial states φ and density operators B depend on and describe simultaneously the electron, proton and nitrogen ion coordinates and momenta. A DF in just the electronic density space, however, results from the definition,

F [τ ] = Inf B→τ Tr B P H Tr B P , (4)
where P projects good quantum numbers for the whole system and traces are taken over all degrees of freedom, while τ is set as only an electronic density. Interactions between heavy degrees of freedom, between heavy and electronic ones, and between electrons, are taken into account by the trace in the numerator. No Born-Oppenheimer approximation is needed for this "global" definition. For the sake of simplicity, however, we return in the following to the case of one kind of particles only. Most considerations which follow have obvious generalization for multicomponent systems.

III. VARIATIONAL EQUATIONS

Let δφ be an infinitesimal variation of the trial function in its allowed domain. (

) 5
If one defines the "gradient operator",

G = P H φ|P |φ + U - P φ|P H|φ ( φ|P |φ ) 2 , (6)
then, obviously, δF = δφ|G|φ + φ|G|δφ . Note, incidentally, that G is Hermitian. At the minimum position Φ, the variation δF vanishes for any δφ. Replace δφ by i δφ to see that the difference, -δφ|G|Φ + Φ|G|δφ , vanishes as well. Then, trivially, at Φ, both δφ|G|Φ and Φ|G|δφ vanish simultaneously, δφ|G|Φ = Φ|G|δφ = 0, ∀ δφ.

In the special case of Slater determinants, let |ph ≡ c † p c h |Φ denote any particle-hole state built upon |Φ as the "reference vacuum" for quasi-particles. Here c † and c are the familiar fermionic creation and annihilation operators, respectively. Then the particle-hole matrix elements of G vanish,

ph| G |Φ = 0, ∀ ph. ( 8
)
As long as a solution of this stationarity condition, Eq. ( 8), is not reached, the matrix elements, ph|G|φ , define the direction of the gradient of F in the hyperplane tangent to the manifold of Slater determinants. A gradient descent algorithm, |δφ = -η ph |ph ph|G|φ , where η is a small step parameter, then leads to the solution. Notice, however, that the ph representation is covariant with φ. ph basis has to be recalculated at each step. Being state dependent, G must also be recalculated at each step.

IV. SIMILAR THEORY, WITH A LAGRANGE MULTIPLIER

The slightly complicated gradient operator, Eq. ( 6), leads to a variational condition, Eq. ( 7), which combines the matrix elements of three operators, namely P H, P and U. Define the number λ = Φ|P H|Φ / Φ|P |Φ as a yet unknown Lagrange multiplier; it can be considered as an arbitrary parameter and shall be adjusted self-consistently later, when Φ is reached. Then Eq. ( 7) also reads,

δφ| ( P H -λ P + Φ|P |Φ U ) |Φ = 0. (9)
If φ were completely unrestricted, namely if δφ were completely general, this equation, Eq. ( 9), would mean that Φ is an eigenstate of the operator G. Since intrinsic states are understood to belong to restricted sets of states, the result Φ is only an approximate eigenstate of G.

To avoid the cumbersome coefficient, Φ|P |Φ , which multiplies U, it is convenient to define the auxiliary operator,

H = P H -λ P + W, (10)
where W = i w(r i ) is, like U, an arbitrary, local, real, external field, bounded from below. It is obvious that G and H define a common solution Φ if u and w are suitably proportional to each other, w = Φ|P |Φ u. In the following, however, we set H ab initio. It is an operator bounded from below. We are interested in its "almost ground state" Ξ and assume that this state is unique. A connection between a solution Ξ in this section and a solution Φ in the previous section can easily be tested later. Define again a constrained search for the lowest energy,

Inf φ φ| H |φ = Inf τ ( Inf φ→τ φ| H |φ ) = Inf τ F λ [τ ] + dr τ (r) w(r) , (11)
where the λ-dependent DF, F λ , is defined as,

F λ [τ ] ≡ Inf φ→τ φ| (P H -λP ) |φ . (12)
It is again convenient, for pedagogy at least, to assume that this Inf φ induces an absolute minimum, reached at a position Ξ in the variational space. The same assumption states that, given λ, the absolute minimum of F λ [τ ] is

F λ [σ] = Ξ|(P H -λP )|Ξ , ( 13
)
where σ is the density of Ξ. Let E denote this energy, E(λ) ≡ Ξ|(P H -λP )|Ξ . A simple manipulation then gives,

dE dλ = -Ξ|P |Ξ . (14)
A Legendre transform, using λ and Ξ|P |Ξ as conjugate variables, is thus available to return the matrix element Ξ|P H|Ξ as a function of the matrix element Ξ|P |Ξ . Then one has just to locate the minimum of their ratio. Note again that the theory depends on the variational space where φ evolves. But, in any case, one obtains simultaneously the density of Ξ, the best intrinsic state, and the energy of its projected state P | Ξ .

V. SUMMARY, DISCUSSION AND CONCLUSION If only because of the need for spin densities [15] in the description of polarizable systems, the problem of symmetry conservation, or restoration, in DF theory has already received much attention in atomic and molecular physics [16] - [19]. It has been revisited here, in the spirit of the projected Hartree-Fock method with variation after projection [14]: a variational principle for the density of an intrinsic state, without symmetry, optimizes the energy of a state with good quantum numbers. The idea was already introduced in the context of particle number projection [20]. We have shown in Secs. II and IV that our approach allows generalizations of the Hohenberg-Kohn existence theorem.

It can be stressed that the present approach is concerned with the density of an intrinsic state, not that of an eigenstate. This is a major difference with all the other DF theories that we are aware of. Note, in particular, how our functional differs from a functional of a symmetrized [16] density .

We showed in Sec. IV that a way to define the intrinsic Hamiltonian amounts to a linear combination, H = -λ P + P H, of the projector P on the desired quantum numbers, and the laboratory Hamiltonian multiplied by that same P. Here, a subtle question must be raised, that of the nature of the intrinsic state. The more flexible the trial functions for this state, the better the projected state and the lower the projected energy. However, full flexibility contradicts simplicity, and, moreover, uniqueness of the intrinsic state; many different packets |φ can give the same P |φ . Symmetry projection brings correlations which, therefore, must be absent from the intrinsic state. This is why variational domains for intrinsic states must necessarily be much narrower than the full Hilbert space.

In practice, fortunately, intrinsic states are confined to non-linear, curved [21] manifolds, such as coherent states, Slater determinants, etc., which do not make linear subspaces. The intrinsic state, therefore, is not an exact eigenstate of H. It just minimizes a related quantity, the projected energy. It must be concluded that DF theory for an intrinsic state necessarily depends on two factors, namely, i) obviously the quantum numbers to be projected out, but also ii) the variational space retained for this intrinsic state.

  Inf φ φ|P H|φ φ|P |φ + φ|U |φ = Inf τ Inf φ→τ φ|P H|φ φ|P |φ + dr τ (r) u(r) .

Acknowledgements: It is a pleasure for B.R.B. and B.G.G. to thank the TRIUMF Laboratory, Vancouver, B.C., Canada, for its hospitality, where part of this work was done. The Natural Science and Engineering Research Council of Canada is thanked for financial support. TRIUMF receives federal funding via a contribution agreement through the National Research Council of Canada. B.R.B. also thanks Service de Physique Théorique, Saclay, France, and the Gesellschaft für Schwerionenforschung mbh Darmstadt, Germany, for their hospitality, where parts of this work were carried out, and acknowledges partial support from the Alexander von Humboldt Stiftung and NSF Grant PHY0555396. The contribution of two anonymous referees in making this paper clearer is also gratefully acknowledged.