0003: Plan name change

Summary

After announcing a name change in our blog, we will have to take extra steps in the implementation of the decision for a new name.

Motivation

Doing a brand change is always a risky decision. The team agreed on it after many discussions, and with some kind of general consensus, despite not everybody fully agreeing. Extending on the discussion in the blog post:

Benefits of a name change

  1. postmarketOS only reflects a fraction of what the project is, and could be. The best example is Fairphone 4 and 5 support being added on release-day. A new name could still reflect the sustainability aspect of the project, without exclusively referring to one very limited aspect of sustainability.

  2. It is hard to pronounce. This is specially a problem when doing outreach to non-native English speakers. This is a great problem if we want to grow as a community and reach out of the hacker world.

  3. The capitalization is awkward, as easily becomes obvious in point 1 of this section.

  4. An easier to pronounce and less specific name is certainly a better branding to approach less-technical people that might not already know about what postmarketOS is.

  5. postmarketOS has very little chances of being accepted as a trademark, leaving us in quite a vulnerable position against trolls. This came after discussions with trademark lawyers.

Problems of a name change

  1. Some people might feel alienated by it. Change is always hard, and we did not do a great outreach beforehand. We might have also failed to explain some of our rationale.

  2. Part of the reasons for name change come from a goal to expand the user-base of the project outside a group of tech-savvy hackers. This might be hard to explain, and might not seat well with some.

  3. postmarketOS is already a well-recognized brand, and easy to find online. We might loose some of that momentum with a new name. However, we shoot high, and it would be fair to assume that postmarketOS is only known by a tiny fraction of the people that might at some point be able to use a device with our operating system installed. So this might only be a relative downside.

  4. The rebranding might cause technical disruption, reason for which this PMCR exists.

In addition to this, a name change needs work. I personally do not consider that a downside. The work will be put by motivated individuals working as volunteers. People work on what they find best, and I do not consider it a downside when people do volunteer work on their own will. When volunteer work applies, it is not always for granted that people will do the same amount of work on some other part of the project. They might simply not do it.

Consequences

A name change could have the following consequences:

  1. An easier to pronounce name, that will be more appealing and easy to share outside the group of people that don’t yet know the project.

  2. Allow the project be appealing for greater demographies than a specific sub-group of people within the sustainability world.

  3. Avoid having to correct people over a non-intuitive capitalization.

  4. Having a name that could be defended and trademarked.

It also carries some risks:

  1. Alienating part of the community and causing some social backslash

  2. Requiring a transition for projects and branding

  3. Losing some recognition short-term. However, that does not seem to have been an issue in similar projects that renamed around us.

  4. We choose a name that people don’t identify with, or that is unnecessarily “empty”.

Implementation plan

The plan has two parts:

Finish making the decision

  1. Close the form for suggestions the day v25.06 is out.

  2. Discuss different alternatives within CC and TC team. Let every team member chose up to 5 names to add to the vote. A rationale of why those were chose can be included, to help others inform their decisions. We ask members to do a basic online search for the names to make sure they are already not used in other places. Suggestions to be sent in the private maintainers channel or directly to Pablo. Any obvious trolling choices will be discarded and announced in the maintainers channel. Name selection will last for at least one week after v25.06, but will only be closed when voting starts.

  3. Ask all team members to vote on a poll considering all the different alternatives using civs. The voting should start at the latest 4 weeks after the release is out, and be opened for 1 week. The voting will consider the 10 best alternatives, ranked, to be able to have backups in case big faults are found with the first ones. Asking for votes outside the team was deemed inappropriate due to the risk of trolling (e.g: people registering domains or trademarks)

  4. Ensure that everybody within the team is fine with the name that won the vote. If somebody is really unhappy with the name, we schedule a meeting where we discuss our options, try to understand the reasons, and figure out if we want to look for alternatives. As we already have the ranked list from the voting, this should be much faster than if we just started with a discussion without prior vote.

  5. The team will follow-up with some private outreach within trusted users and developers of different demographies to make sure the name is appropriate. We want to avoid a name having problematic implications for some communities, or being impossible to pronounce. The ranked choice voting should allow to use the next-best alternative in case the first one is deemed unfit. Who and how to reach out will be coordinated and agreed on a team meeting.

  6. A mascot design will be done matching the preferred alternatives to be released together with the name change. This should, however, not block further steps and is entirely optional.

  7. If 2 weeks after the voting closed no problems have been found with the chosen name or a backup, the decision can be considered final.

Implement the name change

The following actions should be taken, with no other specific ordering than the first 2 have to be done first.

  1. Before going public, buy associated domain(s), and rename or get associated social media account(s).

  2. Make it public, with a rationale on the decision

  3. Code/Rename changes:

    1. pmaports: packages with postmarketos in the name, adding “provides” for backwards compatibility

    2. bpo and pmbootstrap code changes (with alias/symlink to old name)

    3. postmarketos.org

    4. Visible parts of build.postmarketos.org

    5. Wiki branding

  4. (Concurrently to point above) Infra changes

    1. Point new domain to our websites and deploy them to the new domain:

      • postmarketos.org

      • gitlab.postmarketos.org

      • wiki.postmarketos.org

      • build.postmarketos.org

      • cast.postmarketos.org

      • (full list to be taken from infra)

    2. Create automatic redirects for old names

    3. Add new aliases for matrix rooms and move IRC channels

    4. Rename gitlab group and repositories with the name

    5. Create email aliases for everybody

  5. Do a blog post as retrospective

The proposer

Pablo Correa Gomez, a Core Contributor. I am basically opening this so we can start discussing on things that need change, and start drafting a plan. I do not have infra access, but could totally do any parts of the other work.