Comments on Proposed POSI 2.0 Revisions

My comments

The most frequent concerns I’ve encountered in this context are:

• POSI is overly focused on scholarly infrastructure; much of it could be adapted to general open infrastructure with some modifications.

• POSI is overly focused on membership organizations.

There’s no reason why other industries can’t adopt POSI to suit their needs. POSI adopters might even be willing to provide guidance. However, it’s already challenging to make POSI applicable to the diverse range of players in scholarly communication. I’m concerned that attempting to expand it further could either make it overly complex, too ambiguous, or both.

Initially, I was sympathetic to the second concern. It’s undeniable that the original principles were primarily written by people familiar with “membership organizations.” Consequently, many of the examples we highlight (particularly in the original blog post) are related to membership organizations.

But there are at least two senses of the words “member” and “membership”.

• Implicit membership is categorical or statistical (you belong to a set by virtue of a characteristic, like pétanque enthusiasts)

• Explicit membership is formal and intentional (you actively join and are recognized as a member, like a pétanque club)

And if you examine the actual text of the principles, the word “membership” only appears three times- the first two times in the “implicit” sense (members of the scholarly community) and the third time in the “explicit” sense (as in “membership fees”). Even in the last case, it is just providing one example of possible revenue sources that do not involve “charging for data.”

And the 1.1 revision made the issue even less of a concern by replacing the phrase “Non-discriminatory membership” with “Non-discriminatory participation or membership”

So it isn’t really clear what text people find inapplicable to other organization types (the call for comments doesn’t really give examples) and, so I’ve come to think this concern is overblown. Having said that, it might be useful if the POSI site provided a special section with examples of how current POSI adoptors have interpreted the principles for their particular contexts.

The 1.1 revisions of POSI created a regression, so this can largely be resolved by reverting to the original text of the 1.0 principle.

In the 1.0 version of the principles, under the Governance section, there was the principle that read:

Transparent operations

This was modified in the 1.1 revisions to read:

Transparent governance

Which effectively made the entire section only about governance instead of about governance and operations.

This is one of several instances where the 1.1 revisions have made POSI less clear and more contentious. Another notable example is where the phrase:

“data related to the running of the research enterprise should be community property”

was replaced with:

“data related to the running of the scholarly infrastructure should be community property.”

As ORCID correctly pointed out, the latter could potentially encompass purely operational (and often private) data, such as HR records, passwords, and so on. This, of course, is not what was intended.

The primary concern here is that a POSI-endorsing organization might transfer its assets to a non-POSI endorsing entity that could subsequently enclose them.

This is a certainly a risk that should be addressed, but it is also an opportunity for POSI to highlight that, if an organization has at least met three of the principles for POSI compliance:

• open data
• open source
• open patents

then this “enclosure-through-transfer-or-inheritance” scenario becomes virtually impossible because the community can always choose to “fork” the infrastructure.

In this respect, POSI serves as a “poison pill,” making it highly undesirable for hostile takeovers or inheritances.

Yes, there are still certain assets that the community would not be able to take with them when forking, such as “domain names,” “trademarks,” and “private data.” However, this is also true of large open source projects, and these limitations have not prevented forks of numerous significant open source projects (e.g., OpenOffice->LibraOffice, Redis->Valkey, ElasticSearch->OpenSearch, MySQL->MariaDB, Terraform->OpenTofu).

So yes, it seems useful for POSI to define principles around successor organizations and the transfer of assets in order to constrain the behavior of adopters who haven’t yet met the commitments to open data, open source, and open patents.

Anybody who has tried to setup a new infrastructure organization will have met a common and understandable concern amongst those who would be on the hook to fund it- a concern that is often referred as “The Shirky principle”

institutions will try to preserve the problem to which they are the solution

And in the case of mission-driven organizations, this can seem particularly pernicious because it means that, at some level, they have an interest in never fulfilling their mission.

So funders are understandably cautious about committing to funding something that might last “forever.”

But the problem with the Shirky formulation (and variations of it ²) is that it makes the dynamic sound sinister when there it is in fact driven by entirely innocent, human, and altruistic concerns.

• We don’t want to fire colleagues and friends whose livelihood depends on the organization’s existence.

• We don’t want to lose our own jobs.

It is a case of perverse incentives.

So one of the core ideas behind POSI was to try to encourage a humble organizational culture that recognized its mission was always more important than its existence.

The notes on the proposed POSI revision state that there is “skepticism about the practicality of this principle, as it’s unclear what formal incentives would encourage an organization to cease operations voluntarily”.

First, we should challenge the idea that just because we don’t know how to do it yet, it should not be in the POSI principles.

To be blunt, we don’t have good examples of widely replicable sustainability models for open scholarly infrastructure either.

And we also don’t have examples of un-subvertible governance structures for organizations.

I could go on.

Part of the point of POSI is for the open infrastructure community to directly acknowledge and address these challenges instead of pretending they don’t exist.

But back to the question: “What are examples of formal incentives that would encourage organizations to cease operations voluntarily?”

Pay them to.

Introduce internal incremental reward structures that encourage staff to continually identify and remove accidental complexity and services that have ceased to contribute meaningfully to the mission.

Or more radically…

Guarantee each employee a year of salary should they collectively manage to figure out how to solve the problem the organization was designed to solve without needing the organization.

How?

Use the contingency fund.

Or maybe work with funders to collectively build a mission-completion bounty fund?

The point is that the tendency toward institutional self-preservation is a valid concern.

Commercial organizations have a perpetual reason to exist— which is to return a profit to their investors. They have incentives to encourage this.

Non-profit, mission-driven organizations should not have incentives to exist in perpetuity. And they should have incentives to discourage it.

It is important that POSI retain this principle. We might not know how to do this at the moment, but by keeping this in the principles it forces us to think about the problem instead of ignoring it.

This is a good idea. It is particularly important to document the role of volunteers in sustaining infrastructure organizations because:

• It highlights otherwise invisible labor
• Volunteer labor is an important source of risk (e.g. burnout, changing economic conditions that discourage volunteering)
• Reliance on volunteer labor can reduce diversity of stakeholder participation (e.g. unpaid intern syndrome). It would be useful if POSI also encouraged organizations to document what they do to mitigate this danger (e.g. offer stipends, training, etc.)

POSI should also call on organizations to highlight other labor dependencies that are typically not documented. For example:

• Reliance on employees who are on short-term contracts
• Reliance on contractors
• Reliance on intermediaries (e.g. sponsoring organizations, service providers, aggregators )

All of these working arrangements can obscure the true costs and risks associated of running infrastructure.

It’s unclear why financial sustainability is being singled out here, as it may take considerable time to fulfill any of the POSI commitments. Different organizations will face varying challenges in meeting these commitments. For instance, Crossref has met its financial commitments but has yet to fully open-source its code due to the size, age and complexity of its codebase.

The most important thing for POSI to highlight is that conventions that might apply for standard commercial and non-profit organizations are almost certainly not appropriate for infrastructure organizations.

The reason for this is simple: an infrastructure organization, by definition, will have other organizations dependent on it. Furthermore, infrastructure functionality is likely to be deeply embedded in the systems of those dependent organizations.

So we are not talking just about giving the infrastructure organization enough time to wind down; we are talking about giving the community that depends on said infrastructure enough time to extricate itself from dependency on said infrastructure.

This is why, in the original POSI principles, we suggested a year as an example timeline when the convention for many other organizations is often between three and six months.

We heard several jeremiads about how “one year was too long,” but frankly, given the ubiquity of some of the infrastructure organizations that have adopted POSI, one year is probably way too short.

In any case, the principles are supposed to be principles— so , yes, each organization should pick an appropriate time scale. But POSI itself should emphasize that the expectations for winding down infrastructure are fundamentally different than those for other kinds of organizations.

It is encouraging to see that this proposal presents ‘“de facto” and “formal” standards on an equal footing.

This is important because formal standards processes, particularly, can be dominated by commercial organizations to achieve regulatory lock-in and hinder the ability of smaller, non-profit organizations to provide infrastructure services. Commercial organizations have mastered the art of convening “Bootleggers and Baptists,” into standards forums to create exceedingly complex standards that, while open, are challenging to implement without the expertise of numerous experts and developers. The accumulation of these standards and their integration into national procurement policies have made it extremely difficult for new entrants to compete in offering infrastructure services.

I do wonder, though, if POSI really even needs to mention standards? I suspect that the primary concern that people have is that “open source” and “open data” can turn out to be unusable without documentation. And the typical formal standards process at least produces some documentation. But couldn’t POSI address this by simply amending the existing language around “open source” and “open data” to read “open and documented source” and “open and documented data?”

POSI could use some explicit language on security, but it would be helpful if POSI provided examples of security concerns that might affect the ability of one to open data. The classic one is not wanting to reveal the migration patterns of endangered species.

On the question of organizations having a policy on what happens to private data in the case of transfer to another organization, POSI should advocate two things:

1. A strong and unequivocal prohibition of the transfer of private data in case of transfer to another organization.
2. A call for POSI compliance to include that organizations should have a convenient and free mechanism for participants to export their private information into documented formats so that they can easily move it if they want to.

This is a useful addition as long as it is not seen as a substitute for organizations making data broadly and openly available via periodic public data dumps.