Re: A maturity model for Apache projects

[Shane Curcuru]

On 1/20/15 9:02 AM, Bertrand Delacretaz wrote:
> Hi Justin,
> 
> On Sat, Jan 17, 2015 at 7:37 AM, Justin Mclean  
> wrote:
>> ...Perhaps change CD10 to this?
>> The project produces royalty free Open Source software
> 
> "for distribution to the public at no charge" is straight from the
> from the ASF Bylaws at http://apache.org/foundation/bylaws.html so I'm
> not keen on changing that.
> 
> I have added a footnote to CD10 that explains this, and added
> http://opensource.org/osd to the list of links at the end of the page.
> 
> Does that work for you?
> 
> -Bertrand
> 

A longer explanation of this point, which I use frequently:

  https://www.apache.org/free/

Thanks Bertrand for keeping this fairly generic, while still being clear
that it is clearly the Apache model, not a completely general one.

- Shane

Re: A maturity model for Apache projects

[Shane Curcuru]

On 1/9/15 9:23 AM, Rich Bowen wrote:
> 
> 
> On 01/07/2015 04:43 AM, Scott Wilson wrote:
>> I think we also need to discuss whether we expect projects to
>> undertake self-evaluation and reflection, or whether we'd have a
>> process of review involving peers, mentors, shepherds etc.
> 
> No, I absolutely don't want to create another stack of overhead, or Yet
> Another hoop to jump through, as you said.
> 
> I think "directed self-evaluation" is the way I'd want to go - one or
> two persons from ComDev, in conjunction with two or three persons from
> the PMC, doing an evaluation. I imagine this as a function of ComDev,
> not of the board. That is, it's a community/project strengthening
> exercise, not a Big Hammer.
> 
Indeed, this whole process is merely coming up with a well-thought out
document that we hope helps people who are interested in it.  As I see
this, it's not any explicit process burden for podlings or TLPs (or
pTLPs, if we ever have them).

The board and project reporting schedules, and the list of minimal
project requirements are what Apache projects do have to follow/do/be.

  https://www.apache.org/dev/project-requirements.html

As always, it will be good to put some concise yet clear explanations
and links between the different documents.

- Shane

Re: A maturity model for Apache projects

[Shane Curcuru]

On 1/8/15 6:53 AM, Jim Jagielski wrote:
> But that then provides the ability to create a larger eco-system of
> binary providers.

I know I'm late to the party, but are we advocating that only having
binaries provided by third parties is a good thing, or a bad thing?

We provide software for the public good.  Much of the software we
provide happens to be fairly technical, but even so that does not mean
that most of our actual users are compiling and building everything
themselves.  I'd even bet that the majority of our individual direct
users actually grab binary or jar releases rather than original sources
for building.

I suppose CD30 covers this in the basic case: build tools - to produce
the entire project from the sources - should be widely available.  But I
definitely think that's important to consider, to make our software
truly useful for users.

- Shane
> 
>> On Jan 6, 2015, at 3:45 PM, Nicolas Lalevée
>>  wrote:
>> 
>> I would add something about the build of the sources. Because
>> having sources without having a repeatable build or having no clue
>> about how to build it, it makes the sources quite useless.
>> 
>> I had some troubles recently with a project. Its build depends on a
>> resource which is not available anymore. And I find it quite
>> shameful since it was a project about a build system.
>> 
>> Nicolas
>> 
>>> On 2015-01-06 18:28, Bertrand Delacretaz wrote:
 Hi,
 
 Creating such a model has been on my todo list for ages, and in
 a related discussion on board@ people seem to agree that having
 this can be useful.
 
 So let's start - here's my rough initial list of items:
 
 Code: open, discoverable, fully public history, documented
 provenance Quality: security, backwards compatibility, etc 
 Contributions: welcome from anyone based on technical quality 
 License: Apache License, dependencies must not put additional
 restrictions Community: inclusive, meritocratic, no dictators,
 clear documented path to entry Discussions and decisions:
 asynchronous, in a single central place, archived Decision
 making: consensus, votes if needed, technical vetoes in the
 worst case Independence: from any corporate or organizational
 influence Releases: source code only, notices, long-lived
 release format
 
 Related efforts, inspiration:
 
 http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/


 
http://rfc.zeromq.org/spec:16
 
 -Bertrand
>> 
> 

Re: A maturity model for Apache projects

[Shane Curcuru]

Apologies for coming in late, my dev@ mail wasn't getting read, oops!

Have people considered:

* What is the definition of "Open Source"?  Shouldn't we either define
this in detail, or explicitly reference the well-known OSI definition?

* Code

Adding a point noting that the project produces software that does some
useful function on it's own?  I.e. that the software product produced is
useful to some users as-is, without requiring any other software, in
particular a single vendor's software?

I.e a mature Apache project wouldn't produce some blank framework that
doesn't actually run or produce output without some vendors own plugin
to make it work. 

* LC40 s/bound by/agree to and are bound by/ to emphasize this point?

* QU40 - this is a great point, and helped me understand the difference
between this model and other requirements/docs.  I.e. a "mature Apache
project" will do this, but newer TLPs or Incubator podlings or pTLPs may
well not do this - which is fine, as long as it's clear to users.

* CS10 - am I the only one who finds the wording here (and in CO60) a
little confusing?  Or rather: should we publish this document as
explicitly applies to Apache projects (i.e. clarify where we mean
committers/PMC members in terms of specific roles) or should we keep it
more generic (and call them contributors, etc.)  I.e. for some projects,
committers do have decision powers over code changes within the project
- but not on personnel changes (which is only the PMC).

* CS40 should be updated to directly refer to the Voting rules.

* CS50 should be updated to (somehow, I'm not a wordsmith today) to
ensure the community has time to respond to synopses of decisions made
off-list before irrevocable changes are made.  I.e. if you have a big
meetup and decide to do X, post the notes and decision on the list - and
then wait 72 hours to allow new feedback from the list to shape how X
gets finished.

* IN20 should this be updated to note something like "and decisions made
are made for the good of the project as a whole, and not outside
corporations or employers"?

This is tricky to word correctly, because many employees may have to
fundamentally act in their employer's interests in financial or other
legal contexts.  But some sort of hint or emphasis on making decisions
for the good of the project as a whole and all of it's users is an
important point to make somehow.

Thanks,
- Shane

 

Re: Oaths and Anthems (was Re: A maturity model for Apache projects)

[Kay Schenk]

VERY good! :)

On 01/16/2015 09:51 AM, Alex Harui wrote:
> I think Bertrand’s document is coming along nicely.
> 
> This is half serious and half for fun, but while it will be great to have
> a maturity model and top-level authoritative documents on the Apache Way,
> to me, what would also help is a way to make important things memorizable.
>  I sure hope I don’t have to memorize every word of Bertrand’s document
> and only use it as a reference.
> 
> As I mentioned on one of these threads, the Boy Scouts (and Girl Scouts)
> have oaths and “laws” that you have to memorize to be officially accepted
> into their communities.  IMO, these very short “documents" try to cement
> certain keywords in your head so that you at least realize that certain
> topics are important to that organization.  It isn’t out to be detailed in
> any way.  That’s what these other documents are for.
> 
> So, I offer below some oaths, “laws of Apache” and even an anthem derived
> mostly by culling words from Bertrand’s document.  I left out anything
> from Bertrand’s document like quality and security that I felt folks
> should already be practicing in their day job or in other open source
> organizations.  I wanted the fewest words so that it could be more easily
> memorized and cement in your head the things that make Apache different
> from your day job and other open source groups.
> 
> Hope you like it.
> -Alex
> 
> The Committer Oath
> I, _, promise to properly record the licensing and copyright of
> any code I commit, treat all committers equally, use the mailing list for
> communicating with others, only veto code with technical explanations,
> help users, fix bugs, and represent myself and not my employer in my
> actions.
> 
> 
> The PMC Member Oath (assumes you’ve memorized the Committer Oath already).
> I, _, promise to ensure the correct licensing and copyright of the
> content of releases, treat all PMC members and committers equally, seek
> consensus before voting, identify others whose meritorious actions deserve
> inclusion as committers or PMC members, and use the private mailing list
> only for discussions about people,
> 
> - The Laws of Apache -
> 
> 
> Apache Releases:
> -Are free
> -Are PGP-signed
> -On dist.apache.org
> -Approved by majority vote
> -Do not contain compiled code.
> -Contain scripts to compile any source that needs compilation.
> -Contain correct LICENSE and NOTICE files
> 
> 
> Apache Source Code:
> -Is recorded in SVN or Git.
> -Is not on GitHub (that’s a copy).
> -Is available to the public
> -Contains correct headers
> -Is licensed under an approved license
> -Does not depend on external code under certain licenses.
> 
> 
> Apache Binary Packages:
> -make the Release Manager liable
> -contain LICENSE and NOTICE
> 
> 
> The Apache Anthem (to the tune of “My Country Tis of Thee” or “God Save
> the Queen”)
> 
> A-pach-e code for free
> Source zip and tar.gz
> Signed PGP.
> 
> License and Copyright
> NOTICE files in sight.
> 3 plus-1 vote majority
> No binary
> 
> Please get those headers right
> Plus how to build it right
> Check dependencies
> 
> Source in Subversion tree
> Or Git Repositry
> On servers in Apa-a-che
> Legal history
> 
> 
> 
> 

-- 
-
MzK

"An old horse for a long, hard road,
 a young pony for a quick ride."
 -- Texas Bix Bender

Re: A maturity model for Apache projects

[Dave Fisher]

Hi -

CD20 should refer to the source code repository existing in Apache 
Infrastructure.

"The project's code is easily discoverable and publicly accessible from an ASF 
hosted repository."

Regards,
Dave

On Jan 20, 2015, at 7:50 PM, Antoine Levy Lambert wrote:

> Sure, this should be on our web site, thanks Bertrand for writing this 
> maturity model.
> 
> Antoine
> On Jan 20, 2015, at 9:44 AM, Bertrand Delacretaz  
> wrote:
> 
>> Hi,
>> 
>> Thanks to everybody who contributed, I think
>> https://wiki.apache.org/incubator/ApacheProjectMaturityModel is ready
>> for prime time, as a first version that might still evolve.
>> 
>> (except maybe Justin's comments about CD10, let's see how you like the
>> current wording)
>> 
>> I suggest moving it under https://www.apache.org/dev/ alongside
>> https://www.apache.org/dev/project-requirements which is more about
>> processes, and link both documents to each other. WDYT?
>> 
>> -Bertrand
> 

Re: A maturity model for Apache projects

[Antoine Levy Lambert]

Sure, this should be on our web site, thanks Bertrand for writing this maturity 
model.

Antoine
On Jan 20, 2015, at 9:44 AM, Bertrand Delacretaz  wrote:

> Hi,
> 
> Thanks to everybody who contributed, I think
> https://wiki.apache.org/incubator/ApacheProjectMaturityModel is ready
> for prime time, as a first version that might still evolve.
> 
> (except maybe Justin's comments about CD10, let's see how you like the
> current wording)
> 
> I suggest moving it under https://www.apache.org/dev/ alongside
> https://www.apache.org/dev/project-requirements which is more about
> processes, and link both documents to each other. WDYT?
> 
> -Bertrand

Re: A maturity model for Apache projects

[Roberto Galoppini]

On Fri, Jan 9, 2015 at 3:23 PM, Rich Bowen  wrote:

>
>
> On 01/07/2015 04:43 AM, Scott Wilson wrote:
>
>> I think we also need to discuss whether we expect projects to undertake
>> self-evaluation and reflection, or whether we'd have a process of review
>> involving peers, mentors, shepherds etc.
>>
>
> No, I absolutely don't want to create another stack of overhead, or Yet
> Another hoop to jump through, as you said.
>
> I think "directed self-evaluation" is the way I'd want to go - one or two
> persons from ComDev, in conjunction with two or three persons from the PMC,
> doing an evaluation. I imagine this as a function of ComDev, not of the
> board. That is, it's a community/project strengthening exercise, not a Big
> Hammer.
>

Along this line - self-evaluation - sometimes ago I designed a methodology
and a tool for that, mostly based on QSOS (*).
Recently it has been distributed with an open source license, and more
important it has been generalized so that it could be used to run
different  methodologies (included extending the original one).

Another set od useful resources for measuring open source are Grimoire
metrics tools (**), partially included in Apache Allura.

Roberto

(*) http://www.qsos.org/ | used metrics explained here:
http://sosopensource.com/395.html | downloads:
https://opensourceprojects.eu/p/osp/osseval/wiki/OSSEval/
(**) http://blog.bitergia.com/tag/metrics-grimoire/






>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

On Tue, Jan 20, 2015 at 9:38 PM, Justin Mclean  wrote:
> ...No a real issue either way, just pointing out it might hinder adoption 
> outside of Apache...

Right - people are free to pick and choose anyway, outside of Apache.

-Bertrand

Re: A maturity model for Apache projects

[Justin Mclean]

Hi,

> "for distribution to the public at no charge" is straight from the
> from the ASF Bylaws at http://apache.org/foundation/bylaws.html so I'm
> not keen on changing that.

Understand. No a real issue either way, just pointing out it might hinder 
adoption outside of Apache.

Thanks,
Justin

RE: A maturity model for Apache projects

[Dennis E. Hamilton]

+1

Concerning CD10, I think the language of the statement is correct, but the 
footnote is not helpful, even though also correct.

I think the problem might be context.  For the footnote, try, "It is ASF policy 
that all software created and maintained by an Apache Project is available from 
the project to the public at no charge (section 6.3 of 
http://apache.org/foundation/bylaws.html).  Third-party actions are governed by 
the license."  

The third-party observation is technically unnecessary, except it deals with 
the obvious questions that arise about downstream behavior.

 - Dennis

PS: I confess that I had not observed how much has been done at a.o/dev.  
Stuff's happening!  I will start referring folks to it.  This is a great 
resource for podlings and first-time initial committers (and those of us who 
have not been paying attention).


-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Tuesday, January 20, 2015 06:45
To: Bertrand Delacretaz
Cc: dev
Subject: Re: A maturity model for Apache projects

Hi,

Thanks to everybody who contributed, I think
https://wiki.apache.org/incubator/ApacheProjectMaturityModel is ready
for prime time, as a first version that might still evolve.

(except maybe Justin's comments about CD10, let's see how you like the
current wording)

I suggest moving it under https://www.apache.org/dev/ alongside
https://www.apache.org/dev/project-requirements which is more about
processes, and link both documents to each other. WDYT?

-Bertrand

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

Hi,

Thanks to everybody who contributed, I think
https://wiki.apache.org/incubator/ApacheProjectMaturityModel is ready
for prime time, as a first version that might still evolve.

(except maybe Justin's comments about CD10, let's see how you like the
current wording)

I suggest moving it under https://www.apache.org/dev/ alongside
https://www.apache.org/dev/project-requirements which is more about
processes, and link both documents to each other. WDYT?

-Bertrand

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

On Sat, Jan 17, 2015 at 8:09 AM, Lefty Leverenz  wrote:
> Some trivial edits...

Thanks very much! Trivial edits give one that warm fuzzy feeling that
the content is generally ok ;-)

-Bertrand

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

Hi Justin,

On Sat, Jan 17, 2015 at 7:37 AM, Justin Mclean  wrote:
> ...Perhaps change CD10 to this?
> The project produces royalty free Open Source software

"for distribution to the public at no charge" is straight from the
from the ASF Bylaws at http://apache.org/foundation/bylaws.html so I'm
not keen on changing that.

I have added a footnote to CD10 that explains this, and added
http://opensource.org/osd to the list of links at the end of the page.

Does that work for you?

-Bertrand

Re: Oaths and Anthems (was Re: A maturity model for Apache projects)

[Mattmann, Chris A (3980)]

+1 really enjoyed that Alex.

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++






-Original Message-
From: jan i 
Reply-To: "dev@community.apache.org" 
Date: Friday, January 16, 2015 at 1:23 PM
To: "dev@community.apache.org" 
Subject: Re: Oaths and Anthems (was Re: A maturity model for Apache
projects)

>On Friday, January 16, 2015, Dan Haywood 
>wrote:
>
>> On 16 January 2015 at 17:51, Alex Harui >>
>> wrote:
>>
>> >
>> > Hope you like it.
>> >
>>
>> I like it. A lot.  And laugh-out loud funny (well, I thought, anyway).
>>
>> I'm imagining everyone attending a barcamp or ApacheCon solemnly
>>standing
>> up and repeating that oath...
>>
>> Good job, +1
>
>
>very good job indeed.looking forward to see it practiced in Austin.
>
>rgds
>jan i
>
>
>>
>> Dan
>>
>>
>>
>>
>> > -Alex
>> >
>> > The Committer Oath
>> > I, _, promise to properly record the licensing and copyright
>>of
>> > any code I commit, treat all committers equally, use the mailing list
>>for
>> > communicating with others, only veto code with technical explanations,
>> > help users, fix bugs, and represent myself and not my employer in my
>> > actions.
>> >
>> >
>> > The PMC Member Oath (assumes you’ve memorized the Committer Oath
>> already).
>> > I, _, promise to ensure the correct licensing and copyright of
>> the
>> > content of releases, treat all PMC members and committers equally,
>>seek
>> > consensus before voting, identify others whose meritorious actions
>> deserve
>> > inclusion as committers or PMC members, and use the private mailing
>>list
>> > only for discussions about people,
>> >
>> > - The Laws of Apache -
>> >
>> >
>> > Apache Releases:
>> > -Are free
>> > -Are PGP-signed
>> > -On dist.apache.org
>> > -Approved by majority vote
>> > -Do not contain compiled code.
>> > -Contain scripts to compile any source that needs compilation.
>> > -Contain correct LICENSE and NOTICE files
>> >
>> >
>> > Apache Source Code:
>> > -Is recorded in SVN or Git.
>> > -Is not on GitHub (that’s a copy).
>> > -Is available to the public
>> > -Contains correct headers
>> > -Is licensed under an approved license
>> > -Does not depend on external code under certain licenses.
>> >
>> >
>> > Apache Binary Packages:
>> > -make the Release Manager liable
>> > -contain LICENSE and NOTICE
>> >
>> >
>> > The Apache Anthem (to the tune of “My Country Tis of Thee” or “God
>>Save
>> > the Queen”)
>> >
>> > A-pach-e code for free
>> > Source zip and tar.gz
>> > Signed PGP.
>> >
>> > License and Copyright
>> > NOTICE files in sight.
>> > 3 plus-1 vote majority
>> > No binary
>> >
>> > Please get those headers right
>> > Plus how to build it right
>> > Check dependencies
>> >
>> > Source in Subversion tree
>> > Or Git Repositry
>> > On servers in Apa-a-che
>> > Legal history
>> >
>> >
>> >
>> >
>> >
>>
>
>
>-- 
>Sent from My iPad, sorry for any misspellings.

Re: Oaths and Anthems (was Re: A maturity model for Apache projects)

[Vincent Keunen]

Excellent!

As I see: "Scout un jour, scout toujours!" seems to be true in several
cultures. ;-)

Just as the two Steves did not anticipate that the "Apple" company they
initially created for computers would someday be involved with music (and
the legal problems with the "Apple" of the Beatles), I bet that Baden
Powell did not anticipate that his initiative would be used for Open Source
Software the Apache Way some day... Ah, innovation. Ah, building on the
shoulders of giants.

+1

On Friday, January 16, 2015, Alex Harui  wrote:

> I think Bertrand’s document is coming along nicely.
>
> This is half serious and half for fun, but while it will be great to have
> a maturity model and top-level authoritative documents on the Apache Way,
> to me, what would also help is a way to make important things memorizable.
>  I sure hope I don’t have to memorize every word of Bertrand’s document
> and only use it as a reference.
>
> As I mentioned on one of these threads, the Boy Scouts (and Girl Scouts)
> have oaths and “laws” that you have to memorize to be officially accepted
> into their communities.  IMO, these very short “documents" try to cement
> certain keywords in your head so that you at least realize that certain
> topics are important to that organization.  It isn’t out to be detailed in
> any way.  That’s what these other documents are for.
>
> So, I offer below some oaths, “laws of Apache” and even an anthem derived
> mostly by culling words from Bertrand’s document.  I left out anything
> from Bertrand’s document like quality and security that I felt folks
> should already be practicing in their day job or in other open source
> organizations.  I wanted the fewest words so that it could be more easily
> memorized and cement in your head the things that make Apache different
> from your day job and other open source groups.
>
> Hope you like it.
> -Alex
>
> The Committer Oath
> I, _, promise to properly record the licensing and copyright of
> any code I commit, treat all committers equally, use the mailing list for
> communicating with others, only veto code with technical explanations,
> help users, fix bugs, and represent myself and not my employer in my
> actions.
>
>
> The PMC Member Oath (assumes you’ve memorized the Committer Oath already).
> I, _, promise to ensure the correct licensing and copyright of the
> content of releases, treat all PMC members and committers equally, seek
> consensus before voting, identify others whose meritorious actions deserve
> inclusion as committers or PMC members, and use the private mailing list
> only for discussions about people,
>
> - The Laws of Apache -
>
>
> Apache Releases:
> -Are free
> -Are PGP-signed
> -On dist.apache.org
> -Approved by majority vote
> -Do not contain compiled code.
> -Contain scripts to compile any source that needs compilation.
> -Contain correct LICENSE and NOTICE files
>
>
> Apache Source Code:
> -Is recorded in SVN or Git.
> -Is not on GitHub (that’s a copy).
> -Is available to the public
> -Contains correct headers
> -Is licensed under an approved license
> -Does not depend on external code under certain licenses.
>
>
> Apache Binary Packages:
> -make the Release Manager liable
> -contain LICENSE and NOTICE
>
>
> The Apache Anthem (to the tune of “My Country Tis of Thee” or “God Save
> the Queen”)
>
> A-pach-e code for free
> Source zip and tar.gz
> Signed PGP.
>
> License and Copyright
> NOTICE files in sight.
> 3 plus-1 vote majority
> No binary
>
> Please get those headers right
> Plus how to build it right
> Check dependencies
>
> Source in Subversion tree
> Or Git Repositry
> On servers in Apa-a-che
> Legal history
>
>
>
>
>

-- 
Vincent Keunen
How to contact me 
vinc...@keunen.net
about.me 

Re: A maturity model for Apache projects

[Lefty Leverenz]

Some trivial edits:

LC10
The code is released under the Apache License, version 2.0  <*needs
terminal period*>

QU20
The projects puts a very high priority on producing secure software.
<"project puts">

*Consensus building*   <"Consensus *B*uilding" to match init caps on
"License and Copyright">

*Optional:*  <*change " - " to " -- " in CS10 and RE40*>

*Utterly trivial:*  <*space before footnote 3 in RE10, or remove spaces
before all other footnotes*>


-- Lefty

On Fri, Jan 16, 2015 at 10:37 PM, Justin Mclean 
wrote:

> Hi,
>
> > I thought that was part of the Open Source definition?
>
> Not quite (AFAIK), there's no royalties allowed on redistribution but that
> doesn't mean you can't charge for it either initially or when
> redistributing it as part of a bundle.
>
> "The license shall not restrict any party from selling or giving away the
> software as a component of an aggregate software distribution containing
> programs from several different sources. The license shall not require a
> royalty or other fee for such sale." [1]
>
> Perhaps change CD10 to this?
>
> The project produces royalty free Open Source software.
>
> Thanks,
> Justin
>
> 1.http://opensource.org/osd

Re: A maturity model for Apache projects

[Justin Mclean]

Hi,

> I thought that was part of the Open Source definition?

Not quite (AFAIK), there's no royalties allowed on redistribution but that 
doesn't mean you can't charge for it either initially or when redistributing it 
as part of a bundle.

"The license shall not restrict any party from selling or giving away the 
software as a component of an aggregate software distribution containing 
programs from several different sources. The license shall not require a 
royalty or other fee for such sale." [1]

Perhaps change CD10 to this?

The project produces royalty free Open Source software.

Thanks,
Justin

1.http://opensource.org/osd

Re: A maturity model for Apache projects

[Branko Čibej]

On 16.01.2015 00:40, Justin Mclean wrote:
> Hi,
>
> Some (very) minor things.
>
> CD10 - "distributed at no charge to the public." while this may be true at 
> Apache it doesn't have to be the case. 3rd parties wanting to this model may 
> find this a stumbling block.

I thought that was part of the Open Source definition? That there's
nothing stopping anyone from making enhanced packages or installers or
whatnot that they then charge for, but the original source must be
available free of charge?

-- Brane

Re: Oaths and Anthems (was Re: A maturity model for Apache projects)

[jan i]

On Friday, January 16, 2015, Dan Haywood 
wrote:

> On 16 January 2015 at 17:51, Alex Harui >
> wrote:
>
> >
> > Hope you like it.
> >
>
> I like it. A lot.  And laugh-out loud funny (well, I thought, anyway).
>
> I'm imagining everyone attending a barcamp or ApacheCon solemnly standing
> up and repeating that oath...
>
> Good job, +1


very good job indeed.looking forward to see it practiced in Austin.

rgds
jan i


>
> Dan
>
>
>
>
> > -Alex
> >
> > The Committer Oath
> > I, _, promise to properly record the licensing and copyright of
> > any code I commit, treat all committers equally, use the mailing list for
> > communicating with others, only veto code with technical explanations,
> > help users, fix bugs, and represent myself and not my employer in my
> > actions.
> >
> >
> > The PMC Member Oath (assumes you’ve memorized the Committer Oath
> already).
> > I, _, promise to ensure the correct licensing and copyright of
> the
> > content of releases, treat all PMC members and committers equally, seek
> > consensus before voting, identify others whose meritorious actions
> deserve
> > inclusion as committers or PMC members, and use the private mailing list
> > only for discussions about people,
> >
> > - The Laws of Apache -
> >
> >
> > Apache Releases:
> > -Are free
> > -Are PGP-signed
> > -On dist.apache.org
> > -Approved by majority vote
> > -Do not contain compiled code.
> > -Contain scripts to compile any source that needs compilation.
> > -Contain correct LICENSE and NOTICE files
> >
> >
> > Apache Source Code:
> > -Is recorded in SVN or Git.
> > -Is not on GitHub (that’s a copy).
> > -Is available to the public
> > -Contains correct headers
> > -Is licensed under an approved license
> > -Does not depend on external code under certain licenses.
> >
> >
> > Apache Binary Packages:
> > -make the Release Manager liable
> > -contain LICENSE and NOTICE
> >
> >
> > The Apache Anthem (to the tune of “My Country Tis of Thee” or “God Save
> > the Queen”)
> >
> > A-pach-e code for free
> > Source zip and tar.gz
> > Signed PGP.
> >
> > License and Copyright
> > NOTICE files in sight.
> > 3 plus-1 vote majority
> > No binary
> >
> > Please get those headers right
> > Plus how to build it right
> > Check dependencies
> >
> > Source in Subversion tree
> > Or Git Repositry
> > On servers in Apa-a-che
> > Legal history
> >
> >
> >
> >
> >
>


-- 
Sent from My iPad, sorry for any misspellings.

Re: Oaths and Anthems (was Re: A maturity model for Apache projects)

[Dan Haywood]

On 16 January 2015 at 17:51, Alex Harui  wrote:

>
> Hope you like it.
>

I like it. A lot.  And laugh-out loud funny (well, I thought, anyway).

I'm imagining everyone attending a barcamp or ApacheCon solemnly standing
up and repeating that oath...

Good job, +1

Dan




> -Alex
>
> The Committer Oath
> I, _, promise to properly record the licensing and copyright of
> any code I commit, treat all committers equally, use the mailing list for
> communicating with others, only veto code with technical explanations,
> help users, fix bugs, and represent myself and not my employer in my
> actions.
>
>
> The PMC Member Oath (assumes you’ve memorized the Committer Oath already).
> I, _, promise to ensure the correct licensing and copyright of the
> content of releases, treat all PMC members and committers equally, seek
> consensus before voting, identify others whose meritorious actions deserve
> inclusion as committers or PMC members, and use the private mailing list
> only for discussions about people,
>
> - The Laws of Apache -
>
>
> Apache Releases:
> -Are free
> -Are PGP-signed
> -On dist.apache.org
> -Approved by majority vote
> -Do not contain compiled code.
> -Contain scripts to compile any source that needs compilation.
> -Contain correct LICENSE and NOTICE files
>
>
> Apache Source Code:
> -Is recorded in SVN or Git.
> -Is not on GitHub (that’s a copy).
> -Is available to the public
> -Contains correct headers
> -Is licensed under an approved license
> -Does not depend on external code under certain licenses.
>
>
> Apache Binary Packages:
> -make the Release Manager liable
> -contain LICENSE and NOTICE
>
>
> The Apache Anthem (to the tune of “My Country Tis of Thee” or “God Save
> the Queen”)
>
> A-pach-e code for free
> Source zip and tar.gz
> Signed PGP.
>
> License and Copyright
> NOTICE files in sight.
> 3 plus-1 vote majority
> No binary
>
> Please get those headers right
> Plus how to build it right
> Check dependencies
>
> Source in Subversion tree
> Or Git Repositry
> On servers in Apa-a-che
> Legal history
>
>
>
>
>

Oaths and Anthems (was Re: A maturity model for Apache projects)

[Alex Harui]

I think Bertrand’s document is coming along nicely.

This is half serious and half for fun, but while it will be great to have
a maturity model and top-level authoritative documents on the Apache Way,
to me, what would also help is a way to make important things memorizable.
 I sure hope I don’t have to memorize every word of Bertrand’s document
and only use it as a reference.

As I mentioned on one of these threads, the Boy Scouts (and Girl Scouts)
have oaths and “laws” that you have to memorize to be officially accepted
into their communities.  IMO, these very short “documents" try to cement
certain keywords in your head so that you at least realize that certain
topics are important to that organization.  It isn’t out to be detailed in
any way.  That’s what these other documents are for.

So, I offer below some oaths, “laws of Apache” and even an anthem derived
mostly by culling words from Bertrand’s document.  I left out anything
from Bertrand’s document like quality and security that I felt folks
should already be practicing in their day job or in other open source
organizations.  I wanted the fewest words so that it could be more easily
memorized and cement in your head the things that make Apache different
from your day job and other open source groups.

Hope you like it.
-Alex

The Committer Oath
I, _, promise to properly record the licensing and copyright of
any code I commit, treat all committers equally, use the mailing list for
communicating with others, only veto code with technical explanations,
help users, fix bugs, and represent myself and not my employer in my
actions.


The PMC Member Oath (assumes you’ve memorized the Committer Oath already).
I, _, promise to ensure the correct licensing and copyright of the
content of releases, treat all PMC members and committers equally, seek
consensus before voting, identify others whose meritorious actions deserve
inclusion as committers or PMC members, and use the private mailing list
only for discussions about people,

- The Laws of Apache -


Apache Releases:
-Are free
-Are PGP-signed
-On dist.apache.org
-Approved by majority vote
-Do not contain compiled code.
-Contain scripts to compile any source that needs compilation.
-Contain correct LICENSE and NOTICE files


Apache Source Code:
-Is recorded in SVN or Git.
-Is not on GitHub (that’s a copy).
-Is available to the public
-Contains correct headers
-Is licensed under an approved license
-Does not depend on external code under certain licenses.


Apache Binary Packages:
-make the Release Manager liable
-contain LICENSE and NOTICE


The Apache Anthem (to the tune of “My Country Tis of Thee” or “God Save
the Queen”)

A-pach-e code for free
Source zip and tar.gz
Signed PGP.

License and Copyright
NOTICE files in sight.
3 plus-1 vote majority
No binary

Please get those headers right
Plus how to build it right
Check dependencies

Source in Subversion tree
Or Git Repositry
On servers in Apa-a-che
Legal history

Re: A maturity model for Apache projects

[Justin Mclean]

Hi,

Some (very) minor things.

CD10 - "distributed at no charge to the public." while this may be true at 
Apache it doesn't have to be the case. 3rd parties wanting to this model may 
find this a stumbling block.

CD40 - Perhaps a footnote? for code donated to Apache the history before Apache 
may or may not exists.

LC30 -  Add "compatible with the Apache License" just to make it clear that 
some OS licences are not compatible with Apache?

RE30 - Perhaps remove and/or as we would  want both right?

OCXX - Do we need add something about merit once given doesn't expire?

CO50 Perhaps change "granted more rights" to "granted more responsibility"?

INXX - Add something about multiple roles/multiple hats?

Thanks,
Justin

Re: A maturity model for Apache projects

[Phil Steitz]

On 1/15/15 3:39 AM, Bertrand Delacretaz wrote:
> On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz  wrote:
>> ...Missing Q or C thing:
>>
>> The project is not dead.  Bugs do not sit forever with no response.
>> Questions get answered on user lists...
> Thanks - I have reorganized Antoine's suggestions about this to be
>
> QU50 The project strives to process documented bug reports in a timely manner.
>
> CO70 The project strives to answer user questions in a timely manner.

Yes, it actually is Q and C.  Thanks!

Phil
>
> -Bertrand
> .
>

Re: A maturity model for Apache projects

[Phil Steitz]

On 1/15/15 3:47 AM, Bertrand Delacretaz wrote:
> On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz  wrote:
>> ...QO30 - do we really want individual projects to have / advertise
>> their own ways to take security reports?...
> We do not want that, agreed, but as I want the model to be usable by
> non-Apache projects as well I'm trying to focus on the core principles
> in the model, and leave the Apache specifics to footnotes.

Oh, sorry I missed that.
>
> I have added a footnote to QU30 that points to
> http://www.apache.org/security/ as the default, does that work for
> you?
>
> Sling for example has
> http://sling.apache.org/project-information/security.html which is a
> bit more Sling-specific and also points to
> http://www.apache.org/security/

Yes that is fine.  Thanks!

Phil
>
> -Bertrand
>

Re: A maturity model for Apache projects

[Kay Schenk]

On 01/15/2015 02:47 AM, Bertrand Delacretaz wrote:
> On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz  wrote:
>> ...QO30 - do we really want individual projects to have / advertise
>> their own ways to take security reports?...
> 
> We do not want that, agreed, but as I want the model to be usable by
> non-Apache projects as well I'm trying to focus on the core principles
> in the model, and leave the Apache specifics to footnotes.
> 
> I have added a footnote to QU30 that points to
> http://www.apache.org/security/ as the default, does that work for
> you?
> 
> Sling for example has
> http://sling.apache.org/project-information/security.html which is a
> bit more Sling-specific and also points to
> http://www.apache.org/security/
> 
> -Bertrand
> 

LC20 needs a lot more expansion. There are so many open source licenses.
Depending on the complexity of the given ASF project, it's a challenge
to evaluate LC20.

-- 
-
MzK

"There's a bit of magic in everything,
  and some loss to even things out."
-- Lou Reed

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz  wrote:
> ...QO30 - do we really want individual projects to have / advertise
> their own ways to take security reports?...

We do not want that, agreed, but as I want the model to be usable by
non-Apache projects as well I'm trying to focus on the core principles
in the model, and leave the Apache specifics to footnotes.

I have added a footnote to QU30 that points to
http://www.apache.org/security/ as the default, does that work for
you?

Sling for example has
http://sling.apache.org/project-information/security.html which is a
bit more Sling-specific and also points to
http://www.apache.org/security/

-Bertrand

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz  wrote:
> ...Missing Q or C thing:
>
> The project is not dead.  Bugs do not sit forever with no response.
> Questions get answered on user lists...

Thanks - I have reorganized Antoine's suggestions about this to be

QU50 The project strives to process documented bug reports in a timely manner.

CO70 The project strives to answer user questions in a timely manner.

-Bertrand

Re: A maturity model for Apache projects

[Antoine Levy Lambert]

Phil,

I added your points on the wiki page 
https://wiki.apache.org/incubator/ApacheProjectMaturityModel

Antoine
On Jan 14, 2015, at 2:29 PM, Phil Steitz  wrote:

> The project is not dead.  Bugs do not sit forever with no response. 
> Questions get answered on user lists.

Re: A maturity model for Apache projects

[Phil Steitz]

On 1/14/15 8:22 AM, Bertrand Delacretaz wrote:
> Hi,
>
> On Tue, Jan 6, 2015 at 6:28 PM, Bertrand Delacretaz
>  wrote:
>> Creating such a model has been on my todo list for ages...
> I've written a first draft at
> https://wiki.apache.org/incubator/ApacheProjectMaturityModel
>
> I tried to take the comments of this thread into account, while
> keeping the model minimal.
>
> Hopefully the overview helps explain the goals and expected level of detail.
>
> Feedback is welcome, feel free to edit obvious mistakes directly or
> let's discuss larger things here.

QO30 - do we really want individual projects to have / advertise
their own ways to take security reports?  Shouldn't we just refer
everyone to [1] or [2] and say handling should be according to the
guidelines at [3].

QU40 - my friends @commons will find it comical that it is me who is
questioning this one; but are we really sure we all agree on this? 
The "break early, break often" approach is sometimes supported with
the argument that trying to maintain backward compatibility all the
time stifles innovation.  I don't think anyone advocates doing it in
minor releases without warning, but some might argue that burning
through the major rev numbers fairly quickly isn't a "quality"
issue.  The dodgy bit is do you maintain support for the stranded lines.

CS30 - CS40 (correctly, IMO) refers to "ASF voting rules" - why
should individual projects have their own voting rules?  Being
vote-happy is a community smell, so you would not expect mature
communities to have to develop or rely on these things.

Missing Q or C thing:

The project is not dead.  Bugs do not sit forever with no response. 
Questions get answered on user lists.


Phil

Phil


[1] http://www.apache.org/security/
[2] http://www.apache.org/security/projects.html
[3] http://www.apache.org/security/committers.html
>
> -Bertrand
>

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

Hi,

On Tue, Jan 6, 2015 at 6:28 PM, Bertrand Delacretaz
 wrote:
> Creating such a model has been on my todo list for ages...

I've written a first draft at
https://wiki.apache.org/incubator/ApacheProjectMaturityModel

I tried to take the comments of this thread into account, while
keeping the model minimal.

Hopefully the overview helps explain the goals and expected level of detail.

Feedback is welcome, feel free to edit obvious mistakes directly or
let's discuss larger things here.

-Bertrand

Re: A maturity model for Apache projects

[Rich Bowen]

On Jan 8, 2015 6:56 AM, "Jim Jagielski"  wrote:
>
> But that then provides the ability to create a larger eco-system
> of binary providers.
>
> >

This has worked out really well for httpd, as well as for several
successful companies.

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

On Fri, Jan 9, 2015 at 3:23 PM, Rich Bowen  wrote:
> ...I imagine this as a function of ComDev, not of the
> board. That is, it's a community/project strengthening exercise, not a Big
> Hammer...

+1

-Bertrand

Re: A maturity model for Apache projects

[Rich Bowen]

On 01/07/2015 04:43 AM, Scott Wilson wrote:

I think we also need to discuss whether we expect projects to undertake 
self-evaluation and reflection, or whether we'd have a process of review 
involving peers, mentors, shepherds etc.


No, I absolutely don't want to create another stack of overhead, or Yet 
Another hoop to jump through, as you said.


I think "directed self-evaluation" is the way I'd want to go - one or 
two persons from ComDev, in conjunction with two or three persons from 
the PMC, doing an evaluation. I imagine this as a function of ComDev, 
not of the board. That is, it's a community/project strengthening 
exercise, not a Big Hammer.


--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: A maturity model for Apache projects

[Jim Jagielski]

But that then provides the ability to create a larger eco-system
of binary providers.

> On Jan 6, 2015, at 3:45 PM, Nicolas Lalevée  
> wrote:
> 
> I would add something about the build of the sources. Because having sources 
> without having a repeatable build or having no clue about how to build it, it 
> makes the sources quite useless.
> 
> I had some troubles recently with a project. Its build depends on a resource 
> which is not available anymore. And I find it quite shameful since it was a 
> project about a build system.
> 
> Nicolas
> 
>> On 2015-01-06 18:28, Bertrand Delacretaz wrote:
>>> Hi,
>>> 
>>> Creating such a model has been on my todo list for ages, and in a
>>> related discussion on board@ people seem to agree that having this can
>>> be useful.
>>> 
>>> So let's start - here's my rough initial list of items:
>>> 
>>> Code: open, discoverable, fully public history, documented provenance
>>> Quality: security, backwards compatibility, etc
>>> Contributions: welcome from anyone based on technical quality
>>> License: Apache License, dependencies must not put additional restrictions
>>> Community: inclusive, meritocratic, no dictators, clear documented path to 
>>> entry
>>> Discussions and decisions: asynchronous, in a single central place, archived
>>> Decision making: consensus, votes if needed, technical vetoes in the worst 
>>> case
>>> Independence: from any corporate or organizational influence
>>> Releases: source code only, notices, long-lived release format
>>> 
>>> Related efforts, inspiration:
>>> 
>>> http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/
>>> 
>>> http://rfc.zeromq.org/spec:16
>>> 
>>> -Bertrand
> 

Re: A maturity model for Apache projects

[Chip Childers]

On Wed, Jan 07, 2015 at 09:04:32AM +, Scott Wilson wrote:
> On 7 Jan 2015, at 08:55, Bertrand Delacretaz wrote:
> 
> > On Tue, Jan 6, 2015 at 8:16 PM, Mike Drob  wrote:
> >> ...I understand the value of measuring maturity after a project has left 
> >> the
> >> Incubator, but I also don't know that we want to put an additional set of
> >> checkboxes on projects. Either you're ready to graduate, or you're not
> > 
> > Agreed, and this model can be a good way to measure that readyness.
> > 
> > My idea is also to help projects who are created elsewhere and might
> > want to move to Apache later - having them conform to (parts of) the
> > model will help.
> 
> Thats a good angle to consider - in these cases the incoming project is 
> "mature" in at least some sense, but we need to understand the areas where we 
> needs to focus on.
> 
> It would be worthwhile articulating all these requirements for having the 
> model - what we would use it for, how and why.

And either the incubator or the pTLP process (or both) could really use
this as a way to define "The Apache Way" more than a gut feeling. ;-)

-chip

Re: A maturity model for Apache projects

[Scott Wilson]

On 6 Jan 2015, at 17:28, Bertrand Delacretaz wrote:

> Hi,
> 
> Creating such a model has been on my todo list for ages, and in a
> related discussion on board@ people seem to agree that having this can
> be useful.
> 
> So let's start - here's my rough initial list of items:
> 
> Code: open, discoverable, fully public history, documented provenance
> Quality: security, backwards compatibility, etc
> Contributions: welcome from anyone based on technical quality
> License: Apache License, dependencies must not put additional restrictions
> Community: inclusive, meritocratic, no dictators, clear documented path to 
> entry
> Discussions and decisions: asynchronous, in a single central place, archived
> Decision making: consensus, votes if needed, technical vetoes in the worst 
> case
> Independence: from any corporate or organizational influence
> Releases: source code only, notices, long-lived release format
> 
> Related efforts, inspiration:
> 
> http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/

The SSMM (Software Sustainability Maturity Model)[1] incorporates "Openness" as 
one of the sections, the others being "Reusability" and "Capability". 

The Openness Rating is used to measure the Openness (or freedom) aspect of the 
project. 

The OR tool looks at a project from several dimensions:

• Legal – the conditions surrounding the project source code. Usually 
defined within the licence terms.
• Standards – the data, communication and other standards used within a 
project, for example, APIs, protocols, & documentation norms.
• Knowledge – the documentation, project information, decisions made, 
communication archives and any other content related to the project.
• Governance – the structure of the organisation that defines who 
participates in a project and the terms of participation. Includes decision 
making, and any practical or policy limitations on participation.
• Marketplace – the ability for any organisation to build a business 
around a project. Includes practical, legal and technological limitations to 
building an open marketplace around the project.

Reuse is measured using the Reuse Readiness Rating [2], which incorporates some 
technical elements. 

Capability is measured using a subset of CMMI [3], which focusses on process 
maturity.

The three sets of measures are combined to position projects on a scale from 0 
(Seed) to 8 (Dispersal)[1].

For our purposes at ASF, we need to limit how much we cover and measure 
depending on the aims we're trying to meet.  

I think we also need to discuss whether we expect projects to undertake 
self-evaluation and reflection, or whether we'd have a process of review 
involving peers, mentors, shepherds etc. 

(I presume we don't want to just make hoops for projects to jump through, but 
instead provide useful tools that help both the projects and the ASF as a 
whole.)

[1] http://oss-watch.ac.uk/resources/ssmm
[2] http://oss-watch.ac.uk/resources/reusereadinessrating
[3] http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration

> 
> http://rfc.zeromq.org/spec:16
> 
> -Bertrand

Re: A maturity model for Apache projects

[Scott Wilson]

On 7 Jan 2015, at 08:55, Bertrand Delacretaz wrote:

> On Tue, Jan 6, 2015 at 8:16 PM, Mike Drob  wrote:
>> ...I understand the value of measuring maturity after a project has left the
>> Incubator, but I also don't know that we want to put an additional set of
>> checkboxes on projects. Either you're ready to graduate, or you're not
> 
> Agreed, and this model can be a good way to measure that readyness.
> 
> My idea is also to help projects who are created elsewhere and might
> want to move to Apache later - having them conform to (parts of) the
> model will help.

Thats a good angle to consider - in these cases the incoming project is 
"mature" in at least some sense, but we need to understand the areas where we 
needs to focus on.

It would be worthwhile articulating all these requirements for having the model 
- what we would use it for, how and why.

> 
> -Bertrand

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

On Tue, Jan 6, 2015 at 8:16 PM, Mike Drob  wrote:
> ...I understand the value of measuring maturity after a project has left the
> Incubator, but I also don't know that we want to put an additional set of
> checkboxes on projects. Either you're ready to graduate, or you're not

Agreed, and this model can be a good way to measure that readyness.

My idea is also to help projects who are created elsewhere and might
want to move to Apache later - having them conform to (parts of) the
model will help.

-Bertrand

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

On Tue, Jan 6, 2015 at 8:05 PM, Vincent Keunen  wrote:
> On 2015-01-06 19:15, Bertrand Delacretaz wrote:
>> ...Yeah that's what I meant, convenience binaries are not Apache
>> Releases...

> ...Let's not forget OpenOffice and the likes.  Having all users compile the
> source code *may* reduce the installed base.  ;-)...

Distributing binaries is ok, it's just that those are not Apache
Releases - they are binary distributions and different criteria apply
to them. Definitely worth a footnote in the model, with links to more
details.

-Bertrand

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

On Tue, Jan 6, 2015 at 9:45 PM, Nicolas Lalevée
 wrote:
> ...I would add something about the build of the sources. Because having
> sources without having a repeatable build or having no clue about how to
> build it, it makes the sources quite useless

That might something for a footnote, agreed - as I said I want the
core model to be as small as possible, but such additions are nice.

-Bertrand

Re: A maturity model for Apache projects

[Roberto Galoppini]

Sent from a miserable mobile device

> On 07/gen/2015, at 09:26, Andrea Pescetti  wrote:
> 
>> On 06/01/2015 Dennis E. Hamilton wrote:
>> With regard to "competitors," I just remind myself that forking is a
>> feature and that community before code means not acting like a
>> competitor.  One should not accept the so-called competitor's terms
>> of debate, no matter how much individuals might see and even prefer
>> "competition."
> 
> I'll just note that "Forking is a feature" is totally unrelated to what I 
> wrote. If Microsoft starts a campaign to advocate IIS over the Apache HTTP 
> Server, that PMC will have to follow your route and "not accept the terms of 
> debate" or it will have to give an answer, and part of it may have to be 
> discussed confidentially (even the Foundation Press Releases are not 
> discussed in public before they are issued; in the real world... this 
> happens).

Exactly. We do all know very well Apache PR are discussed privately, not 
differently we (AOO) do discuss how to address jpirnalists' questions 
privately, so that we do not look naive by debating all details on a public ML, 
getting ridicolous and giving journalists a chance to point to this or that 
opinion expressed in those threads.



> 
> The discussion that followed seems to clearly show that this stays undecided. 
> So, coming back to the maturity model, I think that we can recommend a wise 
> usage of the private list, but not necessarily restrict it to votes and 
> security. Trademark violations for example surely belong there, and more can 
> belong there depending on the project and on its public image.
> 
> A note to reassure those who oppose it: I've never seen marketing strategy 
> discussions on the private lists I'm subscribed to. I'm definitely not a 
> marketing-oriented person, but I don't see marketing as inherently evil 
> either.

I always thought Apache was about the code, how discussing some marketing stuff 
within the PMC could be seen as a closed-source practice goes beyond my 
comprension.

Roberto



> 
> Regards,
>  Andrea.

Re: A maturity model for Apache projects

[Andrea Pescetti]

On 06/01/2015 Dennis E. Hamilton wrote:

With regard to "competitors," I just remind myself that forking is a
feature and that community before code means not acting like a
competitor.  One should not accept the so-called competitor's terms
of debate, no matter how much individuals might see and even prefer
"competition."


I'll just note that "Forking is a feature" is totally unrelated to what 
I wrote. If Microsoft starts a campaign to advocate IIS over the Apache 
HTTP Server, that PMC will have to follow your route and "not accept the 
terms of debate" or it will have to give an answer, and part of it may 
have to be discussed confidentially (even the Foundation Press Releases 
are not discussed in public before they are issued; in the real world... 
this happens).


The discussion that followed seems to clearly show that this stays 
undecided. So, coming back to the maturity model, I think that we can 
recommend a wise usage of the private list, but not necessarily restrict 
it to votes and security. Trademark violations for example surely belong 
there, and more can belong there depending on the project and on its 
public image.


A note to reassure those who oppose it: I've never seen marketing 
strategy discussions on the private lists I'm subscribed to. I'm 
definitely not a marketing-oriented person, but I don't see marketing as 
inherently evil either.


Regards,
  Andrea.

RE: A maturity model for Apache projects

[Ross Gardler (MS OPEN TECH)]

+1

Now lets get back in topic. A maturity model starts at immature and works 
towards mature. All views are allowed on that spectrum (the hard part is 
agreeing where each view is but luckily the Apache Way defines much if that for 
us)

Sent from my Windows Phone

From: Ted Dunning<mailto:ted.dunn...@gmail.com>
Sent: ‎1/‎6/‎2015 5:33 PM
To: dev@community.apache.org<mailto:dev@community.apache.org>
Subject: Re: A maturity model for Apache projects

On Tue, Jan 6, 2015 at 3:36 PM, Louis Suárez-Potts  wrote:

>
> > On 6 Jan 2015, at 18:09, jan i  wrote:
> >
> > On Wednesday, January 7, 2015, Ted Dunning 
> wrote:
> >
> >> These are *open* source.  Plotting strategy for marketing on a private
> list
> >> has no place in Apache projects.  Private lists have very limited
> >> appropriate uses and that policy has served Apache very well.
> >
> > +1
> >
> > jan i
> >
>
> Say you are right. But in the “real world,” defined by personal experience
> and hearsay, the result of such policies (and such tones in their
> articulation) is to have discussions entirely off-list. Open source is
> meant to be a vehicle by which free collaboration is enabled now and later.
> As we’ve surely discussed in the past, in different contexts (at least I
> have; I can only assume that if you are reading this you have, too),
> there’s usually a tension between what the world expects and what we would
> like to do in open source. And sometimes the balance is against us.
>
>
In such situations, I become an advocate of closed source.  If you aren't
going to walk the walk and do things in an open, community-oriented way,
then it really is better to call a spade a spade and make the code be
closed source.  You can move faster, productively employ genius prima donas
and hatch all the secret plans you desire.

I would much rather call a spade a spade and get back to work rather than
allow a project to veer in to the open source / closed community category.
In my experience, being stuck in the closed community state is probably a
great indicator of "excessive fascination with the Apache brand".

Oddly enough, I have also seen the opposite case of code that is
unabashedly closed source being very open to input and community action.
Paradoxical.

Re: A maturity model for Apache projects

[Ted Dunning]

On Tue, Jan 6, 2015 at 3:36 PM, Louis Suárez-Potts  wrote:

>
> > On 6 Jan 2015, at 18:09, jan i  wrote:
> >
> > On Wednesday, January 7, 2015, Ted Dunning 
> wrote:
> >
> >> These are *open* source.  Plotting strategy for marketing on a private
> list
> >> has no place in Apache projects.  Private lists have very limited
> >> appropriate uses and that policy has served Apache very well.
> >
> > +1
> >
> > jan i
> >
>
> Say you are right. But in the “real world,” defined by personal experience
> and hearsay, the result of such policies (and such tones in their
> articulation) is to have discussions entirely off-list. Open source is
> meant to be a vehicle by which free collaboration is enabled now and later.
> As we’ve surely discussed in the past, in different contexts (at least I
> have; I can only assume that if you are reading this you have, too),
> there’s usually a tension between what the world expects and what we would
> like to do in open source. And sometimes the balance is against us.
>
>
In such situations, I become an advocate of closed source.  If you aren't
going to walk the walk and do things in an open, community-oriented way,
then it really is better to call a spade a spade and make the code be
closed source.  You can move faster, productively employ genius prima donas
and hatch all the secret plans you desire.

I would much rather call a spade a spade and get back to work rather than
allow a project to veer in to the open source / closed community category.
In my experience, being stuck in the closed community state is probably a
great indicator of "excessive fascination with the Apache brand".

Oddly enough, I have also seen the opposite case of code that is
unabashedly closed source being very open to input and community action.
Paradoxical.

Re: A maturity model for Apache projects

[Louis Suárez-Potts]

> On 6 Jan 2015, at 18:09, jan i  wrote:
> 
> On Wednesday, January 7, 2015, Ted Dunning  wrote:
> 
>> These are *open* source.  Plotting strategy for marketing on a private list
>> has no place in Apache projects.  Private lists have very limited
>> appropriate uses and that policy has served Apache very well.
> 
> +1
> 
> jan i
> 

Say you are right. But in the “real world,” defined by personal experience and 
hearsay, the result of such policies (and such tones in their articulation) is 
to have discussions entirely off-list. Open source is meant to be a vehicle by 
which free collaboration is enabled now and later. As we’ve surely discussed in 
the past, in different contexts (at least I have; I can only assume that if you 
are reading this you have, too), there’s usually a tension between what the 
world expects and what we would like to do in open source. And sometimes the 
balance is against us.

louis

>> 
>> 
>> On Tue, Jan 6, 2015 at 11:48 AM, Andrea Pescetti > >
>> wrote:
>> 
>>> On 06/01/2015 Daniel Gruno wrote:
>>> 
 projects unfortunately have a tendency to use their private lists for
 much more than committer votes and security issues, which I find is bad
 practice.
 
>>> 
>>> If you as a project had a competitor, possibly a proprietary one, would
>>> you discuss marketing strategy in public? Would you expect the same from
>>> your competitor? This is a purely theoretical issue, but some projects
>>> might be facing it. I don't have a clear-cut answer here. Maybe the
>> answer
>>> is yes, but in practice journalists expect to use confidential channels.
>> So
>>> press/marketing strategy might, and I repeat might, be among the
>>> discussions allowed on the private list. Marketing activities instead, as
>>> opposed to strategy, must surely be discussed on public lists.
>>> 
>>> Regards,
>>>  Andrea.
>>> 
>> 
> 
> 
> -- 
> Sent from My iPad, sorry for any misspellings.

Re: A maturity model for Apache projects

[jan i]

On Wednesday, January 7, 2015, Ted Dunning  wrote:

> These are *open* source.  Plotting strategy for marketing on a private list
> has no place in Apache projects.  Private lists have very limited
> appropriate uses and that policy has served Apache very well.

+1

jan i

>
>
>
> On Tue, Jan 6, 2015 at 11:48 AM, Andrea Pescetti  >
> wrote:
>
> > On 06/01/2015 Daniel Gruno wrote:
> >
> >> projects unfortunately have a tendency to use their private lists for
> >> much more than committer votes and security issues, which I find is bad
> >> practice.
> >>
> >
> > If you as a project had a competitor, possibly a proprietary one, would
> > you discuss marketing strategy in public? Would you expect the same from
> > your competitor? This is a purely theoretical issue, but some projects
> > might be facing it. I don't have a clear-cut answer here. Maybe the
> answer
> > is yes, but in practice journalists expect to use confidential channels.
> So
> > press/marketing strategy might, and I repeat might, be among the
> > discussions allowed on the private list. Marketing activities instead, as
> > opposed to strategy, must surely be discussed on public lists.
> >
> > Regards,
> >   Andrea.
> >
>


-- 
Sent from My iPad, sorry for any misspellings.

Re: A maturity model for Apache projects

[Ted Dunning]

These are *open* source.  Plotting strategy for marketing on a private list
has no place in Apache projects.  Private lists have very limited
appropriate uses and that policy has served Apache very well.



On Tue, Jan 6, 2015 at 11:48 AM, Andrea Pescetti 
wrote:

> On 06/01/2015 Daniel Gruno wrote:
>
>> projects unfortunately have a tendency to use their private lists for
>> much more than committer votes and security issues, which I find is bad
>> practice.
>>
>
> If you as a project had a competitor, possibly a proprietary one, would
> you discuss marketing strategy in public? Would you expect the same from
> your competitor? This is a purely theoretical issue, but some projects
> might be facing it. I don't have a clear-cut answer here. Maybe the answer
> is yes, but in practice journalists expect to use confidential channels. So
> press/marketing strategy might, and I repeat might, be among the
> discussions allowed on the private list. Marketing activities instead, as
> opposed to strategy, must surely be discussed on public lists.
>
> Regards,
>   Andrea.
>

RE: A maturity model for Apache projects

[Dennis E. Hamilton]

It seems to me that the journalist practice of wanting confidential access 
serves the interests of the journalist, not the project.  I would simply deny 
such requests and/or encourage the journalist to put questions on a public list.

With regard to "competitors," I just remind myself that forking is a feature 
and that community before code means not acting like a competitor.  One should 
not accept the so-called competitor's terms of debate, no matter how much 
individuals might see and even prefer "competition."

Personally, I would not have any conversation with a journalist that was not 
recorded or, better yet, wasn't in a written exchange, such as via email.  But 
that is me personally.  But denial of confidential access should probably be a 
strong PMC position.

 - Dennis

-Original Message-
From: Andrea Pescetti [mailto:pesce...@apache.org] 
Sent: Tuesday, January 6, 2015 11:48
To: dev@community.apache.org
Subject: Re: A maturity model for Apache projects

On 06/01/2015 Daniel Gruno wrote:
> projects unfortunately have a tendency to use their private lists for
> much more than committer votes and security issues, which I find is bad
> practice.

If you as a project had a competitor, possibly a proprietary one, would 
you discuss marketing strategy in public? Would you expect the same from 
your competitor? This is a purely theoretical issue, but some projects 
might be facing it. I don't have a clear-cut answer here. Maybe the 
answer is yes, but in practice journalists expect to use confidential 
channels. So press/marketing strategy might, and I repeat might, be 
among the discussions allowed on the private list. Marketing activities 
instead, as opposed to strategy, must surely be discussed on public lists.

Regards,
   Andrea.

Re: A maturity model for Apache projects

[Nicolas Lalevée]

I would add something about the build of the sources. Because having sources 
without having a repeatable build or having no clue about how to build it, it 
makes the sources quite useless.

I had some troubles recently with a project. Its build depends on a resource 
which is not available anymore. And I find it quite shameful since it was a 
project about a build system.

Nicolas

> On 2015-01-06 18:28, Bertrand Delacretaz wrote:
>> Hi,
>> 
>> Creating such a model has been on my todo list for ages, and in a
>> related discussion on board@ people seem to agree that having this can
>> be useful.
>> 
>> So let's start - here's my rough initial list of items:
>> 
>> Code: open, discoverable, fully public history, documented provenance
>> Quality: security, backwards compatibility, etc
>> Contributions: welcome from anyone based on technical quality
>> License: Apache License, dependencies must not put additional restrictions
>> Community: inclusive, meritocratic, no dictators, clear documented path to 
>> entry
>> Discussions and decisions: asynchronous, in a single central place, archived
>> Decision making: consensus, votes if needed, technical vetoes in the worst 
>> case
>> Independence: from any corporate or organizational influence
>> Releases: source code only, notices, long-lived release format
>> 
>> Related efforts, inspiration:
>> 
>> http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/
>> 
>> http://rfc.zeromq.org/spec:16
>> 
>> -Bertrand

Re: A maturity model for Apache projects

[Andrea Pescetti]

On 06/01/2015 Tim Williams wrote:

On Tue, Jan 6, 2015 at 3:06 PM, Andrea Pescetti wrote:

The binaries OpenOffice makes available for download from its official site
are "convenience binaries" as per Bertrand's description. We are not going
to ask users to build it themselves!

We're heading off-topic a bit, but... Really? I thought you guys were
some sort of exception to our normal policy and that it was provided
by the PMC.


We are really going off-topic, but just to clarify: the [VOTE] mail 
references both the source and the convenience binaries. Convenience 
binaries are prepared by the Release Manager on his own hardware (and 
this is slowly moving to Apache-owned infrastructure). A major flaw in a 
binary would be a reason for rejecting a release candidate, or asking a 
rebuild of binary packages. So you guessed right: they are PMC-approved 
convenience binaries.


I hope it's clear now. See here for a sample [VOTE] mail:

http://mail-archives.apache.org/mod_mbox/openoffice-qa/201408.mbox/%3c53edb383.6080...@gmail.com%3E

Regards,
  Andrea.

Re: A maturity model for Apache projects

[Mike Drob]

On Tue, Jan 6, 2015 at 2:12 PM, Marvin Humphrey 
wrote:

> On Tue, Jan 6, 2015 at 11:16 AM, Mike Drob  wrote:
>
> > How much of this is already covered by the Incubation process? Hopefully
> > projects don't revert to improper licensing or closed development after
> > they graduate.
>
> The absence of clear documentation harms projects both during and after
> incubation.
>

Agreed.

>
> For example, when a project transgresses against some aspect of Apache
> policy,
> PMC members may not speak out because they don't feel confident that they
> grok
> our muddled rules well enough to argue the point -- even though they were
> trained on them during incubation.
>

This is something I've personally experienced, but I hadn't realized that
this is what it was until just now, when you explained it.

>
> Many people around the Foundation have unreasonable expectations about the
> Incubator's ability to assure good behavior in perpetuity for its
> graduates.
>
> Meanwhile, the abominable state of our policy documentation goes unnoticed.
>

I prefer to consider the expectations optimistic rather than unreasonable.
Would it be easier to start from the Incubator checklist/guidelines and
figure out how to expand that to the general populace rather than building
a new model from scratch? Or is the idea that things are so bad that we
need a drastic cut?

I think the Incubator guidelines are reasonable, and have referred to them
several times when discussing policy. I suppose that could be consequence
of poorly maintained documents, though. Polishing those and hosting them
somewhere on www.a.o (instead of incubator.a.o) would likely go a long way.


> Marvin Humphrey
>

Mike

Re: A maturity model for Apache projects

[Louis Suárez-Potts]

> On 6 Jan 2015, at 14:48, Andrea Pescetti  wrote:
> 
> On 06/01/2015 Daniel Gruno wrote:
>> projects unfortunately have a tendency to use their private lists for
>> much more than committer votes and security issues, which I find is bad
>> practice.
> 
> If you as a project had a competitor, possibly a proprietary one, would you 
> discuss marketing strategy in public? Would you expect the same from your 
> competitor? This is a purely theoretical issue, but some projects might be 
> facing it. I don't have a clear-cut answer here. Maybe the answer is yes, but 
> in practice journalists expect to use confidential channels. So 
> press/marketing strategy might, and I repeat might, be among the discussions 
> allowed on the private list. Marketing activities instead, as opposed to 
> strategy, must surely be discussed on public lists.
> 
> Regards,
>  Andrea.

This is a good question and one that’s been raised repeatedly over the course 
of open source’s fairly brief lifetime by OpenOffice, Mozilla (as far as I 
know), and other, less obvious projects. There’s no single, right answer. But 
Andrae hits a crucial point. It’s the relationship with the journalist that 
actually matters. But not all journalists want “secrets.” But they do expect 
interesting news. And they are trained (and their editors demand) “news” that 
is new, if not otherwise compelling and interesting.

But that does not mean that “news” must only concern the product features, etc. 
It can also be about the community process, about other “interesting” elements. 
“Interesting” lies, too, as much in the facts as in the narrative connecting 
them. And these elements can in fact be made public. Actually, they gain for 
being public, for asserting publicness.

louis

Re: A maturity model for Apache projects

[Marvin Humphrey]

On Tue, Jan 6, 2015 at 11:16 AM, Mike Drob  wrote:

> How much of this is already covered by the Incubation process? Hopefully
> projects don't revert to improper licensing or closed development after
> they graduate.

The absence of clear documentation harms projects both during and after
incubation.

For example, when a project transgresses against some aspect of Apache policy,
PMC members may not speak out because they don't feel confident that they grok
our muddled rules well enough to argue the point -- even though they were
trained on them during incubation.

Many people around the Foundation have unreasonable expectations about the
Incubator's ability to assure good behavior in perpetuity for its graduates.

Meanwhile, the abominable state of our policy documentation goes unnoticed.

Marvin Humphrey

Re: A maturity model for Apache projects

[Tim Williams]

On Tue, Jan 6, 2015 at 3:06 PM, Andrea Pescetti  wrote:
> On 06/01/2015 Vincent Keunen wrote:
>>
>> On 2015-01-06 19:15, Bertrand Delacretaz wrote:
>>>
>>> convenience binaries are not Apache Releases.
>>
>> Let's not forget OpenOffice and the likes.  Having all users compile the
>> source code *may* reduce the installed base.  ;-)
>
>
> The binaries OpenOffice makes available for download from its official site
> are "convenience binaries" as per Bertrand's description. We are not going
> to ask users to build it themselves!

We're heading off-topic a bit, but... Really? I thought you guys were
some sort of exception to our normal policy and that it was provided
by the PMC.  It's remarkable to me that a single individual would
wittingly accept liability for binaries with that large an install
base.  Hopefully the RM has a good umbrella policy...

--tim

Re: A maturity model for Apache projects

[Andrea Pescetti]

On 06/01/2015 Vincent Keunen wrote:

On 2015-01-06 19:15, Bertrand Delacretaz wrote:

convenience binaries are not Apache Releases.

Let's not forget OpenOffice and the likes.  Having all users compile the
source code *may* reduce the installed base.  ;-)


The binaries OpenOffice makes available for download from its official 
site are "convenience binaries" as per Bertrand's description. We are 
not going to ask users to build it themselves!


Regards,
  Andrea.

Re: A maturity model for Apache projects

[Andrea Pescetti]

On 06/01/2015 Daniel Gruno wrote:

projects unfortunately have a tendency to use their private lists for
much more than committer votes and security issues, which I find is bad
practice.


If you as a project had a competitor, possibly a proprietary one, would 
you discuss marketing strategy in public? Would you expect the same from 
your competitor? This is a purely theoretical issue, but some projects 
might be facing it. I don't have a clear-cut answer here. Maybe the 
answer is yes, but in practice journalists expect to use confidential 
channels. So press/marketing strategy might, and I repeat might, be 
among the discussions allowed on the private list. Marketing activities 
instead, as opposed to strategy, must surely be discussed on public lists.


Regards,
  Andrea.

Re: A maturity model for Apache projects

[Mike Drob]

On Tue, Jan 6, 2015 at 11:28 AM, Bertrand Delacretaz  wrote:

> Hi,
>
> Creating such a model has been on my todo list for ages, and in a
> related discussion on board@ people seem to agree that having this can
> be useful.
>
> So let's start - here's my rough initial list of items:
>
> Code: open, discoverable, fully public history, documented provenance
> Quality: security, backwards compatibility, etc
> Contributions: welcome from anyone based on technical quality
> License: Apache License, dependencies must not put additional restrictions
> Community: inclusive, meritocratic, no dictators, clear documented path to
> entry
> Discussions and decisions: asynchronous, in a single central place,
> archived
> Decision making: consensus, votes if needed, technical vetoes in the worst
> case
> Independence: from any corporate or organizational influence
> Releases: source code only, notices, long-lived release format
>

How much of this is already covered by the Incubation process? Hopefully
projects don't revert to improper licensing or closed development after
they graduate.

I understand the value of measuring maturity after a project has left the
Incubator, but I also don't know that we want to put an additional set of
checkboxes on projects. Either you're ready to graduate, or you're not.
That comes from having good mentors, I think.

Am I missing the intent here?


>
> Related efforts, inspiration:
>
>
> http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/
>
> http://rfc.zeromq.org/spec:16
>
> -Bertrand
>

Re: A maturity model for Apache projects

[Louis Suárez-Potts]

> On 6 Jan 2015, at 14:05, Vincent Keunen  wrote:
> 
> 
> On 2015-01-06 19:15, Bertrand Delacretaz wrote:
>> Hi Marcel,
>> 
>> On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans
>>  wrote:
>>> ...Since the only official releases *are* source releases the
>>> statement “source code only” probably applies to the source code
>>> release, meaning that it should not contain any binaries. Since
>>> convenience binaries are not official anyway, it might not make that much
>>> sense checking them...
>> Yeah that's what I meant, convenience binaries are not Apache
>> Releases. The maturity model can point to information about the latter
>> but I would keep it out of the model, that should be as concise as
>> possible.
>> 
>> 
> 
> Let's not forget OpenOffice and the likes.  Having all users compile the 
> source code *may* reduce the installed base.  ;-)

:-)
especially if they use OS X. 

-louis


> 
> 
> -- 
> VK private signature Vincent Keunen
> How to contact me 
> vinc...@keunen.net 
> about.me 
> My new project: Andaman7 

Re: A maturity model for Apache projects

[sebb]

On 6 January 2015 at 18:31, Bertrand Delacretaz  wrote:
> On Tue, Jan 6, 2015 at 7:21 PM, Daniel Gruno  wrote:
>> ...How about a compromise:
>> distribution of releases and source: publicly, in a _consistent_ manner
>> according to foundation guidelines?...
>
> Works for me.

Does not work for me.

The adjective "consistent" seems to be applied to the wrong noun.

"consistent manner" implies to me that the way we release artifacts
won't change.

Maybe

distribution of releases and source: publicly, in a manner
_consistent_ with the foundation guidelines?


> -Bertrand

Re: A maturity model for Apache projects

[Vincent Keunen]

On 2015-01-06 19:15, Bertrand Delacretaz wrote:

Hi Marcel,

On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans
 wrote:

...Since the only official releases *are* source releases the
statement “source code only” probably applies to the source code
release, meaning that it should not contain any binaries. Since
convenience binaries are not official anyway, it might not make that much
sense checking them...

Yeah that's what I meant, convenience binaries are not Apache
Releases. The maturity model can point to information about the latter
but I would keep it out of the model, that should be as concise as
possible.




Let's not forget OpenOffice and the likes.  Having all users compile the 
source code *may* reduce the installed base.  ;-)



--
VK private signature Vincent Keunen
How to contact me 
vinc...@keunen.net 
about.me 
My new project: Andaman7 

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

On Tue, Jan 6, 2015 at 7:21 PM, Daniel Gruno  wrote:
> ...How about a compromise:
> distribution of releases and source: publicly, in a _consistent_ manner
> according to foundation guidelines?...

Works for me.
-Bertrand

Re: A maturity model for Apache projects

[Daniel Gruno]

On 2015-01-06 19:15, Bertrand Delacretaz wrote:

Hi Marcel,

On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans
 wrote:

...Since the only official releases *are* source releases the
statement “source code only” probably applies to the source code
release, meaning that it should not contain any binaries. Since
convenience binaries are not official anyway, it might not make that much
sense checking them...

Yeah that's what I meant, convenience binaries are not Apache
Releases. The maturity model can point to information about the latter
but I would keep it out of the model, that should be as concise as
possible.


...Another thing we might want to do is to check if releases are really
placed in /dist/ ...

Also something that's important but does not belong to the core model IMO.

How about a compromise:
distribution of releases and source: publicly, in a _consistent_ manner 
according to foundation guidelines?


With regards,
Daniel


-Bertrand

Re: A maturity model for Apache projects

[Bertrand Delacretaz]

Hi Marcel,

On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans
 wrote:
> ...Since the only official releases *are* source releases the
> statement “source code only” probably applies to the source code
> release, meaning that it should not contain any binaries. Since
> convenience binaries are not official anyway, it might not make that much
> sense checking them...

Yeah that's what I meant, convenience binaries are not Apache
Releases. The maturity model can point to information about the latter
but I would keep it out of the model, that should be as concise as
possible.

> ...Another thing we might want to do is to check if releases are really
> placed in /dist/ ...

Also something that's important but does not belong to the core model IMO.

-Bertrand

Re: A maturity model for Apache projects

[jan i]

On Tuesday, January 6, 2015, Daniel Gruno  wrote:

>
> On 2015-01-06 18:53, Vincent Keunen wrote:
>
>> Good idea.
>>
>> I would just remove the "only" from "Releases: source code only". Maybe
>> say "Releases: source code at the minimum" ?  It's not a problem to have
>> some projects also release binaries, is it?
>>
>
> Releasing binaries have, to this point, always been a convenience service
> provided by individuals, but that may very well change with the new code
> signing service. I agree that this will need some mulling over.


The "always" is relative. AOO has as a project released binaries since
incubator and unless I have misunderstood something a number of our java
projects make jar files available.

>
>
>> Shouldn't there be also something about a minimum documentation? Not
>> necessarily doc on source code, but doc on the project (minimal web
>> site,...)?
>>
>
> I would add to that something about where discussions/decisions take
> place, possibly something about contacting projects; private for
> personal/security issues (provided they get disclosed publicly if it's a
> security issue and it has been fixed), public for all else. Some projects
> unfortunately have a tendency to use their private lists for much more than
> committer votes and security issues, which I find is bad practice.

+1

rgds
jan i

>
> With regards,
> Daniel.
>
>
>> I can also confirm that Bertrand was talking about this to me at
>> Budapest.  So "ages >= 2 months".  :-)
>>
>> Vincent
>>
>> On 2015-01-06 18:28, Bertrand Delacretaz wrote:
>>
>>> Hi,
>>>
>>> Creating such a model has been on my todo list for ages, and in a
>>> related discussion on board@ people seem to agree that having this can
>>> be useful.
>>>
>>> So let's start - here's my rough initial list of items:
>>>
>>> Code: open, discoverable, fully public history, documented provenance
>>> Quality: security, backwards compatibility, etc
>>> Contributions: welcome from anyone based on technical quality
>>> License: Apache License, dependencies must not put additional
>>> restrictions
>>> Community: inclusive, meritocratic, no dictators, clear documented path
>>> to entry
>>> Discussions and decisions: asynchronous, in a single central place,
>>> archived
>>> Decision making: consensus, votes if needed, technical vetoes in the
>>> worst case
>>> Independence: from any corporate or organizational influence
>>> Releases: source code only, notices, long-lived release format
>>>
>>> Related efforts, inspiration:
>>>
>>> http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-
>>> fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/
>>>
>>> http://rfc.zeromq.org/spec:16
>>>
>>> -Bertrand
>>>
>>
>>
>

-- 
Sent from My iPad, sorry for any misspellings.

Re: A maturity model for Apache projects

[Marcel Offermans]

On 6 Jan 2015 at 19:01:01, Daniel Gruno (humbed...@apache.org) wrote:
On 2015-01-06 18:53, Vincent Keunen wrote: 
> Good idea. 
> 
> I would just remove the "only" from "Releases: source code only". 
> Maybe say "Releases: source code at the minimum" ? It's not a problem 
> to have some projects also release binaries, is it? 

Releasing binaries have, to this point, always been a convenience 
service provided by individuals, but that may very well change with the 
new code signing service. I agree that this will need some mulling over. 
I think you might be misinterpreting the original intention. Since the only 
official releases *are* source releases the statement “source code only” 
probably applies to the source code release, meaning that it should not contain 
any binaries. Since convenience binaries are not official anyway, it might not 
make that much sense checking them (we could, to make sure that notice and 
license files are there).

Another thing we might want to do is to check if releases are really placed in 
/dist/ because that is something that I have seen in the past not happening 
(only releasing to Maven central for example).

Greetings, Marcel

Re: A maturity model for Apache projects

[Daniel Gruno]

On 2015-01-06 18:53, Vincent Keunen wrote:

Good idea.

I would just remove the "only" from "Releases: source code only". 
Maybe say "Releases: source code at the minimum" ?  It's not a problem 
to have some projects also release binaries, is it?


Releasing binaries have, to this point, always been a convenience 
service provided by individuals, but that may very well change with the 
new code signing service. I agree that this will need some mulling over.




Shouldn't there be also something about a minimum documentation? Not 
necessarily doc on source code, but doc on the project (minimal web 
site,...)?


I would add to that something about where discussions/decisions take 
place, possibly something about contacting projects; private for 
personal/security issues (provided they get disclosed publicly if it's a 
security issue and it has been fixed), public for all else. Some 
projects unfortunately have a tendency to use their private lists for 
much more than committer votes and security issues, which I find is bad 
practice.


With regards,
Daniel.



I can also confirm that Bertrand was talking about this to me at 
Budapest.  So "ages >= 2 months".  :-)


Vincent

On 2015-01-06 18:28, Bertrand Delacretaz wrote:

Hi,

Creating such a model has been on my todo list for ages, and in a
related discussion on board@ people seem to agree that having this can
be useful.

So let's start - here's my rough initial list of items:

Code: open, discoverable, fully public history, documented provenance
Quality: security, backwards compatibility, etc
Contributions: welcome from anyone based on technical quality
License: Apache License, dependencies must not put additional 
restrictions
Community: inclusive, meritocratic, no dictators, clear documented 
path to entry
Discussions and decisions: asynchronous, in a single central place, 
archived
Decision making: consensus, votes if needed, technical vetoes in the 
worst case

Independence: from any corporate or organizational influence
Releases: source code only, notices, long-lived release format

Related efforts, inspiration:

http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/ 



http://rfc.zeromq.org/spec:16

-Bertrand

Re: A maturity model for Apache projects

[Vincent Keunen]

Good idea.

I would just remove the "only" from "Releases: source code only". Maybe 
say "Releases: source code at the minimum" ?  It's not a problem to have 
some projects also release binaries, is it?


Shouldn't there be also something about a minimum documentation? Not 
necessarily doc on source code, but doc on the project (minimal web 
site,...)?


I can also confirm that Bertrand was talking about this to me at 
Budapest.  So "ages >= 2 months".  :-)


Vincent

On 2015-01-06 18:28, Bertrand Delacretaz wrote:

Hi,

Creating such a model has been on my todo list for ages, and in a
related discussion on board@ people seem to agree that having this can
be useful.

So let's start - here's my rough initial list of items:

Code: open, discoverable, fully public history, documented provenance
Quality: security, backwards compatibility, etc
Contributions: welcome from anyone based on technical quality
License: Apache License, dependencies must not put additional restrictions
Community: inclusive, meritocratic, no dictators, clear documented path to entry
Discussions and decisions: asynchronous, in a single central place, archived
Decision making: consensus, votes if needed, technical vetoes in the worst case
Independence: from any corporate or organizational influence
Releases: source code only, notices, long-lived release format

Related efforts, inspiration:

http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/

http://rfc.zeromq.org/spec:16

-Bertrand


--
VK private signature Vincent Keunen

A maturity model for Apache projects

[Bertrand Delacretaz]

Hi,

Creating such a model has been on my todo list for ages, and in a
related discussion on board@ people seem to agree that having this can
be useful.

So let's start - here's my rough initial list of items:

Code: open, discoverable, fully public history, documented provenance
Quality: security, backwards compatibility, etc
Contributions: welcome from anyone based on technical quality
License: Apache License, dependencies must not put additional restrictions
Community: inclusive, meritocratic, no dictators, clear documented path to entry
Discussions and decisions: asynchronous, in a single central place, archived
Decision making: consensus, votes if needed, technical vetoes in the worst case
Independence: from any corporate or organizational influence
Releases: source code only, notices, long-lived release format

Related efforts, inspiration:

http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/

http://rfc.zeromq.org/spec:16

-Bertrand