[Owasp-board] Proposal for Comment - Project Branding

Dennis Groves dennis.groves at owasp.org
Tue Jul 23 00:29:34 UTC 2013

Brilliant, Love it, and Totally agree! :-)

On 22 Jul 2013, at 17:07, Jim Manico wrote:

> Yes, I suggested this exact model to the board. Please note, the
> Apache sponsorship page is the ONLY page at Apache that allows logos.
> I think it's a wise policy.
> --
> Jim Manico
> @Manicode
> (808) 652-3805
> On Jul 22, 2013, at 6:27 PM, Dennis Groves <dennis.groves at owasp.org> 
> wrote:
>> 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 
>>> 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

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

     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