[Owasp-leaders] On Project Reboots

John Wilander john.wilander at owasp.org
Tue Apr 10 09:33:12 UTC 2012

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" (
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

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
   - 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>

> 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.
> Version: GnuPG v2.0.14 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> JjxLicNJqbFJ3jTY4bTuXHznUR2484OLq9m3p498eTIo6h7H7+pQG5sEQHm77/uB
> zNh1eJnD1tHnhXgUAIGSGB51RJKDWd2ZjCtTSYnUF1Tq9whYhglL7TQJAM8doqsP
> qh7fv9n6/DEEle73nOyi6flw61lYYyA7/TWMIMHONRtmqQHX0caeleh1PDAKq/B4
> A9l1dLQbIXeRR3G0mkm9yPh2d9mO3cK6DYq+lcMrzLL6/6t8KTZ0vgPhLqV75wuR
> zl/UDzAMNNnL8DItCN7pstkwH+AnCED3FV/RLQpMqyB3BZrGdHC1r+ME/dqF2S0=
> =j4Iz
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20120410/bc825bfc/attachment.html>

More information about the OWASP-Leaders mailing list