> It's a simpel vote. It is not about changing rules or > requirements, because those are exactly the same as they are > for all code - the fact that I repeated them does not make them 'new'. > All the vote is about is to relax one requirement - which is > the requirement that the code is maintained by the community. > If that is too much trouble to make a vote on, I doubt it > will be on a face-to-face meeting. > > I can delay the end of the vote till thursday, after the > meeting, so people can discuss it as mcuh as they like. > However if you cannot simply make up your mind on the simple > qyestion whether we should allow people access to CVS (yes or > no), then there is imo no point in continuing at all. > > If you don't want people to be able to put their code in CVS > at all, vote -1. If you do think people should get access, > using the current rules and possibly more relaxed rules in > the future, vote +1. If you don't care, abstain.
Okay, lets give it another try why I said no. +1 for CVS access. -1 for the proposed rules. The rules are for non-community-maintained code and they don't have to comply with the mmbase code requirements. -1 because there isn't a text explaining what is offered to 3rd parties when the cvs is open. In my perspective this is a small step for a developer, but a giant step for the community. I agree with Pierre that we don't require a project. There is enough documentation about the subject. The vote is almost there and I want a modified version to pass. We don't need a lot of days of discussion. One or two hours on a shouting meeting is enough. Here is an example of the text which every 3rd party should read before requesting usage of the infrastructure on the mmbase systems. Gerard already did the work for me a year ago so this is nothing new. Is this a good replacement for the vote Pierre made? It is for me. ---------------------------------------------------------------------------- ------------------------------ If you are planning to share code and want to use the MMBase infrastucture, 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. The recommended license for these kind of applications is the MPL or any compatible (BSD-like) license. 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 ================================= - The recommended license for these kind of packages is the MPL or any compatible (BSD-like) license. - The community (core committers) have to vote on allowing the application 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. - 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. 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 to commit your package in. Your package will be removed again if you or somebody else is not maintaining it. 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, the MMC recommends 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
