[Owasp-board] Proposal for Comment - Project Branding

Jim Manico jim.manico at owasp.org
Tue Jul 23 00:33:04 UTC 2013

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

More information about the Owasp-board mailing list