community-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1125400 - /comdev/site/trunk/content/projectIndependence.mdtext
Date Fri, 20 May 2011 14:02:58 GMT
Author: rgardler
Date: Fri May 20 14:02:57 2011
New Revision: 1125400

CMS commit to community by rgardler

    comdev/site/trunk/content/projectIndependence.mdtext   (with props)

Added: comdev/site/trunk/content/projectIndependence.mdtext
--- comdev/site/trunk/content/projectIndependence.mdtext (added)
+++ comdev/site/trunk/content/projectIndependence.mdtext Fri May 20 14:02:57 2011
@@ -0,0 +1,62 @@
+Title: Project Independence
+Notice:    Licensed to the Apache Software Foundation (ASF) under one
+           or more contributor license agreements.  See the NOTICE file
+           distributed with this work for additional information
+           regarding copyright ownership.  The ASF licenses this file
+           to you under the Apache License, Version 2.0 (the
+           "License"); you may not use this file except in compliance
+           with the License.  You may obtain a copy of the License at
+           .
+           .
+           Unless required by applicable law or agreed to in writing,
+           software distributed under the License is distributed on an
+           KIND, either express or implied.  See the License for the
+           specific language governing permissions and limitations
+           under the License.
+While not all aspects of the Apache Way are practiced the same way by 
+all projects at the ASF, there are a number of rules that Apache 
+projects are required to follow – things like complying with PMC 
+[release voting][1], [legal policy][2], [brand policy][3], 
+using [mailing lists][4], etc., which are [documented in various places][5]. 
+A primary purpose of the basic requirements the ASF places on it’s 
+projects are to help ensure long-lived and stable projects by having 
+a broad enough community to maintain the project even in the potential 
+absence of any individual volunteer or any sea change at a major vendor 
+in that area. The Apache project governance model is explicitly based 
+on a diverse community. This is different from other governance models, 
+like the “benevolent dictator” idea or the often corporate-backed model 
+that Eclipse uses.
+## Apache projects are independent
+This is implicit in the fact that the Project Management Committee (PMC) runs the project,
and the fact that PMC members are expected to contribute to the project as individuals, wearing
their “PMC hat”. The concept of hats means that when a PMC member votes on project
matters, they are casting their vote as an individual acting in the best interests of that
PMC, and not as an employee or representative of some third party. There are also certain
expectations of diversity within a PMC; the board may apply extra scrutiny to PMCs with low
diversity (i.e. PMCs that are dominated by people with a common employer). Similarly, the
ASF does not allow corporations to participate directly in project management, only individuals.
+There are two important aspects to this independence: project management, and project use
by end users.
+## Apache projects are managed independently
+Apache projects should be managed independently, and PMCs must ensure that they are acting
in the best interests of the project as a whole. Note that it is similarly important that
the PMC clearly show this independence within their project community. The perception of existing
and new participants within the community that the PMC is run independently and without favoring
any specific third parties over others is important, to allow new contributors to feel comfortable
both joining the community and contributing their work. A community that obviously favors
one specific vendor in some exclusive way will often discourage new contributors from competing
vendors, which is an issue for the long term health of the project.
+## Apache products may be used independently
+All Apache projects must release their code under the [Apache License][6], which clearly
specifies the minimum restrictions that users of Apache software must agree to. Apache software
is all about being able to use it for virtually whatever our users want: open source, proprietary,
secret: we’re happy to have users take our software (although not our name) for virtually
any purpose. While our legal guidelines allow certain other software licenses to be used for
specific dependencies, the software we release always uses our license.
+Extending this idea, users of Apache software should be able to find our software, learn
how to use it, and actually apply it to all its common use cases solely by going to the Apache
project’s own website. Apache projects should provide sufficient documentation, install
features, basic user help (through mailing lists) and services for the common use cases to
the user, without them having to rely on third parties. It is important that our users can
both make use of our software freely – both in terms of not having to pay for the software,
as well as not having to worry about IP claims or other more restrictive licenses on either
the software or the configurations or other common materials required to actually use the
+## Apache projects are non-commercial
+The ASF’s mission is to produce software for the public good. All Apache software is
always available for free, and solely under the Apache License. While our projects manage
the technical implementation of their individual software products independently, Apache software
is released from the ASF, and is always meant to serve the public good.
+We’re happy to have third parties, including for-profit corporations, take our software
and use it for their own purposes – even when in some cases it may technically compete
with Apache software. However it is important in these cases to ensure that the brand and
reputation of the Apache project is not misused by third parties for their own purposes. It
is important for the longevity and community health of our projects that they get the appropriate
credit for producing our freely available software.
+  [1]:
+  [2]:
+  [3]:
+  [4]:
+  [5]:
+  [6]:
\ No newline at end of file

Propchange: comdev/site/trunk/content/projectIndependence.mdtext
    svn:eol-style = native

View raw message