Project Open CSP

What is the goal of this initiative
The goal is to have a MediaWiki solution that can serve as content services platform for large companies.

Such a platform should be an open source alternative for products like Confluence.

Compared to those products such a platform would typically provide better flexibility and lower cost.

What do CSP users want?
The assumption is that companies want:
 * An easy to install CSP framework with lot's of out-of-the-box features
 * High flexibility in creating custom features and adapting features to company processes, policies and standards
 * Ongoing development in line with common DevOps practices

What is needed to make this a success
This is an ambitious goal, but the MediaWiki platform offers a great foundation. The key 'building blocks' for making the CSP a success are:

Bright future for MediaWiki
MediaWiki is going to stay here for decades and will develop accordingly. This definitely seems to be the case, the future of Mediawiki is as bright as ever.

CSP framework with essential features
The CSP framework should have a set of features that are supported by high quality extensions. The starting point is that a CSP cannot be without these features. Also they have to be tightly integrated and work together perfectly. The essential features with their supporting extensions are:

Plug-in market
The CSP framework is a perfect foundation for plug-ins that can be installed on top of it. These plug-ins of course need to work well on the framework, but need not guarantee to work well with other plug-ins. Suppliers can provide suites of plug-ins that work together well, but the user of the CSP decides which plug-ins to use. The purpose of the list below is to create a shared understanding of what plug-ins can do.

Support for DevOps practices
Some of these practices need special attention because they are not straightforward for a MediaWiki based CSP. They are: The main reason why these practices need special attention is that features often are (partly) implemented as content. Templates, forms, Lua modules and widgets are pages in the wiki and therefore technically should be considered as content since they live in the database. MediaWiki doesn't provide a standard way to deal with this in the mentioned practices. For version control those pages need to be as files on the server. For continuous integration and deployment there need to be tools to get those files as pages in the deployed system. For automated testing there need to be tools that work within the system on those pages.
 * Version Control for all system artifacts
 * Continuous integration and deployment
 * Automated testing

Some tools are available to support this.