[Owasp-leaders] On Project Reboots

Chris Schmidt chris.schmidt at owasp.org
Mon Apr 9 19:42:23 UTC 2012


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



More information about the OWASP-Leaders mailing list