[Owasp-board] Proposal for Comment - Project Branding

Jim Manico jim.manico at owasp.org
Tue Jul 23 00:07:51 UTC 2013

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
(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

More information about the Owasp-board mailing list