[Owasp-leaders] Proposing new guidelines to start code/tool projects

johanna curiel curiel johanna.curiel at owasp.org
Wed Aug 27 18:57:39 UTC 2014


Personally i believe we are not a software foundation, we don't have
professional, full time developers, *we don't have the infrastructure, so
at this time I'm not a big fan of advertising production quality /
production ready security controls*

Jerry, you have nailed with your comment. We just don't have the capacity
to have test Quality as suggested by Timur and honestly I dont even know if
this should be our mission. Timur I appreciate your comments, just keep in
mind that OWASP does not have a staff nor a team of volunteers to do this.
We are working with realistic down to earth resources and if a project has
had not had a single release that is more than enough criteria to discard
it as inactive.

Security controls to be used in a production environment - not so cool (in
my opinion).
Agree, level of responsibility is quite high for these kind of projects


On Wed, Aug 27, 2014 at 2:37 PM, Jerry Hoff <jerry at owasp.org> wrote:

> I'm probably the only one, but I really don't think owasp should be
> building and promoting security controls and advising them to be used in
> production.
>
> Poc security controls are cool, testing tools are super cool, and learning
> tools are super cool - but security controls to be used in a production
> environment - not so cool (in my opinion).
>
> What is our SLA if security or other bugs are found? What is our track
> record on actively maintaining security libraries over time? Security
> controls may need support over the life of an app, which could be 10 years+
>
> Personally i believe we are not a software foundation, we don't have
> professional, full time developers, we don't have the infrastructure, so at
> this time I'm not a big fan of advertising production quality / production
> ready security controls.
>
> Jerry
>
> --
> Jerry Hoff
> jerry at owasp.com
> @jerryhoff
>
> On Aug 27, 2014, at 21:11, "Timur 'x' Khrotko (owasp)" <timur at owasp.org>
> wrote:
>
> Consider approaching the project quality problem from a different angle.
> Any prominent OWASP project should also be degraded when its active support
> is abandoned, or its professional usefulness gets significantly lowered. We
> can't measure this problem simply by days of inactivity, number of edits or
> other quantitative properties.
>
> My suggestion (and probably it is also NIH)) would be to approach both new
> and old projects with a common criteria of quality.
> I don't mind how long it would take for a new project to achieve
> "selected" status, meaning that OWASP identifies with it professionally.
> I don't mind how long a new project tries to boot up, if it succeeds once
> then hurray, but with time its chances to become a noticeable project just
> get lower by the logic of things.
> I also suggest that if there is a good idea with bad management, then
> someone at OWASP, among us or Foundation, has to recognize it and not let
> the idea/project die. So it is not only the responsibility of the project
> leaders to let good projects mature. Moreover, I suggest it is our own
> failure if some really good appsec ideas fail due to project management
> issues, while mediocre ideas flourish due to ambitious leaders.
>
> So lets establish quality categories/statuses for OWASP projects (just as
> illustration):
> 1. Flagship -- 10 per a year, not only certified quality but heavily
> promoted, quality is certified by non-OWASP specialists as well
> 2. Selected -- the quality is certified by project review teams (there is
> a new organizational facility for it) and renown OWASP specialists
> 3. Incubator -- the idea is supported/reviewed by two OWASP
> specialists/mentors, active
> 4. Everything else -- new ones, not yet recognized startups, and old ones,
> even ex-flagships, that lost active support or got obsolete for other
> reasons.
>
> It also should count if a project, its page on owasp wiki or github gets a
> lot of hits, or its documents or binaries are downloaded frequently, or
> there is media buzz about it, a project was invited to conferences, etc.
>
> The system of days and milestones is good, it can motivate project
> leaders/members to work. So we may establish the notion of track, a project
> being on track. There can be rules of game for new projects to be on track,
> and some rewards for it. For example a new project which fulfills the
> startup track requirements receives mentors from OWASP, and they are
> obliged to give it a few hours of support and write a review. etc. etc.
>
> Regards:
> timur
>
>
> On Wed, Aug 27, 2014 at 10:35 AM, johanna curiel curiel <
> johanna.curiel at owasp.org> wrote:
>
>>
>> Yes this is a very important system and during the reviews we check if
>> projects have a issue tracking system.  This is par tof the health criteria
>>
>> On Wednesday, August 27, 2014, Dinis Cruz <dinis.cruz at owasp.org> wrote:
>>
>>> This is a good model and I think the balance is right (between allowing
>>> innovation and pushing for quality)
>>>
>>> From a management/tracking point of view we could also push for the use
>>> of issue tracking systems (like GitHub issues, bugzilla, jira) to
>>> document/track activities on that project (ie even a project with no code
>>> should have a healthy number of issues opened/closed)
>>> On 23 Aug 2014 18:49, "johanna curiel curiel" <johanna.curiel at owasp.org>
>>> wrote:
>>>
>>>> Leaders,
>>>>
>>>> After hearing your concerns and some ideas from Kait-Disney and the
>>>> project task force members, I'm proposing the following , which hopefully
>>>> will help us reach better guidelines and less empty projects
>>>>
>>>> We will allow Incubator projects a 1 year deadline BUT with the
>>>> following conditions:
>>>>
>>>>    - They will need a clear deadline proposal roadmap for the next 90
>>>>    days
>>>>    - We will provide an example on the wiki template of what we expect
>>>>    to see
>>>>    - We will provide a 'Start up kit' cheat sheet with all the
>>>>    goodies(how to get money for project, participate in Google Summer of code
>>>>    program, Winter of Code program, Wiki template, Project summit
>>>>    presentations,Github repository etc)
>>>>    - If they do not present a clear roadmap with deadlines, the
>>>>    project will not be accepted
>>>>    - They need to have a repository even if empty, because this will
>>>>    allow us to automate the monitoring of their progress
>>>>    - The wiki page must be COMPLETE. No empty descriptions or half
>>>>    info there. This will be not accepted.
>>>>
>>>>
>>>> We will create a webbot to track all wiki project pages based on the
>>>> latest updates and based on that we will create reminders every 90 days
>>>> about the activity to ALL project leaders (not just incubators).
>>>>
>>>> General rules for all projects:
>>>>
>>>>    - Project leaders will receive 1 reminder if the project hasn't
>>>>    been updated at all in 90 days.
>>>>    - Project leaders will receive 1 warnings  if no commit or wiki
>>>>    update has been done in 80 days or if they dont feedback with us about the
>>>>    situation of their project
>>>>    - The third one will be final and the project will be set in the
>>>>    inactive list
>>>>    - Remember you can always revive the project but you will need a
>>>>    roadmap in order to do this.
>>>>
>>>>
>>>> regards
>>>>
>>>> Johanna
>>>>
>>>>
>>>>
>>>> On Thu, Aug 21, 2014 at 11:09 PM, johanna curiel curiel <
>>>> johanna.curiel at owasp.org> wrote:
>>>>
>>>>> Jim and leaders,
>>>>>
>>>>> The idea of the whiteboard is that no one needs to maintain this ;-).
>>>>> Is just a whiteboard with idea-projects hanging there in order for people
>>>>> to join and find contributors to pull off their project. What I'm trying to
>>>>> do is be realistic about the maintenance of project inventory and how OWASP
>>>>> looks to the outsiders. Empty projects looks really bad. Dont expect
>>>>> potential users to go read your roadmap and comeback when you say you are
>>>>> ready.
>>>>>
>>>>> On the other hand, the 90 day issue is, that sometimes an idea takes
>>>>> time to develop, find contributors and the opportunity to work on
>>>>> it.Therefore future project leaders should made use of programs such as
>>>>> Google Summer of Code. Some of the best ideas I have seen have flourished
>>>>> during this program. If you want this into production, project leaders can
>>>>> place their ideas in the Gsoc idea page (
>>>>> https://www.owasp.org/index.php/GSoC2014_Ideas) jump the wagon to get
>>>>> students, apply to develop the 'idea'. OWTF, ZAP, PHPSEC, WEBGOATPHP have
>>>>> made enormous progress during this program, and when we did the call, only
>>>>> 12 projects applied!! So where are the active project leaders even when
>>>>> they had a chance like this to get a student paid for 3 months to work on
>>>>> their projects including 500 dollars for their project per student ?
>>>>>
>>>>> >In the past, many project got approved that probably should not have
>>>>> been, but I'm trying to ensure that fully formed project ideas are the ones
>>>>> that make it through.
>>>>> I believe this will definitely help put a minimum entry level.
>>>>>
>>>>> I  would like to find a middle ground to have a realistic review
>>>>> process based on our capacity to review projects,allow ideas to develop but
>>>>> also, have better quality for potential users of OWASP projects.I repeat ,
>>>>> empty project pages might have been the norm but this really looks bad.
>>>>>
>>>>> regards
>>>>>
>>>>> Johanna
>>>>>
>>>>>
>>>>> On Thu, Aug 21, 2014 at 10:34 PM, johanna curiel curiel <
>>>>> johanna.curiel at owasp.org> wrote:
>>>>>
>>>>>> Hi Kait (Gregory)
>>>>>>
>>>>>> I agree with  you on this and I think that the problem has been this :
>>>>>>  * when they submit their project they have an outline of the
>>>>>> project and a roadmap*
>>>>>>
>>>>>> If you take a look of those empty projects , their outline is way to
>>>>>> vague, not even a clear description of what the project is about is and
>>>>>> there is not a clear plan for the roadmap. So we really need to review
>>>>>> more careful when allowing an incubators begin. Ideally we should provide a
>>>>>> clear example. The 90 days deadline sounds very good to me.
>>>>>>
>>>>>> The idea of a 90 day puts pressure into it. After 90 days no code,
>>>>>> then inactive.
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> Johanna
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 21, 2014 at 10:20 PM, Gregory Disney <
>>>>>> gregory.disney at owasp.org> wrote:
>>>>>>
>>>>>>> Repost from Kait, because she keeps getting kicked off the leaders
>>>>>>> list.
>>>>>>>
>>>>>>> ==========================================================================================
>>>>>>> I brought this up with Johanna earlier today in regards to what
>>>>>>> should be done with new projects.
>>>>>>>
>>>>>>> It's my opinion that requiring new projects to have source code
>>>>>>> written before they can become a project will alienate would be project
>>>>>>> leaders. For many new projects, when they submit their project they have an
>>>>>>> outline of the project and a roadmap. This is especially true for
>>>>>>> documentation projects, which may not have a draft yet at the time they
>>>>>>> apply.
>>>>>>>
>>>>>>> I propose instead that we continue to approve projects that have a
>>>>>>> flesh out project outline and require that they have progress on the
>>>>>>> project within 90 days. After 90 days, these new projects should be
>>>>>>> reviewed for progress. This doesn't have to be an in-depth review, more of
>>>>>>> a check in with the project leader to see if their repository is posted, if
>>>>>>> they have source code, or a draft in cases of documentation projects.
>>>>>>> If after 90 days, there has been no progress on the project, those
>>>>>>> project should be considered inactive.
>>>>>>>
>>>>>>> By making progress a requirement in the first 90 days, we can avoid
>>>>>>> the problem we have now, which is that several projects that enjoy active
>>>>>>> project status while having never produced anything for the project.
>>>>>>>
>>>>>>> Please let me know what you think.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 21, 2014 at 7:14 PM, Jonathan Marcil <
>>>>>>> jonathan.marcil at owasp.org> wrote:
>>>>>>>
>>>>>>>> Oh I see, if you want to add another step in the new project
>>>>>>>> adoption
>>>>>>>> life cycle.. well go ahead!
>>>>>>>>
>>>>>>>> Also, if there's no time limit, you'll kill that special motivation
>>>>>>>> of a
>>>>>>>> urge to deliver something. For some people it may actually help
>>>>>>>> motivate
>>>>>>>> them to release. Others will release anyways. Pressure can be good.
>>>>>>>> It
>>>>>>>> can be another period than one year.. maybe 6 months I don't know.
>>>>>>>>
>>>>>>>> All that said, I hope you don't plan to move everything to
>>>>>>>> whiteboard by
>>>>>>>> default.. As a project starter, I kind of accepted the rule of "one
>>>>>>>> year
>>>>>>>> or the project is out of incubator" and would not like the rules to
>>>>>>>> change in the middle or having to adhere to another process I won't
>>>>>>>> need
>>>>>>>> in 2 months. Good news about that is that if you apply the one year
>>>>>>>> timeout of the initial agreement, you'll be free of "dead" incubator
>>>>>>>> projects within one year anyways.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> - Jonathan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2014-08-21 21:52, johanna curiel curiel wrote:
>>>>>>>> > Jonathan and leaders
>>>>>>>> >
>>>>>>>> > I would love to allow idea-projects hang for a year but what I
>>>>>>>> have seen
>>>>>>>> > after reviewing this for almost 2 years, that the project leader
>>>>>>>> looses
>>>>>>>> > pressure to create something in that period and many projects in
>>>>>>>> the end
>>>>>>>> > die like this.
>>>>>>>> >
>>>>>>>> > If we allow idea-projects hang for a year, the amount of work
>>>>>>>> becomes
>>>>>>>> > quite big with all the projects that must be reviewed and
>>>>>>>> managed. This
>>>>>>>> > process has failed twice, with the Global Committee and the
>>>>>>>> technical
>>>>>>>> > advisory board. Setting the bar higher challenges project leaders
>>>>>>>> to
>>>>>>>> > really work on it and not let it hang for a year, in the
>>>>>>>> meanwhile,
>>>>>>>> > people (potential users) of your project, visit the wiki and  get
>>>>>>>> > disappointed to see anything on it.
>>>>>>>> >
>>>>>>>> > The idea of the Whiteboard, can allow future project leaders to
>>>>>>>> set this
>>>>>>>> > as an idea-project and get contributors, but the expectations are
>>>>>>>> > different, especially for potential users. They know that this is
>>>>>>>> just
>>>>>>>> > an idea and the project hasn't developed yet. When you are ready
>>>>>>>> to take
>>>>>>>> > it to the next step, then it becomes a tangible project , and
>>>>>>>> once done
>>>>>>>> > that, then the real work begins to keep the project alive and
>>>>>>>> kicking,
>>>>>>>> > but thats much easier to monitor than communicating through email
>>>>>>>> every
>>>>>>>> > time to see if the project is alive and in the meanwhile the wiki
>>>>>>>> page
>>>>>>>> > is outdated and no code has been produced. It damages OWASP
>>>>>>>> reputation.
>>>>>>>> >
>>>>>>>> > We need to develop and design a 'Startup' like program where we
>>>>>>>> provide
>>>>>>>> > training to potential project leaders how to make that idea a
>>>>>>>> > prototype.Just like with 'Accelerators' . Since we work globally,
>>>>>>>> I
>>>>>>>> > think this should be available online (through courser for
>>>>>>>> example) and
>>>>>>>> > have this programs twice a year for example.
>>>>>>>> >
>>>>>>>> > regards
>>>>>>>> >
>>>>>>>> > Johanna
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Thu, Aug 21, 2014 at 9:30 PM, Jim Manico <jim.manico at owasp.org
>>>>>>>> > <mailto:jim.manico at owasp.org>> wrote:
>>>>>>>> >
>>>>>>>> >     > Last but not least, thank you a lot for your efforts
>>>>>>>> Johanna, you are
>>>>>>>> >     keeping the main backbone of OWASP healthy and not anyone has
>>>>>>>> the
>>>>>>>> >     courage and toughness to do so.
>>>>>>>> >
>>>>>>>> >     +1000
>>>>>>>> >
>>>>>>>> >     More positive work and progress around projects bas been done
>>>>>>>> in the
>>>>>>>> >     last few months than several years past. We are very lucky to
>>>>>>>> have
>>>>>>>> >     your "extreme volunteerism", Johanna.
>>>>>>>> >
>>>>>>>> >     PS: +1 On the sandbox idea. Perhaps call it "the whiteboard"
>>>>>>>> instead
>>>>>>>> >     of "sandbox" to denote an "IT centric idea"
>>>>>>>> >
>>>>>>>> >     Aloha,
>>>>>>>> >     --
>>>>>>>> >     Jim Manico
>>>>>>>> >     @Manicode
>>>>>>>> >     (808) 652-3805 <tel:%28808%29%20652-3805>
>>>>>>>> >
>>>>>>>> >     > On Aug 21, 2014, at 8:23 PM, Jonathan Marcil
>>>>>>>> >     <jonathan.marcil at owasp.org <mailto:jonathan.marcil at owasp.org>>
>>>>>>>> wrote:
>>>>>>>> >     >
>>>>>>>> >     > Last but not least, thank you a lot for your efforts
>>>>>>>> Johanna, you are
>>>>>>>> >     > keeping the main backbone of OWASP healthy and not anyone
>>>>>>>> has the
>>>>>>>> >     > courage and toughness to do so.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> _______________________________________________
>>>>>>>> OWASP-Leaders mailing list
>>>>>>>> OWASP-Leaders at lists.owasp.org
>>>>>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>
>>>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>
> Email us to enforce secure link with your mail servers (domain).
> This message may contain confidential information - you should handle it
> accordingly.
> Ez a levél bizalmas információt tartalmazhat, és ekként kezelendő.
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140827/31d8b716/attachment-0001.html>


More information about the OWASP-Leaders mailing list