Re: A maturity model for Apache projects
On 1/20/15 9:02 AM, Bertrand Delacretaz wrote: Hi Justin, On Sat, Jan 17, 2015 at 7:37 AM, Justin Mclean jus...@classsoftware.com 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
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
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)
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
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 bdelacre...@apache.org 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
On Sat, Jan 17, 2015 at 8:09 AM, Lefty Leverenz leftylever...@gmail.com 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
Hi Justin, On Sat, Jan 17, 2015 at 7:37 AM, Justin Mclean jus...@classsoftware.com 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: A maturity model for Apache projects
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: Oaths and Anthems (was Re: A maturity model for Apache projects)
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 aha...@adobe.com 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 http://vincent.keunen.net/contact-me/ vinc...@keunen.net about.me http://about.me/vincent.keunen
Oaths and Anthems (was Re: A maturity model for Apache projects)
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: Oaths and Anthems (was Re: A maturity model for Apache projects)
On 16 January 2015 at 17:51, Alex Harui aha...@adobe.com 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
Re: Oaths and Anthems (was Re: A maturity model for Apache projects)
On Friday, January 16, 2015, Dan Haywood d...@haywood-associates.co.uk wrote: On 16 January 2015 at 17:51, Alex Harui aha...@adobe.com javascript:; 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: A maturity model for Apache projects
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
On 1/15/15 3:39 AM, Bertrand Delacretaz wrote: On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz phil.ste...@gmail.com 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
On 01/15/2015 02:47 AM, Bertrand Delacretaz wrote: On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz phil.ste...@gmail.com 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
On 1/15/15 3:47 AM, Bertrand Delacretaz wrote: On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz phil.ste...@gmail.com 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
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
On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz phil.ste...@gmail.com 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
On Wed, Jan 14, 2015 at 8:29 PM, Phil Steitz phil.ste...@gmail.com 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
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 phil.ste...@gmail.com 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
Hi, On Tue, Jan 6, 2015 at 6:28 PM, Bertrand Delacretaz bdelacre...@apache.org 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
On Fri, Jan 9, 2015 at 3:23 PM, Rich Bowen rbo...@rcbowen.com 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
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 nicolas.lale...@hibnet.org 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
On 7 Jan 2015, at 08:55, Bertrand Delacretaz wrote: On Tue, Jan 6, 2015 at 8:16 PM, Mike Drob md...@mdrob.com 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
On Tue, Jan 6, 2015 at 9:45 PM, Nicolas Lalevée nicolas.lale...@hibnet.org 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
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
Sent from a miserable mobile device On 07/gen/2015, at 09:26, Andrea Pescetti pesce...@apache.org 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
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 md...@mdrob.com 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
On Tue, Jan 6, 2015 at 11:28 AM, Bertrand Delacretaz bdelacre...@apache.org 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
On 2015-01-06 19:15, Bertrand Delacretaz wrote: Hi Marcel, On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans marcel.offerm...@luminis.nl 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 http://vincent.keunen.net/contact-me/ vinc...@keunen.net mailto:vinc...@keunen.net about.me http://about.me/vincent.keunen My new project: Andaman7 http://bit.ly/a7vkblogen
Re: A maturity model for Apache projects
On 6 January 2015 at 18:31, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 6, 2015 at 7:21 PM, Daniel Gruno humbed...@apache.org 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
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
On Tue, Jan 6, 2015 at 3:06 PM, Andrea Pescetti pesce...@apache.org 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
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
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
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 pesce...@apache.org 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
On Wednesday, January 7, 2015, Ted Dunning ted.dunn...@gmail.com 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 pesce...@apache.org javascript:; 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
On 6 Jan 2015, at 14:48, Andrea Pescetti pesce...@apache.org 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
On Tue, Jan 6, 2015 at 3:36 PM, Louis Suárez-Potts lui...@gmail.com wrote: On 6 Jan 2015, at 18:09, jan i j...@apache.org wrote: On Wednesday, January 7, 2015, Ted Dunning ted.dunn...@gmail.com 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
On Tuesday, January 6, 2015, 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. 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.
A maturity model for Apache projects
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
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
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
Re: A maturity model for Apache projects
Hi Marcel, On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans marcel.offerm...@luminis.nl 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
On Tue, Jan 6, 2015 at 7:21 PM, Daniel Gruno humbed...@apache.org 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
On 2015-01-06 19:15, Bertrand Delacretaz wrote: Hi Marcel, On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans marcel.offerm...@luminis.nl 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
