[Owasp-board] Proposal for Comment - Project Branding

Dennis Groves dennis.groves at owasp.org
Mon Jul 22 23:27:07 UTC 2013


Dear Sirs,

Pay special attention to this: 
https://www.apache.org/foundation/sponsorship.html
Apache *SELLS* sponsorship logo locations in exchange for supporting 
Apache. Are you suggesting the same? There is certain brilliance to 
this. Big carrot, little stick indeed!

Additionally, OWASP needs sponsors, and I am personally of the position 
that we need to define the 'sponsor relationship' better; because the 
reality is that no-one is an island. We all need each other (The 
principle of OPEN). Sponsors need OWASP, and OWASP needs sponsors. And 
the fact is, those sponsors are going to be commercial entities. And the 
other fact is, OWASP is not 'capturing that value.'

Dennis

On 22 Jul 2013, at 15:53, Jim Manico wrote:

> 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
>>
>>
>
>
>
> _______________________________________________
> Owasp-board mailing list
> Owasp-board at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-board


Dennis
-- 
[Dennis Groves](http://about.me/dennis.groves), MSc
[Email me](mailto:dennis.groves at owasp.org) or [schedule a 
meeting](http://goo.gl/8sPIy).

     Unless someone like you...cares a whole awful lot...
     nothing is going to get better...It's not."
                                             -- The Lorax


More information about the Owasp-board mailing list