[GPC] SoC '09, RFP questions
Boberski, Michael [USA]
boberski_michael at bah.com
Thu May 14 14:47:14 EDT 2009
I'm not sure I agree with e.g. "... 2.0.1 because then that's suddenly an "alpha" release..."
No worries. Just curious.
From: li.jason.c at gmail.com [mailto:li.jason.c at gmail.com] On Behalf Of Jason Li
Sent: Thursday, May 14, 2009 2:24 PM
To: Boberski, Michael [USA]
Cc: paulo.coimbra at owasp.org; Global Projects Committee
Subject: Re: [GPC] SoC '09, RFP questions
I had actually proposed moving to a unified version number system for consistency reasons (not for quality clarity). The problem with that strategy is that all the OWASP projects out their already have their own version naming scheme. My recent survey across OWASP projects has shown that project owners are all over the map with how they name their releases.
I don't think that a version numbering system really improves the clarity for the "quality" of a release as it actually inhibits the flexibility of a developer to make incremental changes. For example, if I have a final release version 2.0 of OWASP FooBar. After release, I notice a small but critical error that I want to correct and is easily reviewed, but what should I call that? I can't make it 2.0.1 because then that's suddenly an "alpha" release, but jumping to version 3.0 is inappropriate for such a small fix. Ultimately, we want to be as un-intrusive as possible to project leaders while still being able to provide a general framework for all OWASP projects.
We have discussed at length various other ways to characterize quality, but ultimately, we found tagging releases with these qualifiers (alpha, beta, stable) gives us the framework to express quality level while giving the flexibility of version naming decisions to developers.
Note that identifying the quality of releases this is a problem that's experienced all over (see:
For open source products (which is categorically what we deal with at OWASP), "stable" seems to be a generally accepted term to refer the highest quality version of a release.
-jason.li at owasp.org-
On Thu, May 14, 2009 at 1:54 PM, Boberski, Michael [USA] <boberski_michael at bah.com> wrote:
> I'd propose moving to a versioning system then, and dropping yet another confusing word. Perhaps rip off language from a CM manual or from CC CM requirements, something like that. Propose e.g. establish criteria for 1.x, 0.x, 0.0x releases.
> The dough should be clarified on the page, otherwise you'll have to cull whole bunch of 20k proposals and watch people withdraw them after they realize they won't be getting paid to cover all the actual work. Propose fix the amount or list "tiers" or amounts that may be awarded based on scope etc.
> Also, assessment critieria 2.0 wiki pages and page organization are both confusing to me. Really shouldn't take more than a page in my mind.
> Mike B.
> -----Original Message-----
> From: li.jason.c at gmail.com [mailto:li.jason.c at gmail.com] On Behalf Of
> Jason Li
> Sent: Thursday, May 14, 2009 1:46 PM
> To: Boberski, Michael [USA]
> Cc: paulo.coimbra at owasp.org; Global Projects Committee
> Subject: Re: [GPC] SoC '09, RFP questions
> 3) The rationale for changing "Release" quality to "Stable" quality was because it was becoming cumbersome to talk about "alpha releases", "beta releases", and "release releases".
> All of these are types of "releases" and our anecdotal studies showed that people found it confusing. Even in the "real" world, I don't think there's any true consensus on "version naming". Alpha and beta are pretty universal in their usage. But you'll find many projects like Eclipse and various Linux distributions that characterize their high quality releases as the latest "Stable" release while other projects just simply drop the alpha/beta tag from the version number to indicate the project is ready for prime time. "Stable" was the best "qualifier" we could find to differentiate between quality levels of releases.
> 4) I don't believe that the grants were ever intended to cover the actual "cost" of work. My view is that SoC offers the opportunity for OWASP to "encourage" its community to produce something of value. In previous years, there have been some items that have been granted based on actual costs - things like graphic design that were contracted out to "real" companies. However, that was more a function of the fact that OWASP did not have a framework to fund activities other than through SoC. We recently abstracted the OWASP Grant framework away from SoC to account for this so it's my expectation that we should no longer see any SoC grants that are used to cover "actual" costs. Such activities should now instead fall under a general OWASP grant.
> I'll be honest and admit that I'm not sure why there's a mention of "up to 20k" in the guidelines: Dinis | GPC - can anyone comment on this?
> -Jason Li-
> -jason.li at owasp.org-
> On Thu, May 14, 2009 at 1:11 PM, Boberski, Michael [USA] <boberski_michael at bah.com> wrote:
>> Jason, a few follow-up questions:
>> Question #3. What was the rationale from changing "Release" quality
>> to "Stable" quality? I understand the intent, but do we not want to
>> underscore that releases for us mean the same as in the commercial world?
>> Question #4. Are the proposals intended to be "realistic"? E.g.
>> there's mention of joint proposals up to 20k. The SoC grants were all
>> (?) e.g. 2.5k, more incentive-type amounts than amounts intended to
>> cover the actual cost of the work.
>> Mike B.
>> From: li.jason.c at gmail.com [mailto:li.jason.c at gmail.com] On Behalf Of
>> Jason Li
>> Sent: Thursday, May 14, 2009 12:48 PM
>> To: Boberski, Michael [USA]
>> Cc: paulo.coimbra at owasp.org; Global Projects Committee
>> Subject: Re: [GPC] SoC '09, RFP questions
>> I was not able to attend the recent meeting the GPC had in Poland
>> regarding the SoC protocol, but here was my understanding of it prior
>> to that meeting and I do not believe the rules of engagement have changed.
>> With regards to your first question, yes, we are relying more on
>> project proposals this year. We are hoping for this season of code to
>> be geared more towards improving existing projects rather than create
>> a new wave of new projects by having a list of projects as in the
>> previous year. That is not to say that we will not accept any new
>> ideas - any proposal will be accepted for review by the SoC Jury. But
>> rather than provide a list of ideas which encourages a tide of new
>> projects, we're hoping to focus on improving existing projects while
>> still allowing new and innovative project ideas to pop up.
>> Also, as you may have seen in traffic on the list, we are currently
>> in the process of identifying projects that have been abandoned by
>> their project leaders and it's our intention to include these
>> projects as an adoption option for SoC when it is officially launched next week.
>> In regards to your second question, this discussion was undergoing
>> much debate but I believe the conclusion was that there is no mandate
>> to reach any particular quality level. It will be up to the project
>> proposer to create a clearly defined roadmap with milestones and for
>> the proposer to identify which quality level they wish to reach. The
>> SoC Jury will examine the project roadmap and deliverables and take
>> into consideration whether the quality level identified in the
>> roadmap is appropriate for the amount of work proposed for the
>> project. As appropriate, the SoC Jury will provide feedback on proposals if they feel the quality level is too low.
>> As an extreme example, a project proposal to create a one page
>> cheat-sheet for CSRF that selects "Alpha" quality will most likely be
>> referred back to the proposer with a request that the proposal target
>> "Stable" quality as the amount of work involved in a one page
>> cheat-sheet should allow for reaching "Stable".
>> On the other hand, a project proposal to create a comprehensive
>> security framework like ESAPI for say, PHP, that selects "Alpha"
>> quality may be viewed more favorably because the expected work
>> involved may be considerably more.
>> Regardless of the quality level selected, the SoC Jury will also be
>> judging the project roadmap to ensure that the deliverables and
>> milestones are appropriate; payment for SoC will be directly tied to
>> completion of the project's proposed milestones in the roadmap and
>> therefore it is expected that the roadmap will include significant detail about the work involved.
>> Hope that helps! LMK if you have further questions.
>> -Jason Li-
>> -jason.li at owasp.org-
>> On Thu, May 14, 2009 at 12:25 PM, Paulo Coimbra
>> <paulo.coimbra at owasp.org>
>>> I thank your interest and pertinent questions and I am carbon
>>> copying the Global Projects Committee as its members may want to
>>> provide the adequate answers.
>>> Paulo Coimbra,
>>> OWASP Project Manager
>>> From: Boberski, Michael [USA] [mailto:boberski_michael at bah.com]
>>> Sent: quinta-feira, 14 de Maio de 2009 16:27
>>> To: Paulo Coimbra
>>> Subject: SoC '09, RFP questions
>>> Paulo, looking at
>>> http://www.owasp.org/index.php/OWASP_Season_of_Code_2009, I have a
>>> few questions.
>>> Question #1. Is it correct that there is not a list with specific
>>> requests for proposals as was done with the SoC '08, that instead
>>> you're relying on participants to propose specific projects, ideally
>>> that fall within those four listed areas?
>>> Question #2. Do projects need to reach Alpha or Beta quality?
>>> Mike B.
>>> Global-projects-committee mailing list
>>> Global-projects-committee at lists.owasp.org
More information about the Global-projects-committee