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

johanna curiel curiel johanna.curiel at owasp.org
Thu Aug 28 16:02:07 UTC 2014


 >May I suggest that we hire a professional publisher to help us with
writing process of major documents.

Jim, how do we get this moving? I think the IEEE document makes us look
real bad ;-P


On Thu, Aug 28, 2014 at 11:31 AM, Jerry Hoff <jerry at owasp.org> wrote:

> Jim,
>
> I think that is absolutely reasonable - the idea would be a software
> foundation would agree to support and maintain the library, but having
> OWASP missionaries / thought leaders involved in the evolution of the
> security control libraries would be ideal.
>
> Jerry
>
>
> --
> Jerry Hoff
> @jerryhoff
> jerry at owasp.org
>
>
>
> On Aug 27, 2014, at 11:22 PM, Jim Manico <jim.manico at owasp.org> wrote:
>
>  Quite a reasonable opinion, Jerry. And I think it's fair to somehow
> collaborate with a real software foundation for these software control
> projects. But I'd still like OWASP involvement somehow....
>
> Perhaps a partnership were we use Apache's[1] process and infrastructure,
> but have an OWASP volunteer manage it?
>
> [1] Or some other software foundation....
>
> Aloha,
> Jim
>
>
> On 8/27/14, 12:23 PM, Jerry Hoff wrote:
>
> Agree with Johanna - ideally successful poc security controls "graduate"
> to apache, Mozilla or some other group to maintain production quality
> projects. My main concern are SLAs and long-term support.
>
>  These controls will be in production for years and years and years -
> security controls will always need continual support and updates. Since
> OWASP can't legitimately make that support commitment at this time, I think
> we should encourage foundations with paid, full time developers and a
> tested software development infrastructure would be the best place for
> these projects to live.
>
>  Again, merely my opinion...
>
>  Jerry
>
> --
> Jerry Hoff
> jerry at owasp.com
> @jerryhoff
>
> On Aug 27, 2014, at 22:16, johanna curiel curiel <johanna.curiel at owasp.org>
> wrote:
>
>   >There are several more of these mini-control projects popping up (safe
> File IO, advanced logging, etc). And I think it's a good idea to keep
> supporting them.
>
>  Jim, I believe we should definitely work on security libraries, I
> just don't know if OWASP as an organization should  provide any from
> of guarantee to users.
>
>  >2) Both built and maintained by PhD level computer programmers.
>  Ph.D doesnt says much to me, an example , Long-Term Capital Management
> was full with Ph.Ds that almost caused the biggest Stock market
> crash..Financial Times described it as "the fund that thought it was too
> smart to fail"
>
>  So being that said,  I don't think we questioned the intelligence of the
> people working in these libraries, but I questioned who's responsibility is
> , or since these are Open Source project, OWASP should not feel
> this responsibility at all
>
>
> On Wed, Aug 27, 2014 at 3:08 PM, johanna curiel curiel <
> johanna.curiel at owasp.org> wrote:
>
>>  > 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 <%28808%29%20652-3805>
>>>>>>>>>>> <tel:%28808%29%20652-3805> <%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
>>>>>>>>>>>
>>>>>>>>>> ...
>
> [Message clipped]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140828/50c854c7/attachment-0001.html>


More information about the OWASP-Leaders mailing list