[Owasp-board] Fwd: Re: Proposal for Comment - Project Branding

Jim Manico jim.manico at owasp.org
Mon Jul 22 22:53:43 UTC 2013


Here are some comments from Jason Li around project branding. I agree (and think we should take counsel from) 99% of this message. 

My only comment for Jason is around the "neutrality" portion of how I think we should list project contributors. I think his concern is fair, and I think we can address this.

For example, check out the contributor page of Hadoop, a project that has more users and a larger community than all of OWASP.

http://hadoop.apache.org/who.html

Some great vendor-neutrality aspects to this page:

1) No logos
2) Neutral listing of contributors
3) Still contains contributor name, role in project, and company they work for (so company sponsorship of contributors is acknowledged) 
4) Different groups of contributors based on seniority

So with these kinds of branding choices in mind, I think we can enhance vendor neutrality at OWASP in a way that does not diminish deep contributors - if the board and organization has a will for it.

But most importantly, I do agree with Jason that we should have a talk with those most effected before making any major change.

Aloha,
Jim


-------- Original Message --------
Subject: Re: [Owasp-board] Proposal for Comment - Project Branding
Date: Wed, 17 Jul 2013 01:41:07 -0400
From: Jason Li <jason.li at owasp.org>
To: Jim Manico <jim.manico at owasp.org>
CC: Michael Coates <michael.coates at owasp.org>, Sarah Baso <sarah.baso at owasp.org>

Jim - my feedback is below - thanks!

-Jason

Board,

I appreciate the desire to maintain vendor neutrality for projects but I
want to caution you about the direction that this initiative is taking.

I'd like to share the GPC's past experiences with managing projects and
trying to effect changes of similar scale. One of the original goals of the
GPC was to ensure that OWASP consumers could get information about a
project in a consistent way. That culminated in the now-familiar Project
Details tab that's present on practically all OWASP projects now. But that
path is littered with corpses along the way - and I foresee a similarly
painful path for corporate logos given the way the policy is developing.

Here's what I suggest as a considerations for success:

1) Forge a policy - not implementation - consensus with the projects that
are considered the main offenders

This policy seems to be written with a specific implementation in mind and
assumes that listing contributors on a project sponsors tab is THE way to
go. The projects that the Board considers to be the main offenders of
corporate logo usage are going to be the ones that have the most pain and
the most effort required. So it's important to work with them before
setting policies that specify implementation like this one. Just like with
good software development, good policy should be about requirements, not
implementation.

We made a similar mistake when we tried to standardize project details. At
the time, we thought a separate heading on the page was THE way to go and
dictated that to projects. But the most visible main OWASP projects were
resistant to the change. We eventually reached out to a few high profile
projects to explain our motivations and understand their resistance to the
project details proposal. The objections were mainly about control of the
main project page content/appearance. Out of that collaboration, one of the
projects suggested using Wiki tabs (new at the time) and thus was born the
Project Details tab. With the separate tab, projects still controlled the
appearance of the main content but there was still a consistent place for
project information. It may seem an obvious solution looking back - but
that's just because it's ubiquitous now which speaks to the success of the
initiative.

For corporate logos, we should first understand what companies see as the
benefit of sponsoring a project and of having their logo on the project
page. Reach out to them in a collaborative manner and discuss OWASP's
concerns about vendor neutrality. Perhaps they have an idea that we haven't
even considered yet that recognizes sponsors in a way they want to be
recognized but doesn't compromise our neutrality and turn OWASP into NASCAR.

2) Based on the policy, provide a template/model for what a project page
*should* look like and where contributors and/or sponsors should appear

OWASP - and the Board in particular - has a history of "bring me a rock"
management. Originally with project details, we asked projects to put a set
of information on the project page. However, there was no concept at the
time of a consistent format. As a result, we went back and forth with
projects and some project leaders got sick of it. Mike Boberski for example
was a co-author and project lead of the ASVS but became frustrated with
OWASP and left the project. To my knowledge, there has been no update to
ASVS since then despite the Board naming a new leader several years ago. I
can see corporate logos following the same pattern where sponsors will try
and clean things up, get bashed over the head, go back and try again, get
bashed over the head, etc. unless there's a template.

Note that based on the current suggested policy, the guy that takes a quick
second to correct a small typo in the final draft is recognized as equally
as the company that spends 520 man hours supporting the project - all in
the favor of listing contributors "neutrally". If I were a vendor that had
supported OWASP for a long time, that would seem disrespectful on OWASP's
part. That's surely not the intent - and a template showing how
contributors should be listed will go a long way in forestalling that
perception.

3) Flesh out the policy with actual implementation

It always sounds easy and straight forward to dictate policy - but the
devil is in the details. I guarantee that as projects change content, cases
will come up where following the policy as stated to the letter will end in
an absurd result. Find an offending project that's willing to be the guinea
and work with them to flesh the implementation out through to
completion. These things need to be fleshed out in a well thought out way -
and it's hard to do that if you're trying to impose a policy on a project
that they're reluctant to adopt in the first place. Don't start by spouting
policy and rattling sabers with an offending project that's not receptive
to the change.

We did this with a few projects when we started down the road with
SourceForge and we eventually realized what we were trying to do with SF
wasn't going to work. Imagine if we had just opened it up right away and
forced everyone to go through a loose policy that hadn't really been fully
fleshed out? Make sure there's an implementation path that works for both
OWASP as an organization and the projects themselves.

4) Policy compliance

Michael already addressed the six-month audit. I would like to further
remind the Board that any kind of regular manual auditing of any policy
(not just this one) on projects is infeasible... we couldn't even manage to
reliably do project reviews based on the Assessment Criteria when project
leaders explicitly requested them... As the Board continues to consider
policy changes in general, please keep in mind that anything related to
projects (and likely chapters) needs to be scalable and self-correcting.

With specific regards to the corporate logos, what do you actually expect
to happen with projects that don't comply? What's the incentive and
consequences? And again, the projects that are most offending are going to
be the keys here. They have the most work to do so we want to provide the
right incentive. Otherwise, why wouldn't they just leave things as they
are? What's the consequence?

We made that mistake with project details at first. As I mentioned, the
mainstream projects were hard to push. And since those main offenders
lagged behind, other lesser projects scoffed at the idea of including
project details. After all, WebGoat and WebScarab weren't doing it - why
should they?

Ultimately - It's important to have a big stick - but it's probably more
important to have a bigger carrot. I think we've lost several projects over
the years whenever we tried to push project policy changes on them. Most of
our projects are one person deep - if that person leaves the project, it
will die. We have not have much success historically with picking up or
adopting projects once they have been abandoned. And this is a huge policy
change so we should really tread carefully and try to avoid repeating past
mistakes.

---

On Tue, Jul 16, 2013 at 9:36 AM, Jason Li <jason.li at owasp.org> wrote:

> Will do - thanks Jim.
>
> -Jason
>
>
> On Friday, July 12, 2013, Jim Manico wrote:
>
>> Jason,
>>
>> Send me your comments, I'll add them to the doc. I'd like your comments
>> to me considered here.
>>
>> Cheers,
>> Jim
>>
>>
>> > Sounds like a reasonable process _in principle_.
>> >
>> > My only caution is that if the intent is for the Board to coalesce
>> around a
>> > particular alignment, by the time public comment period has come
>> around, it
>> > might seem that Board members opinion will have already been formed. In
>> > that event, public opinion is somewhat moot.
>> >
>> > For green-field initiatives, I don't think it's a problem to have a
>> > strawman drawn up and internal Board consensus beforehand. But for
>> sweeping
>> > policy decisions that have a great deal of trickle down effect (the
>> > proposed initiative affects a number of projects - several of them high
>> > profile, well known projects) - already having an internal Board
>> consensus
>> > before seeking public comment I think promotes the idea that the Board
>> is
>> > not receptive to community concerns.
>> >
>> > Here's the analogy I see... when Congress puts forth legislation, they
>> have
>> > subcommittees that do the initial leg work and broker consensus. Then
>> > there's general floor discussion and then the body makes a decision.
>> When
>> > the Supreme Court issues a ruling, they solicit briefings of the various
>> > view points (including outside opinions - or amicus curiae briefs) and
>> then
>> > make a decision.
>> >
>> > So when looking at Board action, the lens I would think about is: is the
>> > Board trying to "do" something (hold a conference, generate project
>> > revenue, create a new paid position, etc) or is the Board trying to
>> "judge"
>> > something (establish a policy, change membership requirements, set
>> standard
>> > for conduct, etc).
>> >
>> > In the case where the Board is "doing" something, I think it makes
>> sense to
>> > act like Congress (create strawman, generate consensus, solicit
>> feedback).
>> > In the case where the Board is "judging" something, I think it makes
>> sense
>> > to act like the Supreme Court (solicit feedback, generate consensus,
>> create
>> > decision).
>> >
>> > Just some food for thought.
>> >
>> > Looking forward to the public comment period.
>> >
>> > -Jason
>> >
>> > P.S. I'm well aware that our federal government has its own pitfalls ;-)
>> >
>> > On Wednesday, July 10, 2013, Michael Coates wrote:
>> >
>> >> Yep. Its not yet open for comment yet on purpose.  We want the board to
>> >> take a first pass and come to some alignment and then present that
>> item for
>> >> public comment. That step should be in a couple weeks.
>> >>
>> >> The goal is to avoid proposing something for comment that doesn't even
>> >> have any level of agreement at the board as a potential path forward.
>> >>
>> >> Now the public comment could result in major changes, but that's ok
>> too.
>> >>
>> >> Laslty the board will vote on the updated doc that has all comments
>> >> considered.
>> >>
>> >> When we go for public discusion it will be in the governance list.
>> >>
>> >> Sound reasonable?
>> >> On Jul 10, 2013 11:22 AM, "Jason Li" <jason.li at owasp.org> wrote:
>> >>
>> >>> Michael,
>> >>>
>> >>> I'd like to provide some comments and feedback on this proposal based
>> on
>> >>> experiences with the GPC.
>> >>>
>> >>> It doesn't appear that the document is open to comment by non-board
>> >>> members?
>> >>>
>> >>> What's the best way to provide input?
>> >>>
>> >>> -Jason
>> >>>
>> >>>
>> >>> On Tue, Jul 9, 2013 at 1:09 AM, Michael Coates <
>> michael.coates at owasp.org>wrote:
>> >>>
>> >>>> Board,
>> >>>>
>> >>>> We're starting the 2 week period for board comment on the following
>> >>>> proposal:
>> >>>>
>> >>>> Projects/Project Brand Guidelines
>> >>>>
>> >>>>
>> https://docs.google.com/a/owasp.org/document/d/17h6BrV6an_UtcF6VHZsWNKqfW1JGE5pu_yVIWC2ilI8/edit
>> >>>>
>> >>>> Please provide any comments within the google doc. Feel free to
>> either
>> >>>> add a section at the bottom with your name and comments or use the
>> inline
>> >>>> comment feature. Comments that are sent in email won't be captured
>> when the
>> >>>> doc is se
>
>





More information about the Owasp-board mailing list