CALL FOR: 3rd-party packages in MMBase CVS
Called by: Nico Klasens Total tally on this call : +13
START OF VOTING: 2005-03-05 19:00 END OF CALL: 2005-03-09 19:00
YEA (13) : Rob van Maris, Daniel Ockeloen, Rob Vermeulen, Marcel Maatkamp, Rico Jansen, Michiel Meeuwissen, Johannes Verelst, Eduard Witteveen, Pierre van Rooden, Kees Jongenburger, Andre van Toly, Gerard van Enk, Mark Huijser
ABSTAIN (0) :
NAY (0) :
VETO (0) :
No votes, assumed abstained (2): Jaco de Groot, Ernst Bunders
This vote succeeded, a CVS repository (name to be decided, 'packages' perhaps?) will be created, and it is now permissable to propose 3rd party applications as packages for this cvs repository.
Tasks:
The release manager (Michiel) is requested to create a new CVS repository.
The CVS Monitor/patch manager (Nico) is requested to place the rules for 3rd party packages in the documentatio tree.
The webmaster (Andre) is requested to place teh rules online, and to look into a way to add package information pages to the website.
The licensing manager (Gerard) is requested to review previous documentation for its accuracy and signal any needed changes.
Pierre van Rooden, Vote Manager & Jommunicator
Nico Klasens wrote:
Hello commiters,
A little more then a week ago Pierre proposed to open up CVS for 3rd party (that is: non community-maintained) packages. I answered his request with a negative response. I do like his intention to give others access and that is why I call this VOTE.
I propose to use the below text for the rules and guidelines for third parties when they want to use the infrastructure on mmbase.org. The text allows third parties to commit their sources to a CVS module, use the mailinglists for the development discussions and use their own standards (we recommend ours). The text also restricts third parties to use the MPL and commit only in their part of the repository.
The text does not commit us to setup a full infrastructure (homepage, bugtracker, documentation, etc). It is not what we are offer right now. This does not mean that we will not do this in the future.
Nico Klasens
START OF VOTING: 2005-03-05 17:00 END OF CALL: 2005-03-09 17:00
[_] +1 (YES) [_] +0 (ABSTAIN ) [_] -1 (NO), because : [_] VETO, because:
---------------------------------------------------------------------------- ------- 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.
Core and Applications =====================
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.
[architecture http://www.mmbase.org/mmdocs/general/media/architecture.png]
This section discusses the different parts, the community around these parts, the licenses that are being used or can be used, etc.
MMBase Core -----------
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.
MMBase Community Packages -----------------------------
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.
MMBase 3rd Party Packages -------------------------
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 @@TODO@@ url to contribute.html
Infrastructure and Organization ===============================
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'.
How to become a 3rd Party Package =================================
- All code submitted must follow the MPL. This may change later, but we want a discussion on licenses before that will happen.
- Third party code must be subject to code conventions, preferrably ours.
This is a pragmatic requirment so contributors know how they have to
submit
their patch.
- The community (core committers) have to vote on allowing the package in
CVS.
The Vote has to be made by an existing core committer.
- A committer (not necessarily the same person who made the vote) needs to maintain the code. It is possible to make someone a committer for the
express
purpose of maintaining 3rd-party code.
- As such, the package needs to have a committer supporting it.
- A package that is not maintained can be removed from CVS if nobody desires
to
maintain it further.
- The release manager decides which packages are included in a distribution.
Packages that follow the build process as used by the core applications
are more
likely to be taken into consideration.
- The core committers decide which package gets the status
'community-maintained'.
A community-maintained package no longer requires a specific committer to maintain it, though a core committer will be typically assigned to
overview
and approve changes.
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.
Open Source
===========
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
_______________________________________________ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Anything worth doing is worth overdoing." _______________________________________________ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
