Skip to content

Update choosing a platform doc #8837

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 26, 2022
Merged

Update choosing a platform doc #8837

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
095837e
Update choosing a platform doc
agjohnson Jan 25, 2022
dc05f27
Update copy on community
agjohnson Jan 25, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 21 additions & 15 deletions docs/user/choosing-a-site.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,41 +1,47 @@
Choosing Between Our Two Sites
==============================
Choosing Between Our Two Platforms
==================================

A question our users often have is what the difference is between |org_brand| and |com_brand|.
This page will lay out the functional and philosophical differences between the two sites,
which should help you choose which is a better fit for your organization.
Users often ask what the differences are between |org_brand| and |com_brand|.

The features available on both platforms are the same.
The primary difference is the audience and use cases that are supported.
While many of our features are available on both of these platforms, there
are some key differences between our two platforms.

Read the Docs Community
-----------------------

|org_brand| is meant for open source projects to use for documentation hosting.
This is great for user and developer documentation for your project.
|org_brand| is strictly for hosting open source documentation. This means that
project documentation source, and the generated documentation, are both publicly
accessible and licensed under a permissive license.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why permissive specifically? Could be copyleft as well (not considered "permissive" as far as I understand). Or, not have a license at all, because people tend to forget to choose a license. I would remove references to the licensing here, just say that the sources are "publicly visible" or something like it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same, I don't think we mention any of that in our ToS

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good points.

I wasn't meaning to differentiate between copyleft and permissive here. There's no point where we check or enforce licensing, however we do describe in several places (or have described in the past) that community is for open source projects or non-commercial works. Dropping mention of a license is the most correct though.

True about repositories without a license. Github TOS would apply here by default, meaning those repositories retain full copyright and do not explicitly grant us any rights at all -- even the right "to use".

In this case, our TOS does grant us necessary rights:
https://docs.readthedocs.io/en/stable/terms-of-service.html#license-grant-to-us

So, open licensing is not a legal requirement because our TOS works around that. But, I will leave the mention of open source documentation hosting.


Important points:

* All documentation sites have advertising
* Open source project hosting is always free
* All documentation sites include advertising
* Only supports public VCS repositories
* All documentation is publicly accessible to the world
* Less build time and fewer build resources (memory & CPU)
* Email support included only for issues with our platform
* Documentation is organized by projects

You can sign up for an account at https://readthedocs.org.

Read the Docs for Business
--------------------------

|com_brand| is meant for companies and users who have private documentation.
It works well for product documentation as well as internal docs for your developers.
|com_brand| is meant for companies and users who have more complex requirements
for their documentation project. This can include commercial projects with
private source code, projects that can only be viewed with authentication, and
even large scale projects that are publicly available.

Important points:

* No advertising
* Hosting plans require a paid subscription plan
* There is no advertising on documentation sites
* Allows importing private and public repositories from VCS
* Supports private versions that only your organization or people you give access to can see
* Supports private versions that require authentication to view
* Supports team authentication, including SSO with Google, GitHub, GitLab, and Bitbucket
* More build time and more build resources (memory & CPU)
* Includes 24x5 email support, with 24x7 SLA support available
* Documentation is organized by organization, giving more control over permissions

You can sign up for an account at https://readthedocs.com.
Expand All @@ -44,4 +50,4 @@ Questions?
----------

If you have a question about which platform would be best,
you can email us at [email protected].
email us at [email protected].