Governance/ProjectProgramModels

From OWASP
Jump to: navigation, search

Purpose

OWASP needs help from our community to define an OWASP Projects Program model that will meet the needs of our leaders. To do so we are engaging the community to discuss and flush out different options. We would like to have a vote on this to ensure that the community has a say in how the foundation moves forward.

The Options

Please feel free to add additional bullets to any of the cells. Please do not remove existing items.

Option 1 - Flagships get majority of resources to increase quality. 2 - Develop two separate programs: Quality focused and Innovation focused 3 - Community project review centric model
Summary Description

Drop the Lab designation, and only have Incubator and Flagship projects. Flagship project status would be determined by community vote, and our resources would go towards developing Flagship projects, based on community input. Incubators would get less attention and support.

  • Keeps both Flagships and Incubators under the same program (as official "OWASP Projects").
  • Would remove resources from Incubators and funnel the majority of resources into the Flagship Projects.

Separate focus of OWASP projects into two separate programs. One will focus on increasing the quality of a handful of projects selected by the community, and the other program will focus on developing a platform for new leaders that facilitates innovation, research, and testing.

  • Takes two community requests (increase quality, platform for innovation), and separate each request into to programs.
  • Allows the foundation to have clearly defined goals for each program.

This is the approach we are currently using. This approach requires that the community conduct project reviews to graduate projects, and it requires a twice yearly project audit to demote projects that are currently inactive.

  • Current approach
  • Requires a large task force of community reviewers to make sure our project graduation process is functioning efficiently.
How are Flagships Selected? Community Vote Community Vote Community Project Health and Quality Reviews
New Project Designations
  • Official OWASP Project: Projects that OWASP actively maintains and promotes. In reality, these are what flagship projects should be under the current system. The majority of our resources and time should be used to improve the quality and sustain these projects.
  • OWASP Supported Projects: These would be similar to what the incubators are under our current system. Encourages innovation and it allows starting members to become engaged and involved. These can be managed in the same way we manage incubators now.
  • OWASP Sunset Projects: Projects like ESAPI or WebScarab would fit under this title. These are projects that are still being used by consumers, but that we will not directly support as they are not actively maintained or being worked on.
  • OWASP Flagship Project: Projects that OWASP actively maintains and promotes. The majority of our resources and time would be used to improve the quality and sustain these projects.
  • OWASP Incubator Projects: These would be all of the rest of our projects. These can be managed in the same way we manage incubators and lab projects now.
  • OWASP Sunset Projects: This is the same as Proposal 1. Projects like ESAPI or WebScarab would fit under this title. These are projects that are still being used by consumers, but that we will not directly support as they are not actively maintained or being worked on.
  • OWASP Flagship Project: Projects that OWASP actively maintains (but does not manage) and promotes.
  • OWASP Lab Projects: Projects with beta or stable release that wish to graduate to Lab.
  • OWASP Incubator Projects: All new projects, managed the same way we manage incubators projects now.
  • OWASP Sunset Projects: Projects like ESAPI or WebScarab would fit under this title. These are projects that are still being used by consumers, but that we will not directly support as they are not actively maintained or being worked on.
Project Quality

Consolidate Foundation resources to help improve quality of Flagship projects only. This will give the majority of our resources to a handful of projects.

  • Flagship Project Program: As mentioned above, these projects would be the ones OWASP actively maintains and seeks to increase the quality of. We can re-name this program (if necessary). Recommended that we limit the number of projects in this program for any given year (i.e. no more than 6 projects). Additionally, Flagship projects would be voted on by the community (which projects should be flagship).
  • Primary Goal of the Program: To increase the quality of a select few number of OWASP projects selected by our community stakeholders and consumers.
  • OWASP Projects Program: This would be similar to what we have now which is a platform for research and innovation. All projects under this platform would have the same designation unless they are sunset or inactive projects. They would get the same benefits they do now and the same opportunities.
  • Primary Goal of the Program: To maintain a research and innovation platform for our community to test ideas and theories.

The foundation has no direct influence over the quality of the project. The quality of the project is dependent on the project leader’s individual time, resources, and output.

Project Reviews

The Foundation facilitates a technical review of the community selected "Official" projects once a year, and the Incubator projects only get reviewed if they ask for one. The reviews are conducted by the community for supported projects.

  • For the OWASP Projects Program, we would only conduct reviews for those projects that ask for them. The reviews will be primarily to give feedback to the leader about their research/ideas and on their project health.
  • For the Flagship Program, reviews would be mandatory, and I recommend the new technical person conduct them. I further recommend they be done every quarter for each project. It is far more manageable since we would only have 6 or so projects in this program.

Project reviews are only done for those projects that want reviews, or that would like to graduate to the next level.

Resources and Funding

The majority of our resources and funding will go towards the development of higher quality Official OWASP projects. Supported projects will still have access to resources, but they will be minimal.

Each program would need to have their own budget. The Flagship program would only spend their funds on items that increase project quality. It would be required that flagship submit a detailed project plan and budget. The Projects Program would have a budget that would fund items like project dev work, the project summit, OSS, marketing/design costs, etc.

All projects get access to funding; however, Flagships get priority for funding for project development work. Funding items like project dev work, the project summit, OSS, marketing/design costs, etc are still available to all projects.

Positives of this approach
  1. Simplifies the process from an operational perspective as we would be primarily focusing on increasing the quality of a very small community selected group of projects.
  2. Increases community involvement.
  3. Incentivizes Leaders to make their projects user friendly, high quality, and highly volunteer engaged.
  1. Separates two different focus areas into two separate programs.
  2. Increases community involvement.
  3. Incentivizes Leaders to make their projects user friendly, high quality, and highly volunteer engaged.
  1. No adaptation needed in the operational and financial plan for 2014
Negatives of this approach
  1. Community vote might turn into a popularity contest.
  2. OWASP Official projects will take the majority of resources from all other projects.
  3. We will still have two separate focus areas under one program.
  4. Project development work will still be dependent on volunteer resources.
  1. Will require an additional foundation hire to manage Flagship Project Program.
  2. Project development work will still be dependent on volunteer resources.
  1. The model requires too many resources to manage efficiently.
  2. Foundation has no direct influence over project quality. Foundation can only suggest improvements.
Any other considerations
  1. Kevin Wall: Regarding "How are flagships selected?", I would view a community vote as a last resort. Rather I think a better option is to propose some objective criteria by which all projects (or at least projects of a specific type, such as software projects) can be measured. A "community vote" could them be used to vote of the proposed criteria. I think that such an approach is more work initially, but in the long run, I think it is less likely to turn into a popularity vote with the most visible projects becoming flagship projects.
  2. Kevin Wall: Under "New Project Designations", the first bullet states "Projects that OWASP actively maintains and promotes"...what specifically do you have in mind? This seems rather nebulous, kind of like "I'll know it when I see it" thing, but not everyone may have the same conceptual model in mind. If we are going to give funds to flagship projects, then I want to know details of how this will be done.
  3. Kevin Wall: Under "Project Quality", a similar statement. How exactly will the OWASP Foundation resources help to improve the quality. My personal belief is that whatever we've been doing has failed miserably. The key to sustaining a successful project is to have a sufficiently sized core of engaged OWASP volunteers working on this. I personally don't think that paying people to write code is going to help much. Case in point...I don't think that OWASP could afford the normal rates that any of the ESAPI contributors would normally get. So people have to contribute because they want to, because they're motivated. So how is the OWASP Foundation going to do that?
  4. Kevin Wall: Under reason #2 for "Positives of this approach"...my comment is REALLY??? How? Specifically, how is this different than Option #2?
  5. Kevin Wall: Under "Negatives of this approach", regarding statement #1. I don't think there is any 'might' about it.
  1. Kevin Wall: Same comment as comment #1 for Option 1.
  2. Kevin Wall: Also under "Summary Description", the lead in paragraphs...how is this DIFFERENT than Option #1?
  3. Kevin Wall: Regarding the 2nd bullet item under "Summary Description" for this option...this bullet is a MIST, but I don't see why it is exclusive to Option #2.
  4. Kevin Wall: Regarding "Resources and Funding", I think this is an excellent idea, but at a bare minimum, some board-given guidelines would be required. I don't think I'd want the project themselves having complete autonomy here. Also, for this to work I think each project would have to have some dedicated PM resources as developer generally are neither very good, nor found of doing things like the issues described here. (But perhaps this was already anticipated and what was in mind in #1 under "Negatives of this approach"???)
  1. Kevin Wall: Lead-in sentence under "Summary Description" for Option #3...if this is the approach that we are "currently using" than why have we not been doing regular (twice yearly!) community project reviews? I had not even heard about them until 3Q2013. And if we have been doing them, why have they been such a failure?
  2. Kevin Wall: Under the 2nd bullet for "New Project Designations"... did you mean to say "graduate to Flagship" rather than "graduate to Lab" since the context here was Lab projects?
  3. Kevin Wall: A comment on the 2nd sentence under "Project Quality" for this option: In reality, I believe that this will also be true for Options #1 and #2 for both Flagship and Lab projects. See my earlier comments regarding paid versus volunteer help under Option #1.
  4. Kevin Wall: Under "Project Reviews"... this statement is in contradiction to what was stated in the lead-in sentences under "Summary Description" for Option #3 where it discusses two mandatory reviews per year. So apparently I am confused or one or both of these statements need clarification.

Additional Comments

Use this space to provide additional comments on any of the existing text. For example, perhaps you disagree with something that is above. Please note your thoughts in this section.

  1. James McGovern - I can't quite tell if this model will provide service equally to builders vs breakers vs defenders. Has OWASP looked at models that are role-aligned? For example stuff that CISOs care about vs developers vs project managers, etc
  2. Kevin Wall - James is absolutely right. I had only considered software vs. documentation projects, but that's another legitimate way to cut the pie.
  3. Kevin Wall - I have further comments under the Discussion page.