How to share code in the MMBase repository
Infrastructure and Organization
How to become a 3rd Party Package
Infrastructure and Organization
How to become a 3rd Party Package
This software is OSI Certified Open Source Software. OSI Certified is a certification mark of the Open Source Initiative.
The license (Mozilla version 1.0) can be read at the MMBase site. See http://www.mmbase.org/license
Table of Contents
If you are planning to share code in the MMBase repository, please read this first.
MMBase is a general purpose object oriented content management system. The sources are freely available since april 2000. Since that time, MMBase has become a base for many systems which are mostly web-oriented.
What exactly is MMBase? How is its software organized, and how will it grow overtime? The number of organizations involved with MMBase is increasing. This presents new opportunities to share and collaborate, provided that questions like these are anwered.
This document gives an overview of the different MMBase-application types there are and how the MMBase-community could be dealing with them.
MMBase is or can be divided in different parts. Some of the parts belong to the core of MMBase, some of the parts are applications build upon this core.
This section discusses the different parts, the community around these parts, the licenses that are being used or can be used, etc.
MMBase core is the base of all MMBase-applications. We strive to keep the Core as small as possible. There's an interface around the core, called MMCI, which is the preferred way for applications to use the core. This interface must be stable and backwards compatible between different MMBase releases, to ensure compatibility of MMBase-applications.
Community .
The core is maintained and extended by the MMBase developers (and especially by the commitors).
License .
The core uses the MPL-1.0 license. This license has been chosen to get as much freedom as possible. Developers can use the sources to extend MMBase, companies can use the core to build their own system and sell it to their customers.
Although the license allows to create proprietary changes, it's better to create changes with the backup of the developers community. It's better for the continuation of MMBase and proprietary changes are difficult to maintain between different MMBase releases.
Community packages are packages which are being developed by the same developers community as the MMBase Core. A Community packages can be started by the community, eg the mediaproject, or can be adopted by the community, eg the editwizards.
Before an existing package can be adopted by the community, it has to be proposed to the community as an 'Hack' (sometimes followed by an'integration' project) or as a project. The community must decide whether or not they are going to maintain this package. More information about proposing an Hack or a project see guidelines section at mmbase.org http://www.mmbase.org/guidelines
A community package which is going to be started by the community must follow the project proposal guidelines, which can also be found at http://www.mmbase.org/guidelines.
Examples.
Mediaproject, editwizards, taglib, dove, rmmci, xmlimporter, etc.
Community .
MMBase developers community
License .
The MMBase Community Packages must use the MPL-1.0 license. This way sources can be mixed, package and core can be packaged together without any trouble regarding licenses.
Packages being developed by external companies or organizations, which are build upon the MMBase Core. There are two types of 3rd Party Packages: 1. Closed Source Packages 2. Open Source Packages We'd like to encourage all companies to make their packages Open Source. But it's perfectly legal to create a closed source package. If an package is very specialized for one use it's not always useful to make it open source (although the source could be used to learn from).
Community .
These packages are being maintained by the community around the package. This can be a company or companies which initially build the package. This community can be joined by other developers or organizations. It's also possible this community will be small during the initial development and after a period of time other organizations can join the community.
License .
All code submitted must follow the MPL. This may change later, but we want a discussion on licenses before that will happen.
The rest of this document talks about the Open Source MMBase 3rd Party Packages. Stop reading this document if you want to contribute to the MMBase Core or MMBase Community Packages. Go and read How to contribute to the community
To support all different types of packages an infrastructure is needed. An infrastructure contains things like cvs-repository, mailing list, homepage, bugtracker, etc.
Furthermore it's possible not all rules of the MMBase community apply on all of the different packages.
Infrastructure
Most of the tools needed are already present for the MMBase Core. Because the MMBase Community Packages are being developed by the same community, the same tools can be used for these packages.
The 3rd Party MMBase Packages require their own set of tools. Their own mailing list(s), cvs-repository, homepage, bugtracker, documentation, etc. These facilities are not yet in place, but for the moment the 3rd Party Packages are allowed to use the mailing list(s) and cvs-repository present for the Core and Community Packages.
Repository
Everyone is allowed to use the repository, but that does not mean that everyone is allowed to do everything. Below are some guidelines everyone should obey to keep everyone happy. - please be kind and behave - please confine yourself to your part
Mailing lists
When you post to the mailing lists about a specific applications please prefix the subject with the application name in square brackets [].
Homepage, bugtracker, documentation, distributions
The rest of the infrastructure might become available in the future. we still have to work out a suitable solution for these things.
Organization
The MMBase Core and MMBase Community Packages share the same organization and guidelines. Information about this can be found at the MMBase Developers Website http://www.mmbase.org/guidelines
The 3rd Party MMBase Packages will have their own organization and rules, which must be extended from the MMBase Core organization and rules. This way the 3rd Party Packages and the MMBase Core are not too much on two different roads. This is only needed for 3rd Party Packages which want to be recognized as one of the 'official MMBase 3rd Party Packages'.
Notice the difference in the usage core committer and committer in the rules above. Core committers correspond to the role 'committers' as described in the guidelines (http://www.mmbase.org/guidelines). 3rd party committers don't have to be core committers, but then they don't have the priviliges of a core committer.
The core committer who made the vote for the package has to sponsor the package. This means that he is allowed to add committers for that package and he has to watch the commits from these committers.
What does this mean when you want to use the infrastructure of the MMBase community? Send an email to the developers mailing list and request that one of the core committers creates a Vote for you and your package. When the vote passes then you will receive an account and module/directory to commit your package in. Your package will be removed again if you or somebody else is not maintaining it. In the request to the mailing list you have to motivate why you want to make the package open source and share the code with others. A 3rd party package should be useful for others. A package which is highly customized for one person is in most cases not interesting for others. This is very vague, but you can probably judge better if it should be shared then we, as community, can.
The rules above don't require the 3rd party package to use our code conventions and build process, but we recommend 3rd party package do. If a 3rd party package wants to become a community maintained package or wants to be included in the distributtion then the package has to follow them. It is also in your advantage when it uses the mmbase build process, because people are familiar with that.
Committers may lose there status if they break the rules. A committor receives a warning when he breaks a rule (i.e. a CVS rule). After three warnings, Someone May take up contact with the committer to ask him to resign. If the committer is not willing, a unanimous, non-negative call need succeed on the developer list. The committer will be temporarily disallowed CVS access for the duration of the call.
When is software Open Source? There are different definitions in use, but a general definition is provided here: http://www.opensource.org/docs/definition.php
In addition to this, we recommend the following best practices.
Recommendations:
documentation included
license compatible with Mozilla Public License
contact-details available of maintainer
This is part of the MMBase documentation.
For questions and remarks about this documentation mail to: [email protected]