Allow for different flavors/target groups of the game

[Ainali]

After the OSPO OnRamp session in the chat, a question was asked if the game could be used for anything else than public organizations, and of course, it can. But rather than telling people to fork it and add their own cards, perhaps we could make it more modular?

My initial idea is that each card type could also have an extra parameter for the target group. Then each card either have a specific group named or it could be an all for generic cards. Then when you make the cards they will get the default setup (presumably being public-organizations or something like that) unless you specify a target group.

To make this not too complex, we could add guidelines that if you add a target group for a card type, one has to add the right number of cards so that all generic ones for that card type can be swapped away in one go and we don't need to mix them.

Does this sound feasible? My idea here is that this could go to the roadmap, and someone will have to come up with at least one set of cards for another target group to make it worthwhile implementing it.

[ericherman]

I think we can put this on the Roadmap.

While it's not high-priority for the Foundation for Public Code, it would be nice to support our FOSS friends by having a deck without the Public Organization focus.

I can imagine it being relatively straight-forward to make alternative cards to the ones that have a strong public-org orientation.
I expect that this would be only a little bit of work; in some cases, it may simply be a matter of removing the word "Public" (e.g.: "Public organization 1 is Commissioning").
However, I expect that most cards will require larger text changes, yet likely still relatively small.

From there, it will be a little tricky -- but not too tricky -- to adjust the Makefile to use either the originals cards or the alternatives cards when building the 54 card deck.
There are multiple ways we could do this; I'm certainly willing to help hack on this stuff.

[Ainali]

Added to the roadmap.

[nicorikken]

I can second this idea, after discussion with @Ainali @ElenaFdR and @marbre Some ideas:

Flavors

• Research institutions often dealing with both public and private partnerships and differences in goals and capabilities.
• Generic public/private collaborations which is reasonable to occur for technical software, just think of Kubernetes related tools developed by government to fill gaps in their own infrastructure or the existing 'public WiFi mangement system' scenario.

Starting state

• Single actor Can we start with a state of a single actor, to which others get added?
• Only inhouse developers How about not having contracting parties?
• Some states with other

Calamities

• Becoming a standard Plan to upgrade the project to a standard, resulting in additional requirements for the standardisation process
• Research request Researcher needs a specific feature just for this single research which doesn't really fit the larger roadmap
• Forked community Dissatisfied party forks the project and initiates a competing collaborative organisation
• Research project code Researcher wants to merge code related to a research project for which there is no guarantee for maintenance (similar to 'Wild developer')
• Incompatible technology (generic) Interested party is used to a different programming language or technical infrastructure which makes it impossible for them to adopt and contribute.
• Intellectual property concern Lawyer of one organisation has triggered a discussion about intellectual property being lost through this project, reducing the willingness to collaborate. Consequences are similar to 'lost funding' but with a different motivation.
• Security requirements For the second year in a row the project was unable to meed the security process requirements set by the 'governance body/stewardship organisation' and the project is at risk of being removed from their coordination.
• Lost funding Existing 'lost funding' can apply equally in a research setting).
• Code quality conflict Conflict about coding standards and code quality: different skill level of developers have different quality norms. Might be a trigger for the 'automatic quality checks' below.
• Lots of questions filling the issue tracker. Could be triggered by citizens, students and organisations as well.
• Not open standard it makes sense for the project to ensure interoperability with a standard which is not an open standard. Could trigger a discussion on dealing with an external standardisation body.
• Misbehavior in the community somebody in the community files a complaint about misbehavior by one of the project maintainers. To trigger a discussion about 'code of conduct', see object.
• Different use-case at one of the organisations the software has found applicability for a different use-case out of the existing context, resulting in a split roadmap. Could trigger discussions about modularity, special interest groups, whatever.
• Request for license change A private organisation is willing to adopt the project and contribute to development, but doesn't want to meet the reciprocal requirements of the existing project license. To trigger discussion on licenses and such decision making.
• Abandoned dependency One of the key project dependencies has become unmaintained by the original developer. One organisation wants to change to a different library, the other wants to take on the maintenance of this library.
• Threatened vendor An existing vendor offering a service in the same space is angry about the competing solution and lost revenue. Could trigger discussion on antitrust law, project modularity and being open to collaboration.
• End of free tier The collaboration platform is stopping the free tier for public projects. Might trigger discussion about values on the collaboration space and having is as a shared asset in a larger organisation. Is quite similar to other existing discussions though.

Actors

• Researcher as long-term effort/collaboration
• PhD student/Graduation student for limited time effort
• University
• Research institution
• Standardisation body
• Private company adopting the software
• Student
• Special interest group as a common term for a governance body that is dedicated to a topic
• Funding organisation like Sovereign Tech Fund or NLnet. Might be used to discuss being open to funding or working with a funding organisation in case on is already in place.

Objects

• Open standard to deal with projects that are more focussed on a standard rather than code
• Automatic quality checks to discuss automation of procedures for incoming pull-requests. Might be a solution for the 'Wild developer' too.
• Marketplace or gallery to show potential projects/products, which can trigger a new forms of governance
• Dataset dataset to test or verify, could be open data
• Algorithm to make explicit the novelty in the code, especially for certain research projects.
• Code of conduct to make explicit the governance of the code of conduct, see 'misbehavior in the community calamity'
• Test setup some setup in hardware of software that could be part of one of the organisations or under shared governance
• Collaboration space might be a start for discussion about collaboration space and where it is hosted. Not sure if this is relevant enough.

Scenario's

This would really need some more thinking

Fine if parts of this comment end up in the governance game under CC0-1.0 license.

[ericherman]

These are all good ideas.

It would be easy enough to create a branch which adds all of these cards, and have different build targets to include different sets in a given deck.

I imagine we need to also think about what cards would be removed from the deck for decks focused on "Research institutions" or "Generic public/private collaborations" ... as well as consider whether any of the existing cards need a slight wording adjustment for fitting well into different decks.

[anthonyharrison]

I think there needs to be much more focus on the issues with the supply chain and the impact that calamities/challenges could place on an organisation. Lack of education/awareness is a growing issue in some sectors so adding this to the mix would be good. And even with a single developer, there is a very high probability that the developer will use some 3rd party software (from the supply chain). Has this risk been adequately considered?

Calamities including supplier going out of business, supplier being compromised, supplier suffers data breach, supplier changing licence (either a different and more restrictive open-source license or a proprietary one etc. ). And don't forget a supplier could be providing a service (e.g. data storage, access to an API, access to a AI engine....) which are often overlooked (out of sight, out of mind).

[Ainali]

Thanks, Anthony! Just to be clear, are your suggestions general for all flavors/themes, just related to the ones Nico suggested or a specific flavor on its own?

[anthonyharrison]

@Ainali I think supply chain is a critical issue in all instances! Clearly it is highly relevant to the the issues in this post but it could usefully become a wider theme.