1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
[[preamble]]
Overview
--------
This document provides you with the information that you need to
create a new {forgeName} open source project or become a committer
on an existing one.
ifeval::["{forgeName}"!="Eclipse"]
While this document is focused on {forgeName}, it makes several
"Eclipse" references, including the 'Eclipse Foundation',
'Eclipse Development Process', and 'Eclipse Management Organization'.
The Eclipse Foundation is the legal entity that manages the operations
of the {forgeName} working group, software development forge, and community.
Many of the provided services and contacts are so-named on
that basis.
endif::[]
The {edpUrl}[Eclipse Development Process] (EDP) is the foundational
document for {forgeName} projects and committers. It describes the
manner in which we do open source software. The Eclipse Development
Process does not prescribe any particular development methodology;
it is more concerned with the larger-scale aspects of open source
project lifecycle, including such things as reviews, processes for
running votes and elections, bringing new committers onto a project, etc.
This document will elaborate on some key points of the Eclipse Development
Process.
[[preamble-principles]]
Principles
~~~~~~~~~~
Four basic principles lie at the heart of the Eclipse Development Process:
* Transparency;
* Openness;
* Meritocracy; and
* Vendor neutrality
We refer to the first three as the "open source rules of engagement".
To operate with *transparency*, a project's discussions, minutes, deliberations,
project plans, plans for new features, and other artifacts are open, public,
and easily accessible.
*Openness* at {forgeName} means quite a lot more than "open book" (which is
really a synonym for transparent). The project is open to all;
{forgeName} provides the same opportunity to all. Everyone participates
with the same rules; there are no rules to exclude any potential contributors
which include, of course, direct competitors in the marketplace.
{forgeName} is a *meritocracy*. The more that somebody contributes, the more
responsibility they will earn. A pattern of quality contribution to a project
may lead to an invitation to join the project as a committer. Leadership roles
in {forgeName} are also merit-based and earned by peer acclaim. Merit must be
demonstrated in publicly-accessible forums. Committers and project leads are
added to a project via <<elections, election>>.
NOTE: Employment status has no bearing at whether or not somebody can participate
in an open source project at {forgeName}. Employment does not guarantee
committer status; committer status must be earned by everybody.
*Vendor neutrality* is similar to openness in that it's concerned with
maintaining a level playing field. No vendor is permitted to dominate a project,
and nobody can be excluded from participating
in a project based on their employment status. While
project resources will contain copyright statements that assert ownership of
various assets by individual vendors, the project itself must remain vendor
neutral.
Quality and intellectual property cleanliness are also important principles.
*Quality* means extensible frameworks and exemplary tools developed in an open,
inclusive, and predictable process involving the entire community. From the
consumption perspective, {forgeName} quality means good for users (exemplary tools
are cool/compelling to use, indicative of what is possible) and ready for
use by adopters. From the creation perspective, {forgeName} quality means working
with a transparent and open process, open and welcoming to participation from
technical leaders, regardless of affiliation.
*<<ip,Intellectual property>>* (IP) is any artifact that is made available from
a {forgeName} server (this includes source code management systems, the website,
and the downloads server). Artifacts include (but are not limited to) such things
as source code, images, XML and configuration files, documentation, and more.
Strict rules govern the way that we manage IP and your responsibilities
as a committer.
Code produced by an {forgeName} project is used by organizations to build products.
These adopters of {forgeName} technology need to have some assurance that the IP they're
basing their products on is *clean*: the organization or individuals who claim
copyright of the code are the legitimate copyright holders, and the copyright
holders legitimately agree to make the code available under the license(s) that
the project works under. As a committer, you must be careful that you do not copy
code and inadvertently claim it as your own.
|
