The CMSMS Dev team recently discussed some difficulties that appear from time to time with projects registered on the forge. Individually they are minor problems to the Dev team but can accumulate as we have seen in the past. Also, these problems may have major implications for our user community. To that end we as a group have come up with some rules for forge projects that are in effect as of now. In the past there have been no rules for projects in the forge, and therefore the result has been some confusion from time to time. The following document will soon be inserted as rules to read when registering a new project in the forge. Additionally, in the coming days we will also be sending an to all registered project administrators.

Introduction

The Forge is a website and application software hosted by CMSMS (all rights reserved) and written by Ted Kulp. Its purpose is to provide a space where third party developers can develop, manage and distribute add-on projects for CMS Made Simple in a non-interfering and cooperative manner.

The forge provides (amongst other things)

• Source code repositories (svn or git), including browsing of source code.
• A bug and feature management system
• A file release and distribution system

CMSMS Forge Project Rules:

Copyright and License:

1. Only projects relating to CMSMS will be permitted. Projects that are not modules, plugins, themes, documentation, or translations for CMSMS will not be accepted. Additionally, we do not host websites. All projects submissions must be approved by a forge administrator.

2. Only open source projects released under the GPL (Gnu Public License) or another compatible license will be permitted. Additionally, all projects must be distributed with their source (i.e: no encrypted source files).

3. Special rules apply to translation projects which are distributed with the CMSMS core. Forge administrators may add or otherwise manage the people that have access to the project in order to foster participation in the translation effort.

4. All projects must retain proper copyright permission and give proper copyright credit for included or forked projects.

Account Information:

5. Contact information (email addresses) etc. must be kept accurate at all times. The CMSMS Dev team will use this contact information in the event of a concern about a project owned by that user, or for occasional email updates about forge projects and the forge status. The contact information will not be published in any machine readable way on the forge. If the contact information for a forge account is not accurate it may lead to the account and all related projects, bug reports, feature requests or other input being removed.

Responsibility and Warranty:

6. The CMSMS Dev Team assumes absolutely no responsibility or warranty for the working state of any project, its reliability, security, or compatibility with any version of CMSMS. Projects are managed by their individual developers and the CMSMS Dev team (other than instituting guidelines, rules, and policies) has no responsibility for the code or documents housed within the project.

The purpose of the forge is to serve as a convenient place for contributing authors to house, manage and distribute projects related to CMSMS. It in no way indicates that the CMSMS Dev team is in any way responsible for the working state or accuracy of the projects housed within.

Project Cooperation:

7. Projects that require their users to modify the source code of the core or of any other projects will not be permitted. Projects should install and work properly using the officially supported distribution and installation methods (XML files, or zip/tar files) and require no modification of any other files, particularly files created by another project. Where possible special requirements such as required php extensions, or php configuration limits for the project should be listed in a place that can be easily read by the user before downloading and installing (for modules putting this information in the help or about information is sufficient).

8. No projects that directly modify the data or preferences of any other project or of the core will be permitted.

This means that Project B when installed should not be adjusting preferences or directly writing to the database tables managed by project A or of any core data structures or preferences. Project B must instead use the documented and public API’s of Project A or not interface with the project at all.

Exception: The author may access or modify the data of another project ONLY if they have responsibility and control for the other project. For example, if an author owns the copyright for, and maintains two modules that work cooperatively together then he may write code in one module that directly modifies the preferences and data of the other.

9. No projects that use undocumented or private API’s of another module or of the core will be permitted.

When writing project B that will depend on project A, an author frequently looks through the source code of the other project to find functions he can use to accomplish his tasks. The author should not use any undocumented or private methods within the other project.

If a function exists but is private, or undocumented, or does not exist the author has two options:

• Work with the author of the other module to enhance the documentation or the API’s to solve the problems required.
• Fork the module (thereby assuming responsibility for the code), see the forking rules, below.

Stale or Inactive Projects:

10. Projects that have no commits or releases within the first three months after approval will be deleted without notice.

11. Projects are marked as “Stale” after 12 months without commits or releases. Projects that have no commits or releases for 24 months may be deleted, this will be judged on an individual basis.

12. The CMSMS Dev team will at no time use its administrative access on the forge to allow another community member access to a project to which he is not otherwise entitled.

• i.e: There is no way for a community member to ‘assume’ responsibility over a stale project.
• The original author(s) will retain copyright rights, and ownership in perpetuity.

Language and Distribution:

13. Projects that install as a third party add-on into CMSMS must display in the module manager and in other distribution mechanisms in English including the description, and install and work correctly in English. Additional translations may provide for the ability for the project to display its information in other languages, however the English version must always be present.

Forking Rules:

Open source projects may be forked at any time. Forked projects can be hosted on the CMSMS forge as long as they follow all of the above rules along with:

14: Authors of project forks must change the contact information in the modules help and about information, and clearly describe that the project is a fork of another project.

15. Forked projects should be able to exist cleanly on the same CMSMS Install as the original project and should not interfere with it in any way.

Enforcement Policy:

The CMSMS Dev team will not actively review the source code for each project, or the state of each project. Individuals are asked to report their concerns via email to forge@cmsmadesimple.org. Concerns will be handled on an individual basis. When a concern is reported a member of the CMSMS Dev team will review the reported project and may decide to take further action.

If the concern is regarding a stale project, and the project has not had commits or releases for 24 months the Dev team will at its discretion either attempt to contact the administrator of the project, or delete it.

In other cases the Dev team will make a reasonable effort to contact the administrator of the project in order that the concern can be rectified. The administrator will have thirty days to respond to the email and begin to rectify the concern. We are not as concerned about time frames as we are about effort. If the administrator has responded to our concern and indicates that they will correct the problem within a reasonable period of time, we may have no further contact with them, and consider the issue closed, or continue to monitor the issue at our discretion.

If within 30 days we have no contact from the administrator, the Dev team may decide, depending on the severity of the concern to delete the project or to remove the project from public view as the technology on the forge permits.

The Dev team will make all reasonable attempts to assist the administrator in correcting the problem, by providing guidance or specific technical recommendations where possible. However the Dev team as a whole will not accept responsibility for the effected code or the accuracy of the recommendations.

Thank you for your time and cooperation.