"CMS" stands for "Content Management System". It is a piece of web-based software that allows to organise and share content in a controlled way.
Such a system is usually designed for multiple authors - with the possibility of them receiving different roles, similar to the roles of the chief editor, editors, and reporters in a newspaper. Some roles have a lot of control and privileges, others don't. Besides, a different set of rules is applied to the users of the CMS who don't contribute content but need to have the ability to read it or retrieve it. Similar to a newspaper, a reader will be able to get the full text of a finished article, but not of the article's drafts and original supporting materials, that only the journalists and the editors get to see.
To ensure that every user gets the right set of privileges, a CMS incorporates an authentication system - a way to securely log in users by unique user names and passwords. This authentication mechanism must be done in such a way that it cannot be easily bypassed or broken - it must be secure and robust.
A CMS must also support a variety of different content types - text, images, videos, audio files. It must have a mechanism for uploading these files (while providing a way to label them and tag them with keywords); a mechanism for organising and storing them over time; and a mechanism for delivering them to users, who will either view them online or download them.
In short, there are three fundamental components in a CMS - content, users, and permissions. Permissions determine how users interact with content. This simple structure can quickly become rather complicated as you add more users with different roles, and different types of content. In the following example (based on our Tiny task 1: Initial project idea) we have only 7 users, and only 2 pieces of content. Solid arrows represent read and edit privileges, dotted lines represent read only access. You can see it can get pretty messy very quickly.
From this really simple foundation, we can create a lot of services, mixing users and content in different proportions, for example:
Blogs - take one user and organise his or her contributions in a chronological way, newest content on top
Photo galleries - take a specific kind of content, image files, and represent them in a grid with previews; build a way to show the full size photos and links back to the previews page, as well as next / previous buttons.
Forum - take many users, and allow them to initiate strings of content. Allow other users to add other ideas to the strings. List the titles of these strings (which are usually called threads) in chronological order, with the newest ones first, similar to a blog
Wikis / glossaries - allow users to define terms, organise the definitions alphabetically.
These services can connect to additional features, that usually don't mean much by themselves, but make sense only together with these services:
User references: For example, each blog entry is labeled with its author.
Time stamps: The system stores the time when the content was created or modified, which allows to order things chronologically, showing readers the newest content first, and enabling search an organisation.
Tags / taxonomies: Users can add keywords to posts and files. Again, this is an organisation and a classification tool, which facilitates search and creates cross links between similar pieces of content.
Comments: These function as mini-forums attached to other posts, where users can discuss the content.
Rankings: These may be of an approve / disapprove kind (similar to the Facebook Like button) or of a score kind (like star ratings of a products on Amazon or of a movie on Netflix).
Geolocation: A GPS coordinate of where the content was created or from where it was posted.
Most advanced CMS's will have all these services and features mixed in a very complicated ways. Facebook, one of the largest (if not the largest) CMS's in the world, has all the items described above and many more, all interacting in sophisticated ways; there are also additional layers of complexity coming from the need to continuously evaluate the content and the user behaviour and serve targeted ads. Last but not least, there is an expectation that the site is always available, with no downtime. Multiply that problem by 500 or 600 million (the number of users), and you begin to realise that the fact that site is running is an amazing engineering feat.