ADR on the terminology of "CMS" versus "Studio"

Development Architecture
, ,
1

Hey Open edX developers! I’d like to share the result of a recent architecture decision record (ADR):

There has been disagreement over whether Open edX’s content authoring Web service is called “CMS” or “Studio”.

This ADR decides that:

  • “CMS” is the proper name of the Web service.
  • “Studio” is the content authoring product that CMS powers.

Going forward, keep this distinction in mind as you write apps, tools, and documentation relating to either CMS or Studio. There are still some places (for instance, Devstack) where the wrong term is used, but this ADR should make it easier to smooth them out over time since a consensus has been reached.

This may not strike everyone as an especially significant or interesting decision :grinning_face_with_smiling_eyes: Still, I do think that straightening out our lexicon is one way to make our project more comprehensible for newcomers and more delightful for experienced contributors.

Happy hacking!

1 Like
2

This is a great decision, it used to confuse me what to call it “cms”, or “studio”. Until I learnt to live with it!.

But still not sure which context exactly to use “studio”? providing an example would be helpful, maybe in the “course authors” doc?

3

The docs on “Building and Running an edX Course” have a “What is Studio?” section that I think explains Studio pretty well. Alas, those docs are filled with a lot of edX.org-specific info instead of being oriented at Open edX.

@ghassan is there other course authoring documentation that you of that we could add this information to?

4

I was referring to this doc exactly https://github.com/openedx/edx-documentation/blob/master/en_us/open_edx_course_authors/source/getting_started/CA_get_started_Studio.rst which uses studio and I guess it’s an appropriate use. Given my take from the ADR you referenced above is (please correct me if I am wrong) to use CMS whenever the context is technical e,g, API docs, infrastructure…etc and to use Studio when documenting how to interact with the product in a manner where no technical background is necessary e.g. authoring a course.

1 Like
5

@ghassan I think your distinction is correct in most cases. I’d note one exception – the HTML/JS/CSS for Studio should be considered “Studio frontend code”, not “CMS frontend code”, since the code is part of the Studio interface.

The distinction is a little fuzzy right now because the Studio interface is coupled to the CMS backend. Once the Studio interfce is fully extracted into micro-frontends, it’ll be clearer, because CMS will be a backend-only webservice, and Studio will be a collection of MFEs using CMS.

1 Like
6

Makes sense!, thanks for the clarification.

1 Like
7

@kmccormick - I’m curious to get your thoughts (and others) on whether there is value in retaining cms at all, or any distinctions between ’ studio front end code’ vs ‘cms front end code’. It would be nice to avoid general industry / technical jargon like cms IMO but this is a minor issue not a major one. (For example our content discovery integrations are also “cms” integrations)

8

@marcotuts check out the ADR–I think it covers what you’ve brought up. Let me know if it doesn’t!

Also, here’s a link to the PR where the ADR was debated: Add ADR to declare distinction between 'cms' and 'studio' (and change STUDIO_CFG to CMS_CFG) by kdmccormick · Pull Request #29534 · edx/edx-platform · GitHub