community-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r894338 - in /websites/staging/community/trunk/content: ./ projectIndependence.html
Date Thu, 16 Jan 2014 01:29:20 GMT
Author: buildbot
Date: Thu Jan 16 01:29:19 2014
New Revision: 894338

Log:
Staging update by buildbot for community

Modified:
    websites/staging/community/trunk/content/   (props changed)
    websites/staging/community/trunk/content/projectIndependence.html

Propchange: websites/staging/community/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Jan 16 01:29:19 2014
@@ -1 +1 @@
-1549816
+1558645

Modified: websites/staging/community/trunk/content/projectIndependence.html
==============================================================================
--- websites/staging/community/trunk/content/projectIndependence.html (original)
+++ websites/staging/community/trunk/content/projectIndependence.html Thu Jan 16 01:29:19
2014
@@ -154,15 +154,19 @@
 </ul>
    <hr>
     <p>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 
+all projects at the ASF, there are a number of rules and policies that Apache 
 projects are required to follow – things like complying with PMC 
 <a href="http://www.apache.org/dev/release.html">release voting</a>, <a href="http://www.apache.org/legal/">legal
policy</a>, <a href="http://www.apache.org/foundation/marks/">brand policy</a>,

 using <a href="http://www.apache.org/dev/#mail">mailing lists</a>, etc., which
are <a href="https://blogs.apache.org/comdev/entry/what_makes_apache_projects_different">documented
in various places</a>. </p>
+<p>A community is not merely a set of rules; it is also a set of behaviors 
+that are expressed by the participants there.  While the ASF is happy to host 
+many different styles of project communities, there are some core behaviors that 
+are expected and required of any Apache project. </p>
 <p>A primary purpose of the basic requirements the ASF places on its 
 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 
+in that area. The <a href="http://www.apache.org/foundation/governance/">Apache project
governance model</a> 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.</p>
@@ -170,12 +174,24 @@ that Eclipse uses.</p>
 <p>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.</p>
 <p>There are two important aspects to this independence: project management, and project
use by end users.</p>
 <h2 id="apache-projects-are-managed-independently">Apache projects are managed independently</h2>
-<p>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.</p>
+<p>Apache projects must 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.</p>
 <h2 id="apache-products-may-be-used-independently">Apache products may be used independently</h2>
 <p>All Apache projects must release their code under the <a href="http://www.apache.org/licenses/LICENSE-2.0.html">Apache
License</a>, 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.</p>
 <p>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 software.</p>
+<h2 id="apache-projects-are-branded-as-apache-projects">Apache projects are branded
as Apache projects</h2>
+<p>Similar to the requirement that users can use Apache projects independently; so
should 
+users understand that when they download and use an Apache product that it is from 
+Apache and not from nor related to any third party.  That is, the user experience when 
+using an Apache project in it's common use cases should clearly show the Apache project 
+branding in the UI or in whatever other ways users would normally interact with the product.
</p>
+<p>Ensuring that Apache projects are branded as Apache projects is critical to the
longevity 
+of our communities.  As users use the software, they may discover bugs, or have ideas for

+improving the software, documentation, or other aspects of the project. When a user chooses

+to share these ideas or improvements, ensuring that the actual product they are using 
+is clearly branded as coming from Apache ensures that they are likely to contribute 
+those ideas and improvements back to Apache and our projects.</p>
 <h2 id="apache-projects-are-non-commercial">Apache projects are non-commercial</h2>
-<p>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.</p>
+<p>The ASF’s mission is to produce software for the public good. All <a href="http://www.apache.org/free/">Apache
software is always available for free</a>, 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.</p>
 <p>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.</p>
   </div>
   



Mime
View raw message