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

johanna curiel curiel johanna.curiel at owasp.org
Wed Aug 27 19:08:58 UTC 2014


> good appsec ideas fail due to project management issues

Well Timur, not every project leader will become a good project manager.
Only time will tell. An idea is not a project and the person responsible to
bring that idea to a project is the leader.

The best example of this is Facebook. The Winkelvoss brothers also had a
great idea but they could not executed . Execution is the most important
thing when working on a project. If you just hang with the idea an no
execution plans then is destined to fail.


On Wed, Aug 27, 2014 at 2:57 PM, johanna curiel curiel <
johanna.curiel at owasp.org> wrote:

> 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/f32cdb38/attachment-0001.html>


More information about the OWASP-Leaders mailing list