[Owasp-leaders] On Project Reboots

John Wilander john.wilander at owasp.org
Tue Apr 10 10:51:40 UTC 2012


Are we asking ourselves why the OWASP Development Guide has not been
released in seven years? Is it because ...

   - No one knowledgeable in our community cares for it enough to spend the
   hours?
   - It's a failure in the sense that developers don't like it?
   - Commercial books such as The Tangled Web (
   http://nostarch.com/tangledweb) does a good enough or better job?
   - Our cheat sheets are more usable than a book?
   - We haven't spent enough money on the project?

Out of the suggested reasons above (and the ones I didn't think of) I
believe lack of money is the least probable.

There's plenty of former A-level FOSS that's no longer maintained. That's
the beauty and curse of open source stuff -- people only fix what matters
to them. Do we really have enterprises standing in line requesting a
Development Guide? If so, why hasn't anyone responded to this massive
demand in seven years? It's open - just fix it.

>From what I can see there was a Development Guide reboot in Feb 2010 --
http://owasp.blogspot.se/2010/02/owasp-development-guide-project.html. Even
an organizational and process chart --
http://owasp-development-guide.googlecode.com/files/guide-org-chart.pdf.
The OWASP-Guide mailing list peaked at 85 emails including digests right
after the reboot announcement (http://lists.owasp.org/pipermail/owasp-guide/).
But we still have no new guide.

Now, did they lack money or something else?

   Regards, John


2012/4/10 Eoin <eoin.keary at owasp.org>

> Hi Chris, John,
>
> Why did I even suggest a project reboot.
> Chapter meetings which are vitally important to the foundation will never
> have the impact across such a wide audience as our projects and guides do.
>
>
> The OWASP Development guide has not been released since 2005!!
> If we have funds I think we should spend on the right things.
> The point about leaders getting paid is a valid one, but why not pay our
> own people to do great things if we have the funds? (lets be radical for a
> minute)...Our material is and always will be open source but we shall pay
> an elite team to commit to rebuilding some old projects.....The reboot
> funding can also be used to pay for mini summits, marketing, awareness,
> fund training etc. But the older projects need a complete rewrite.
>
> Regarding chapters, I know of many many people who have never attended a
> chapter meeting but have based their internal guidelines on various OWASP
> materials.
> I also believe corporate supporters value our output, guidelines and
> tools. Or documents and guides also have proven to be valuable to the wider
> industry as can be seen on our citations<https://www.owasp.org/index.php/Industry:Citations>pages. These are areas where OWASP makes an impact.
>
> -ek
>
>
>
>
> On 10 April 2012 10:33, John Wilander <john.wilander at owasp.org> wrote:
>
>> I totally agree paying OWASP projects or project leaders is wrong. Dinis
>> convinced me at AppSec DC 2009. Whatever money OWASP can pay us it'll be
>> pennies compared to our daytime jobs. The only thing those pennies will do
>> is to remind project leaders and members that they can earn much more on a
>> paid job. Ergo less done for OWASP.
>>
>> We had a chapter meeting on open source security with the lead developers
>> of cURL (http://curl.haxx.se/) and GNU SASL (
>> http://www.gnu.org/software/gsasl/). They both had the same experience -
>> a successful FOSS project typically has numerous one-time committers and a
>> core of 1-3 long-time committers. The recently published study "Open Source
>> by the Numbers" (
>> https://events.linuxfoundation.org/images/stories/pdf/lfcs2012_sands.pdf)
>> shows only 17.3% of FOSS projects have at least one code commit the last
>> year. It also shows 50.7% have only one team member and another 20% only
>> two members.
>>
>> We have to start recognizing that free open source software is something
>> different from commercial, proprietary software. You can build FOSS to
>> prove a point, to make the world a better place, to build a personal brand,
>> to try out a new cool technology etc. But you don't do it to directly earn
>> money.
>>
>> OWASP projects will wither and die no matter how A-level or well known
>> they are. Look at WebScarab.
>>
>> My proposal:
>>
>>    - Make project leaders/teams state what level of commitment they
>>    intend to have when OWASP promotes their project to A-level. For instance
>>    "We will patch major bugs within 60 days of reporting and there will be new
>>    major releases at least once a year." Note that "We might not fix anything
>>    with this software" is a fine statement but will be weighed into the
>>    decision to promote or not. The leader's/team's commitment is published
>>    with the project.
>>    - If a project team fails to live up to its commitment it's
>>    immediately degraded to B-level. Not as a punishment, just as a reality
>>    check -- apparently nobody is caring for this project at the moment, right?
>>    The leader/team and the leaders' list should be notified.
>>    - Let projects ask for specific funding. Wanting to organize a
>>    hackathon or get a project page on a specific domain are viable causes for
>>    funding. Regular project work is not IMHO.
>>
>>
>> Side note: "OWASP is nothing without our projects." Whatever happened to
>> chapters? For me chapters are at least as much of a backbone as guides and
>> software. And chapters wither and die too.
>>
>>    Regards, John
>>
>>
>> 2012/4/9 Chris Schmidt <chris.schmidt at owasp.org>
>>
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I have also neglected to comment thus far on the Project Reboots stuff.
>>> I could go on and on and on about all the reasons that I don't really
>>> think this is a great approach to solve the problem - but I want to
>>> focus on a few key things. (Apologies if I jump around a bit in this
>>> e-mail)
>>>
>>> 1) Why is paying volunteers a bad idea?
>>>
>>> Reputation is worth a great deal more in the Infosec community. I am a
>>> living breathing example of this - had it not been for my involvement in
>>> ESAPI and OWASP I would have not been able to make the switch from being
>>> just another hobbyist security guy who writes software for a living to
>>> becoming a guy who writes security software for a living. It was a
>>> direct result of my involvement in OWASP that got me the job I currently
>>> have. Money is fine and dandy as a motivator, and it will likely spur a
>>> great deal of interest and energy in the projects that get "funded", but
>>> what happens when the project is complete and/or the funds run out? Will
>>> those same people stick around and put the same amount of energy into
>>> the project that they were when they were being recompensated
>>> financially to do so? My point here is that paying our volunteers to do
>>> what they have volunteered for completely undermines the entire ethos
>>> behind volunteerism and the spirit of OWASP IMHO. There are a great many
>>> ways that project leaders can be motivated without promising them money,
>>> ways that will be long-term solutions instead of a quick fix to address
>>> the symptoms instead of the problem. Essentially, in this case it feels
>>> like we are rewarding project leaders for bad behavior.
>>>
>>> We are essentially saying, "Listen, I know that you said you would lead
>>> this project - and you really haven't done so, so how about if I give
>>> you a few thousand clams? Will you do what you already said you would do
>>> for free then?"
>>>
>>> Additionally, by taking this path we are creating a set of expectations
>>> by other projects that is unhealthy. Why would I actively work on my
>>> project if I know I can just let it sit for a couple years and wait for
>>> the governance to come around and say ok, your project is important and
>>> we will pay you to quit sitting on your hands.
>>>
>>> 2) How can we re-focus our leaders without paying them?
>>>
>>> To me, this is a relatively simple problem to solve. Providing a project
>>> with the means to accomplish their goals *is* in the interest of the
>>> organization as a whole - rather than providing leaders with money for
>>> the promise of work done, why don't we instead provide them with the
>>> resources they need to get the work done. This could mean a lot of
>>> different things for a lot of different projects. As an example, I have
>>> been formulating the plans for a Hackathon for the ESAPI project to take
>>> place late this summer. This event will re-energize the project itself,
>>> bring in a lot of fresh new talent, and will result in some great new
>>> ideas from the real world on how to take the ESAPI project to the next
>>> level. This isn't for every project tho, and I am not every project
>>> leader. If there is something that we feel needs to be re-energized, we
>>> should be going to that project leader and saying "What can we, OWASP,
>>> be doing to energize your *project*? What tools or resources do you need
>>> to bring this project up to speed?" If the leader simply comes back
>>> with, "Well, I don't have time to work on this for free" then it sounds
>>> to me like they are not the right person to be leading that project.
>>>
>>> 3) Lastly, who are *we* to say what projects are important?
>>>
>>> This is a bit of a touchy one all the way around I think - we can use
>>> metrics to say what projects are our most referenced, or most
>>> downloaded. What we can't say is that one project is more important than
>>> another project because this is a subjective observation. ESAPI or
>>> AppSensor may be very important projects to some folks, but maybe Top
>>> Ten and Cheat Sheets are more important to these folks over here, ZAP is
>>> probably more important to breakers than ESAPI or AppSensor, while a
>>> builder will likely not regularly refer to the Testing Guide.
>>>
>>> I think it is important to enable the project leaders to come to us (the
>>> GPC or the board) with requests. We should be enabling projects to
>>> succeed and if we notice a project leader that isn't really fulfilling
>>> their duties and responsibilities as a leader then we should engage them
>>> at that point. This is generally made pretty clear on mailing lists and
>>> support forums by the communities that use that particular project. The
>>> bit that is missing right now is the means for a project leader to
>>> approach us and request things from us to help their projects. Maybe the
>>> testing guide needs a technical editor to compile and produce the final
>>> publishable output for the guide - the GPC and Board are in a position
>>> to reach out to the community and also to outside vendors to help fill
>>> these gaps where they make sense.
>>>
>>> It is interesting to note that I have no plans on coming to OWASP to
>>> provide funds for the ESAPI hackathon at all except as a last resort. I
>>> am counting on working with sponsors for the event to provide all the
>>> funding that I will need to make the event a complete success and then
>>> using this as a model to contribute a how-to-do-it-correctly kit back to
>>> the community so other project leaders can build on my success or learn
>>> from my failures to create their own events. I may come to OWASP to get
>>> information on our existing corporate sponsors so that I can reach out
>>> to them with proposals for sponsorship of the event, but I will do
>>> everything in my power to do this without using OWASP funds.
>>>
>>> Also in hindsight, another good way to get money together to help
>>> projects reach goals is to use crowd-sourced funding like the
>>> Kickstarter model, the OWASP Project Partnership model that Jeff and
>>> John designed last year, or simply grassroots means of reaching out to
>>> the community  to say here is what we need, let's make this happen!
>>>
>>> Conclusion, simply paying the project leaders and/or members to do work
>>> is a dangerous non-solution that simply addresses the results of the
>>> problem instead of the problem itself - much like putting a band-aid on
>>> a bullet wound - it may slow down the bleeding, but eventually your
>>> still going to die of lead poisoning or internal bleeding.
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2.0.14 (MingW32)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iQEcBAEBAgAGBQJPgzufAAoJEEOkVJOBy86BfPIH/jfsDAsU9eYGWR1B6LT0M4Bc
>>> JjxLicNJqbFJ3jTY4bTuXHznUR2484OLq9m3p498eTIo6h7H7+pQG5sEQHm77/uB
>>> zNh1eJnD1tHnhXgUAIGSGB51RJKDWd2ZjCtTSYnUF1Tq9whYhglL7TQJAM8doqsP
>>> qh7fv9n6/DEEle73nOyi6flw61lYYyA7/TWMIMHONRtmqQHX0caeleh1PDAKq/B4
>>> A9l1dLQbIXeRR3G0mkm9yPh2d9mO3cK6DYq+lcMrzLL6/6t8KTZ0vgPhLqV75wuR
>>> zl/UDzAMNNnL8DItCN7pstkwH+AnCED3FV/RLQpMqyB3BZrGdHC1r+ME/dqF2S0=
>>> =j4Iz
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>
>>
>>
>> --
>> John Wilander, https://twitter.com/johnwilander
>> Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
>> Conf Comm, http://www.owasp.org/index.php/Global_Conferences_Committee
>> My music http://www.johnwilander.com & my résumé http://johnwilander.se
>>
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>
>
> --
> Eoin Keary
> OWASP Global Board Member (Vice Chair)
>
> https://twitter.com/EoinKeary
>
>
>


-- 
John Wilander, https://twitter.com/johnwilander
Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
Conf Comm, http://www.owasp.org/index.php/Global_Conferences_Committee
My music http://www.johnwilander.com & my résumé http://johnwilander.se
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20120410/2d5aad65/attachment-0001.html>


More information about the OWASP-Leaders mailing list