[Owasp-board] Proposal for Comment - Project Branding

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


Jim,

There are always ways forward. We could grandfather old projects and 
require it of all new projects - or we can figure out how long old 
project have to become 'compliant' before forbid the continue use of the 
'OWASP' brand by their project. I think you are on a great track, but 
yes agreed: tricky, slowly; and definitely need to understand the 
stakeholders positions.



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

> I agree with me as well, but Jason makes a really good point. There 
> are many projects with logos on them today. Many. We cannot just "flip 
> a switch" and ask all of these people to change. And I agree that we 
> need to talk to effected folks first, to gauge impact.
>
> This is really tricky, and I for one do not want to repeat the fiasco 
> of the last big project policy change.
>
> - Jim
>
>
>
>> 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
>>>>> 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
>>
>>
>> Dennis


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