community-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From curc...@apache.org
Subject svn commit: r1558645 - /comdev/site/trunk/content/projectIndependence.mdtext
Date Thu, 16 Jan 2014 01:29:16 GMT
Author: curcuru
Date: Thu Jan 16 01:29:15 2014
New Revision: 1558645

URL: http://svn.apache.org/r1558645
Log:
Add project UI branding requirement; tweaks; add intro para; add links to governance and free
sections

Modified:
    comdev/site/trunk/content/projectIndependence.mdtext

Modified: comdev/site/trunk/content/projectIndependence.mdtext
URL: http://svn.apache.org/viewvc/comdev/site/trunk/content/projectIndependence.mdtext?rev=1558645&r1=1558644&r2=1558645&view=diff
==============================================================================
--- comdev/site/trunk/content/projectIndependence.mdtext (original)
+++ comdev/site/trunk/content/projectIndependence.mdtext Thu Jan 16 01:29:15 2014
@@ -17,16 +17,21 @@ Notice:    Licensed to the Apache Softwa
            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 
+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 
 [release voting][1], [legal policy][2], [brand policy][3], 
 using [mailing lists][4], etc., which are [documented in various places][5]. 
 
+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. 
+
 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 [Apache project governance model][7] 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.
@@ -39,7 +44,7 @@ There are two important aspects to this 
 
 ## 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 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.
 
 ## Apache products may be used independently
 
@@ -47,9 +52,24 @@ All Apache projects must release their c
 
 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.
 
+## Apache projects are branded as Apache projects
+
+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.

+
+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.
+
 ## 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.
+The ASF’s mission is to produce software for the public good. All [Apache software is
always available for free][8], 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.
 
@@ -59,4 +79,6 @@ We’re happy to have third parties, 
   [3]: http://www.apache.org/foundation/marks/
   [4]: http://www.apache.org/dev/#mail
   [5]: https://blogs.apache.org/comdev/entry/what_makes_apache_projects_different
-  [6]: http://www.apache.org/licenses/LICENSE-2.0.html
\ No newline at end of file
+  [6]: http://www.apache.org/licenses/LICENSE-2.0.html
+  [7]: http://www.apache.org/foundation/governance/
+  [8]: http://www.apache.org/free/
\ No newline at end of file



Mime
View raw message