Open Source Project and Community Event Accounts

This section is for anyone who is interested in creating an account specifically for an open source project and/or community driven event.

If you are a maintainer of a project or event organizer and are representing yourself, this page does not apply to you. For example:

I, Kris Nóva, am a maintainer of Aurae.

This documentation only applies to me if I were attempting to create a 2nd account in addition to my primary personal account that would be specifically for “Aurae”.

This documentation does not apply to my personal account, where I would be free to talk about Aurae as I wish.

Open Source Projects and Community Events

We welcome open source and collaborative projects to create accounts on Hachyderm. We also welcome community events to create accounts on Hachyderm.

If your project is an extension of, or resembles, a corporate account, it is bound by the Corporate Account rules and restrictions. If your event is a corporate event and/or meetup, it is also bound by those same rules and restrictions.

If you are unsure if your project and/or event would be considered corporate, please reach out to us at admin@hachyderm.io.

Understanding Open Source Projects and Community Events

The following are the types of projects that are welcome to come and go from Hachyderm as they please.

• ✔️ Open source software projects with MIT, Apache 2.0, GPL, Creative Commons or similar licenses.
• ✔️ Open collaborative projects such as The Gutenberg Project or collaborative wiki style projects like Wikipedia and Wikimedia.
• ✔️ Community driven events, open organizations, and volunteer driven events like FOSDEM.
• ✔️ Open source organizations such as Matrix.

OSS projects and industry events that are company-like or business-like in their implementation will be considered “corporate” (in the account sense) and require a corporate account. They will also be bound by the account rules and restrictions for that account type. Criteria that would meet this type:

• Projects that are a product / service of a parent entity that would meet the criteria for a corporate account or
  events that are for a specific company or company-like organization or
  events for a specific product / service of that company or company-like organization.
• Projects with either a single sponsor or owner that is a company or is company-like / business-like or
  events that meet this definition.
• Projects that resemble paid services for a company or company-like / business-like entity or
  events that meet this defniition.
• Projects that have “free tier” and “paid tier” models that resemble company-like or business-like implementation.

Some specific examples that would would not fall under the OSS project / event definition (in terms of account type) and would require a corporate account:

• ✖️ Large trade organizations and governing bodies such as the CNCF or Cloud Foundry or their subsequent projects such as Istio or Helm.
• ✖️ Product ecosystem event like AWS re:Invent
• ✖️ Open source projects with a single corporate sponsor/owner such as Google’s Go Programming language and HashiCorp’s Terraform.
• ✖️ Open source projects with structured sponsorship models that resemble paid services. Some examples include unlocking essential features, increasing quotas, and so forth via donation or payment tiers.
• ✖️ “up-sell” or “upgrade to pro” or “free trial” model projects that resemble a paid service such as pfSense Community Edition or Wolfram Alpha.

What is financial bias?

Financial bias is defined as “the ability for a specific vendor, project, or organization to pay for a competitive advantage” or sometimes referred to as “pay-to-play” vendor spaces.

Why do we care about financial bias?

We acknowledge the system that we’re in: projects and events need money to run and continue to have great work and results. What we are specifically concerned with is when financial bias can create unhealthy releationships. In particular, financial bias can taint the relationship between a project and/or event and its intended goals. As that grows and spreads, this in turn drives unhealthy relationships between the people building/running the project and/or event and the very people they want to bond, collaborate, and share with.

Our goal with the guidance, rules, and restrictions that we have in place for these and other account types is to protect our community by promoting and nurturing the conditions that allow healthy relationships to thrive by default.

Frequently Asked Questions

Can I create an account for my event? Like DevopsDays?

Yes, the goal is to support community focused events. If the goal of the event is the community, then this is the correct account type for your event. If your event is business oriented, or for businesses to network with each other (e.g. what is sometimes referred to as a tradeshow), your event will need a corporate account.

What about DevopsDays for my specific city?

Yes. As long as your subsidiary account isn’t repeating the same content as the parent account. We expect each account to have relatively independent content.

Can I create a support/help/fan/parody account?

No. Accounts like “Linux Tips” or “Kubernetes Memes” are not in alignment with our mission to create a curated group of professionals. We aim to have accounts that represent real people.

Can I create an account if a similar one already exists?

No. We want to have one account for each project. We do not want to have “Wikipedia tips” and “Wikipedia facts” as separate accounts. We think that collaboration of the same account should be shared at the project level. You should join the project and ask for access to the Mastodon account.

Can I create a bot account for our open source project?

No. We know it is fun to automate pull requests, build status, and more. However, we try to keep our content based around real words written by real people. That said, you are welcome to include some of that data in your project’s account posts, it just can’t be dedicated to only publishing that type of content.