Thursday 8 November 2012

The difference between being 'Appointed' and being 'Accepted' as an OWASP Leader (of its Fork)

OWASP is a community that really embraces new ideas, new contributors and projects.

For somebody motivated (and with time/energy) there are very few ‘real’ barriers on entry. Even the cases where it ‘feels’ like there are barriers of entry or ‘bureaucracy’, those are mainly artificial and easy bypassed (with the right level of energy and commitment)

The problem is Empowerment

What I found (by observing lots of OWASP projects starting, blossoming and dying) is that what makes the difference is how Empowered is an individual on a particular project/tasks.

The easiest scenario is when a new project is born, since by default the person motivated to launch it, will feel empowered to do work on that project.

But when we get into contributing/collaborating with other projects, or in dealing with community matters (like what the OWASP Committees try to address), it gets more complicated, since there is an invisible barrier that most don’t want to cross.

Although the default answer at OWASP to people with ideas is “why don’t you go and do it yourself”, what actually tends to happen is: Nothing (or very little)

And yes, OWASP does have a problem with the ‘...yes I can help...’ brigade, which are the ones that are first to offer to help, but seldom do any actual work (in most cases these ‘non-helpers’ are neutral, since they don’t have an significant impact (positive or negative)).

For me, the the real problem is one where the candidate (current or future OWASP leader) ‘feels’ that he/she needs to be ‘Appointed'

I think it is human nature that creates the ‘need’ to feel that one is allowed to touch/change a particular project. And since there isn’t a direct effort to tackle that ‘need’, we go back to the default outcome which is: Nothing (or very little).

And what a great tragedy it is, when you have somebody who wants to work, wants to learn, wants to contribute, wants to change, but somehow the initial spark fails to happen, and that energy/focus is lost.

There were four cases where I really saw this in action.

  1. the OWASP Seasons of Code
  2. the OWASP Summits
  3. the OWASP Committees (created in the first Summit)
  4. creating a web page in the OWASP wiki

In all these cases, all that it took for a huge amount of energy (and work) to happen on particular project (or area) was for somebody to have his/her idea ‘accepted’ in the public sphere

  • the Season of Code participants (which would had made more money flipping burgers) felt empowered to participate and contribute to a particular project or idea
  • the OWASP summits, that where designed around the idea of 'working sessions', which made the participants fell empowered on these 'working sessions' topics
  • the committees which (initially) empowered existing OWASP leaders to tackle a huge amount of OWASP related issues (Projects, Conferences, Chapters, Membership) and outreach efforts (Industry, Education, Connections)
  • the magic sparkle and empowerment that happens when an owasp leaders/contributor sees a webpage in owasp.org with his name
The problem with these activities is that they are very 'top down' and rely on an 'higher authority' to do the 'Appointments'.

Which means that when that when the 'Appointments' stop, (in 95%+ of cases) the Empowerment and energy stops.

In fact, what happens after a while, is that we have a perverse model where the people appointed have run out of energy,ideas or time, but still have the role, which now prevents new blood from taking over. The current state of the Committees are a great case study of this. Most are just about dead (and the ones that are not, are being driven by external events: Conferences, an election a new project manager, etc...), but since there a 'felling' that 'somebody in charge' there isn't the urgency (and awareness) that really important areas for OWASP (and AppSec) are currently (for all practical purposes) stopped and leaderless

The problem is that OWASP at the moment doesn't do a 'Spring Clean' of leaderships and 'Appointments', which means that although it is easy to get in, it is very hard to get out (and it takes a lot to step down from a Leadership position). Humm ...  maybe at the next OWASP Band we should play the Hotel OWASP to the tune of Hotel California :)

In my view, the solution is to:
  • re-invent the OWASP committees as OWASP Initiatives (which are focused on empowering specific tasks)
  • remove all project leaders that have been on a project, initiative, committee but have done nothing (measurable) in the last 6 months (a good test is just to ask: 'Dear project leader XYX, what have you done for the project/initiative/committee ABC over the last 6 months.').
The removal of the OWASP leaderships is very important, since the dark side of Appointing leaders, is that while they are there, it is quite toxic (and political) for somebody else to 'step-up' and start doing something about that project (i.e. most don't want to buy that fight, or have the time to deal with the political implications/BS).

And this takes me to the real idea behind this post: 

The difference between being 'Appointed' and being 'Accepted' as an OWASP Leader (of its Fork)

What we want is a situation where members of the OWASP community fell empowered to Fork (i.e take ownership) a particular project or idea.

Then, the real 'Appointment' happens by the community that recognises his/hers ideas, and accepts the vision followed/executed (with eventually that person becoming the 'project leader').

This is much more healthier and risk-free than the current 'Appointment' model since, if that person fails to deliver, the loss is minimal

Also important is the fact that this 'Forking' allows for multiple simultaneous attempts/efforts by different participants. Which maximizes the changes of success. 

Compare that with the current 'Appointment' model, which by design choses one path/person vs another one (unless all candidates are accepted), and removes energy/Empowerment from the 'losing' parties.

For more thinking on the 'Fork projects or content' idea see the Design for Fork and the liquididy of OpenSource/Git post. 

Linus has shown us that Forking is the way to create a community around code. Now we need to use the same principles of Forking to create vibrant communities OWASP projects and activities