Develop clear guidelines for projects that are being used by commercial entities

[DonnieBLT]

What kinds of separation should the project have other than not linking to it outside of a supporters page? What if the commercial project does not support the open source version? Is a subscription plan a concern? What if the subscription plan was solely non profit?

[DonnieBLT]

Guidelines for Open-Source Projects and Commercial Entities:

1. Project Ownership: Maintain open-source community ownership; document commercial contributions.
2. Separate branding: Distinguish commercial product branding from open-source project.
3. Clear contribution policy: Transparent policy regarding commercial entity contributions.
4. No preferential treatment: No prioritizing development based on commercial interests.
5. Supporter's page: List all supporting entities equally on a designated page.
6. Open-source commitment: Encourage commercial entities to contribute back to the project.
7. Non-profit subscription plans: Consider transparent plans without conflicts of interest.

[bkimminich]

What kinds of separation should the project have other than not linking to it outside of a supporters page? What if the commercial project does not support the open source version? Is a subscription plan a concern? What if the subscription plan was solely non profit?

Commercial entanglement is a complex topic, and there's different opinions floating around in OWASP about it. I'll try to give my personal take on the matter:

1. OWASP projects can and should point to financial supporters and commercial contributors of "things" with a monetary value (i.e. working hours) from the Supporters tab as per project website template and OWASP policy. If a project has its own website, it should do the equivalent thing there.
2. OWASP projects should under no circumstances offer premium services on top themselves. If a third party does so, that's their thing. Vendors doing that can of course point to the OWASP project, advertise their involvement and support etc. on their own website as they like. That OWASP is vendor neutral doesn't mean vendors need to be "OWASP-neutral".
3. If more than one commercial addon service for a project exists, it's okay to let the OWASP project list them somewhere on the project page for all I care. Should be made clear that this doesn't equal endorsement and all (known) vendors should be listed, to keep neutrality.
4. The neutrality good practices from https://owasp.org/www-committee-project/#div-practice should be followed obviously

This all works fine imho if the OWASP project existed already, so any vendor has a chance to do something with or on top of it.

What doesn't work fine is this situation: A vendor has a product and open-sources it or parts of it into OWASP. Now we have an entanglement problem, because neutrality is not possible if the vendor has commercial add-on services on top or creates them shortly after. Here OWASP needs to be very careful to not be abused as a marketing vehicles. Imho: If a vendor wants to go this path, they should open-source their project under their own name on GitHub. No need to bring OWASP in. If that open source project becomes a security tool staple on its own and the OSS version is not just bait for selling premium services or enterprise versions, applying to become an OWASP project is still possible, it can just be approved/denied on a better information basis.

[northdpole]

This is a bit of a chicken and egg problem.

If a vendor or a project lead decides to offer commercial services on top of an OSS project we should encourage them to announce that their solution is "based on" or "influenced by" or "uses" OWASP project X. Similarly the project could announce somewhere in their marketing pages that "Vendor X" is a known user.

Imho, similarly, if a vendor decides to donate a project to OWASP we should treat this the same as if the project pre-existed the vendor and the vendor just provides services on top of it. Obviously more than usual scrutiny should be applied.
What would not be ok in this scenario would be if the vendor retained complete control of the entirety of the project, did not allow nor encourage (in theory or practice) external meaningful contributions, abandoned the project(less than X meaningful commits per quarter) and/or took steps to prevent others from using the project.

A simple threshold we can set here is that vendor contributed projects must:

• remain at least "Production" at all times(or maybe a "donated" category),
• clearly further the OWASP agenda in a significant way (please not another, increasingly specific top 10 or guidelines for something that is partly covered by an existing project)
• maybe set a "preference" of them having at least one contributor or few commits per year from someone not on the vendor's payroll <-- hard to prove and i guess based on good will, the true check could be "check that the majority of meaningful PRs from new contributors are not automatically rejected".

[bkimminich]

What would not be ok in this scenario would be if the vendor retained complete control of the entirety of the project, did not allow nor encourage (in theory or practice) external meaningful contributions, abandoned the project(less than X meaningful commits per quarter) and/or took steps to prevent others from using the project.

💯🙂👍

[DonnieBLT]

I would be interested in listing a few OWASP projects that have a commercial side to them as examples of good practices.

[stevespringett]

https://www.cryptosoft.com/ is an example of a commercial offering based on OWASP Dependency-Track that has no direct affiliation with the OWASP project itself.

Defect Dojo is an example of a for-profit company that provides support and hosting for OWASP Defect Dojo (the project)
https://www.defectdojo.org/
https://www.defectdojo.com/

[bkimminich]

DefectDojo is in my opinion not a good example, as from now on the OWASP project and the commercial entity are indistinguishable for Joe Average as they have the exact same name. It is definitely an example, though... 🙂

[stevespringett]

I think we need very crisp definitions on what we think "good" examples are. For example, https://owasp.org/www-project-defectdojo/ and https://www.defectdojo.org/ do not have any links to https://defectdojo.com/ (good), but the distinction between .org and .com is not obvious and could be improved.