[Owasp-leaders] Projects

Wed Mar 2 00:04:30 EST 2011

I think Jason has a good handle and I appreciate his leadership in tackling
a monstrous effort, which ironically will probably take an enormous amount
of collaborative energy. By the way, the call last night was related to
developer outreach which encompassed feedback on how overwhelmed developers
are when deciphering proper uses of the myriad of OWASP projects. (don't
shoot the messenger.or echo).  Jason, let me know how I can help.

Overall my point was simply on organization of projects.  At a superficial
glance, insinuating a moratorium to projects may translate to 'roadblocks'
or stifling creativity and volunteerism. However, understanding the true
context of the idea behind a moratorium, break, pause or any other less
threatening synonym is the idea to stop, and organize our projects, so that
we can improve the way that we (1)understand, (2) market, and (3) manage
these projects over their lifecycle to the global corporate, govt
communities at large - a benefit that ultimately serves the creativity and
energy of the project owners. 

I also think that insinuating a loss of enthusiasm and drive around project
development, amidst a moratorium, particularly when no length of time for
such a moratorium was mentioned, assumes a great deal and underscores the
commitment of the community involved.

Tony UcedaVelez, CISM, CISA, GSEC

Atlanta Chapter President

Membership Committee Global Board Member

OWASP Atlanta

http://www.owasp.org/index.php/Atlanta_Georgia

Twitter: @versprite

From: Dave Wichers [mailto:dave.wichers at owasp.org] 
Sent: Tuesday, March 01, 2011 10:38 PM
To: owasp-leaders at lists.owasp.org; 'Tony UV'
Subject: RE: [Owasp-leaders] Projects

I think letting energetic project leaders start or continue projects now is
critical. The last thing we want to do is throw up roadblocks in front of
their volunteer efforts.

Otherwise they will take their ball, and enthusiasm, and go home, or
somewhere else, and we all lose.

-Dave

From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Jason Li
Sent: Tuesday, March 01, 2011 9:54 PM
To: Tony UV
Cc: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Projects

Tony,

I'm not sure what call you're referring to - was this a Global Industry
Committee call?

I agree that there needs to be a push to quality for projects at OWASP and
the rest of the GPC has long recognized this need. In fact, we had several
working sessions during the Summit devoted to addressing this issue. As
OWASP's brand and recognition grow, and as other organizations start to
depend on projects from OWASP, we need to have a mature and consistent way
to ensure that those projects are of high - dare I say, "production" -
quality.

At the same time, the OWASP community has always been organic and some of
our best projects have simply been the confluence of an enthusiastic project
leader, a supportive projects community, and a little bit of luck. Some of
our most prominent projects in the last few years, like the ESAPI project or
the LiveCD project, came together because someone had an idea, OWASP had a
community, and the project leader ran with it. As an organization of
volunteers, we all have constraints on our time. What would happen if a new
project leader with an idea came to OWASP and was told "yeah, that's a great
idea - but don't start it for 3 months"? We would probably lose the energy
of that individual - and maybe we end up losing the next Top Ten, or the
next LiveCD project. One of the greatest assets that we have as a volunteer
organization is the energy of our volunteers and I think that we should not
squander it. If someone wants to donate their time and energy, we should let
them!

Of course we still need some way to address the ever growing library of
OWASP projects and it's true that the GPC has stalled in the last 8-10
months in our progress to try and sift through the projects.  But it's my
belief that the stall happened not because of the volume of projects, but
our failure to put in place a reasonable and complete process.

After the 2008 Summit, we started drafting the Assessment Criteria v2 and we
knew from the start that there would have to be two components to evaluating
a project: the quality of an individual project release, and the quality of
an overall project. By the 2009 Mini-Summit, we had established part of the
Assessment Criteria v2 as an initial process for establishing a base level
of quality for releases - but this was not completed for the overall quality
of a project.

Unfortunately the "Alpha", "Beta", and "Stable" designations for releases
have since been usurped for entire projects (as currently displayed on the
OWASP wiki). We got bogged down in a number of issues in 2010 and never
circled back around to establishing a process for evaluating the quality of
projects. I believe that's really at the heart of what many people have
raised: we have a mountain of projects and no way to differentiate the
mature projects with large user communities and followings, from the
projects that are still in their infancy and developing, from the projects
that have had their time and are no longer relevant, from the projects that
are useless or have been all but abandoned. We hope to change that with the
OWASP Project Lifecycle.

As I mentioned, the GPC had an extremely productive working session at the
last Summit where we proposed a lifecycle that we think will help address
the concerns of quality vs quantity. The ideas were fairly well received and
while we're still fleshing out the full process, any additional feedback is
certainly welcome.

Our proposal is to create four classes of OWASP projects: OWASP Incubator,
OWASP Labs, OWASP Mainstream, and the OWASP Graveyard. These classes are
modeled after similar designations at the Apache Software Foundation, but
tailored to our community. See this overview document
(https://docs.google.com/document/pub?id=1X3SrP_gJAQ3VVQJr86NahrkUtU8OK1Vx_L
OxcfsF97A) and this detailed lifecycle diagram
(http://www.owasp.org/images/c/cd/GPCProjectLifecycleWorkflow.png).

OWASP Incubator projects would be projects that are just starting out and
still finding their way. There would be very few restrictions on incubator
projects and the idea is to facilitate and encourage anyone that wants to
donate their time to a new project idea to contribute. This area would
address the organic birth of many of our best projects.

OWASP Labs projects would be projects that have matured, been fleshed out
and are generally stable. In order to "graduate" from the Incubator to the
Labs, projects would have to show that they are functional, usable and have
the qualities of a "good" OWASP project (pass the sniff test so to speak).
Projects that live in the Labs would be stable, but perhaps might not be
production ready.

OWASP Mainstream projects would be the projects out of the Labs that the
OWASP community establishes are our truly flagship projects that are so
important and useful to the world at large that we need to throw our
organizational resources at supporting these projects. That includes
ensuring that: project leaders and contributors stand by the project with
regular update cycles and bug fixes; a large enough community is available
to answer questions about the project; releases are polished (e.g.
print-worthy book, quality graphic design work, etc) -  so that the project
is as close to "production" level as a non-product based organization like
ours can really aspire.

OWASP Graveyard would be the official way to archive or retire projects that
are no longer useful or that can no longer be supported.

The goal of this lifecycle is to ensure that we keep the spirit of organic
development but are still moving to improve the quality of OWASP projects.

As I alluded to in an earlier email, the challenge for us is to set up the
lifecycle so that we projects *want* to take part in the lifecycle. We've
been discussing with the Conferences Committee and the Connection Committee
about ways we can leverage other activities within the organization to
establish incentives for projects to adopt the lifecycle. This list is *not*
final and is only initial ideas, but for example:

- An updated projects portal would highlight particular projects based on
automated projects

- A limited number of AppSec conference slots could be allocated
specifically for OWASP talks - including potentially funded opportunities
for standout projects to present their latest release

- Interview and article slots could be given in the OWASP Podcast and
Newsletters

- "OWASP Points" would be awarded to projects as they achieve certain
milestones

- Provide paid graphic design or technical writing resources

- etc.

We would utilize those incentives to encourage project leaders to move their
project up the chain by say, "graduating" from the Incubator to the Labs, or
being "promoted" from Labs to Mainstream. Each designation requires an
increasing commitment to quality. Graduating and promoting might even
include being subsumed or merged into a high level OWASP project or altered
to comply with a specific output standard if it's strategically beneficial
to the incorporation of other projects (the perfect example of a
organizational strategic goal is the unified numbering system for the Dev,
Testing, and Code Review guides). Failure to maintain the level of quality
would result in project demotion.

I feel the most important aspect of this strategy is that we are not forcing
project leaders to do anything - because we're all volunteers and ultimately
we can't "force" anyone to do anything. We are simply trying to create a
system where project leaders *want* to embrace certain quality standards and
push themselves to Mainstream, and at the same time project consumers can
easily identify that a project may not be product-quality based on the
Labs/Incubator designation. (consumers include the greater OWASP community
so we know which projects to promote in our conversations, chapter meetings,
etc).

We believe this lifecycle has the potential to give us the best of both
worlds: namely maintain a community where project ideas are freely explored
and encouraged, while still providing the avenue for us to push projects to
a greater degree of quality that we all recognize is necessary for OWASP.

Having outlined this vision, let me return to why I personally don't think a
moratorium on projects is warranted or effective. The reality is that, while
it's true that Paulo is extremely busy with project management, even if we
stopped accepting new project ideas right now, that would not allow us to
improve the quality of our existing projects. Our limiting factor right now
is that we don't have a good, objective process to evaluate the quality of
projects. As a result, we don't really gain anything by instating a
moratorium. Now, once we have a good evaluation process in place, and the
infrastructure to support it, then maybe it *might* make sense to impose a
moratorium. Hypothetically, we would be in a position to put a well defined
time boundary on the moratorium while we execute the process and migrate the
appropriate projects. But until that process and infrastructure in place, we
would stand to lose a lot by halting the adoption of new project ideas.

To the extent possible, I believe we should commit to as much
parallelization as we can - establishing the processes and infrastructure to
support quality projects, while continuing to accept new project ideas.

Obviously we are very open to ideas and suggestions!

-Jason

On Tue, Mar 1, 2011 at 7:57 PM, Tony UV <tonyuv at owasp.org> wrote:

Was there anyone on the call last night/ early morning where we discussed
the snowballing effort that projects is has taken and continuous to take?
I'm not here to stunt innovation but I for one don't see the impact of a
moratorium over a short and well defined/ managed period of time where
projects are properly categorized. I think the global OWASP community will
appreciate this organizational effort as well since, to Chris' point, they
get overwhelmed and quite honestly desensitized to the number of projects
that we have/ host/ manage.  

Ultimately, if we take 1,2, 3, x months as part of a moratorium, what impact
would be experienced? Is there a build schedule that we have that I'm not
aware of?  If not then I think a time out in the name of organizational will
go a long way. 

These are just my 0.02 and I obviously support Jason's discretion but would
love to hear other leaders who don't voice their opinions to often in these
threads to see if they can provide some localized feedback to the contrary
or in support of the notion that we have too many projects for our audience
to decipher and use.  If the moratorium will help us define metrics for
success, marketing, implementation cases, etc for each project, I think this
will serve as a great value add worth waiting for.

Tony UcedaVelez, CISM, CISA, GSEC

Atlanta Chapter President

Membership Committee Global Board Member

OWASP Atlanta

http://www.owasp.org/index.php/Atlanta_Georgia

Twitter: @versprite

From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Chris Schmidt
Sent: Tuesday, March 01, 2011 6:44 PM
To: Jason Li; Leaders
Subject: Re: [Owasp-leaders] Projects

Well said Jason - 

I tried to be clear that I don't want to dissuade anyone from starting new
projects, especially with the amazing amount of momentum that we have right
now - however, I just wanted to make sure that we set real expectations for
any new projects. Also - one of the biggest things I have heard about
projects since and during the summit is that right now, flat out - there are
just too damn many of them. Adding more projects to the stack is not going
to help anyone at all, so my thinking is code away get it right, get it
good, then migrate it to an official OWASP project. There is nothing that
says you can't start your project on Google Code, or SF, or Java.Net or any
other host, get it to a point where you have an artifact and then start the
process of making it an OWASP Project. This is exactly what I am doing with
jQuery-Encoder that I have been working on. 

On 3/1/11 6:37 PM, "Jason Li" <jli at owasp.org> wrote:

While I agree that it's a gargantuan effort do any project migration, I
don't think it's appropriate for us to put a moratorium on new projects.

As noted at the Summit, we're still in the early stages of reaching out to
project hosting services - it could be a several months or more before we
have the infrastructure in place. As much energy as we have in pushing the
project hosting forward, the reality is that these things sometimes take
longer than we wish. The cloud hosting for the OWASP website is a great
example of this --- no one would be more happy to see that pushed forward
than Larry and Matt who have been working hard for over a year. But there
are still several logistical hurdles for them to clear. I hope that we don't
have the same issues on the project hosting side, but there's not guarantee
of that and I don't think we should delay development of new incubator
projects until we have such infrastructure.

We also still haven't hashed out the rules of engagement for the proposed
project lifecycle. While we are looking at the project hosting solution as
*the* centralized repository for OWASP coding projects, there's still
considerations to be made and discussions to be had about how it fits into
our lifecycle. After further consideration, it's perfectly possible that we
will decide that the OWASP repository is for Labs/Mainstream projects and as
part of the Graduation Process, Incubator projects migrate their
repositories to the centralized OWASP repository. Nothing is set in stone.

The onus is on us in the GPC to settle these issues quickly, but I don't
believe we should delay other projects while we consider these issues.

We can discuss further during the GPC meeting next week.

-Jason

On Tue, Mar 1, 2011 at 8:24 PM, Chris Schmidt <chris.schmidt at owasp.org>
wrote:

All - 

Given the things that the projects committee is currently in the process of
doing (hosting, process, etc.) I think it would behoove us to put a hold on
any new code projects until after we get the new platform at least partially
implemented. We are already looking at a very time-consuming process to move
all 170+ existing OWASP Code Projects to the new platform, and as such -
adding new ones while we are in the transition and planning phases is
ultimately just going to make things more difficult. 

That being said, I would recommend that the idea be that any code projects
that start are notified that when the platform comes up, they will be
expected to 

1.	Move their own project to the new platform (if required - the new
platform could still be hosted on Google Code) 
2.	Register their project through the appropriate means once the
platform is ready to rock.

I don't want to discourage new thinking, but I also don't want to spend 3
months getting things moved over once we have our platform ready. 

Chris Schmidt
ESAPI Project Manager (http://www.esapi.org)
ESAPI4JS Project Owner (http://bit.ly/9hRTLH)
Blog: http://yet-another-dev.blogspot.com

_______________________________________________
OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-leaders

Chris Schmidt
ESAPI Project Manager (http://www.esapi.org)
ESAPI4JS Project Owner (http://bit.ly/9hRTLH)
Blog: http://yet-another-dev.blogspot.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20110302/a2a448b7/attachment-0001.html 