Background
As you may well be aware ZAP left OWASP to join the new Software Security Project on the basis that the Linux Foundation would be able to secure funding for core ZAP development. Unfortunately the proposed funding for ZAP has been withdrawn and as a result ZAP will no longer be joining the Linux Foundation. Note that the Software Security Project will still be going ahead, but again, not part of LF.
ZAP is a complex and ambitious project. Commercial companies that maintain projects equivalent to ZAP have hundreds of people working on them. It is not possible to maintain ZAP in one’s spare time, no matter how many people volunteer. I believe that 2 people working full time on ZAP is really the minimum we need in order to maintain ZAP, and that is not enough for ZAP to really thrive.
Over the last few years we have struggled to get enough funding for ZAP, and the main funding we have achieved has not proved reliable.
The Open Source Fellowship
The withdrawal of the Linux Foundation funding did put ZAP in a very precarious position.
However, I am delighted to be able to announce that ZAP is now sponsored by the Crash Override Open Source Fellowship! This means that both myself and Ricardo are able to spend 80% of our time working on ZAP for the next 2 years. Not only that, but the remaining 20% of our time will be spent on other open source developments, some of which will directly benefit ZAP!
The sponsorship does not change anything to do with the governance of the project - the ZAP Core Team remains completely in control of the project, our roadmap and all of the Intellectual Property.
This is an amazing investment in ZAP and one that saves the ZAP project from potential closure.
For more details see https://crashoverride.com
Helping ZAP Thrive
While the Crash Override Open Source Fellowship support means that ZAP can survive, we still need to find a long term independent and scalable funding model in order for ZAP to thrive.
ZAP has grown from a very small project to become what is probably the world’s most popular web security scanner.
Initially I hoped that if we made ZAP useful enough to enough people and companies then those who benefit from ZAP would donate enough money to the project to allow us to grow. Sadly that has not proved to be the case.
We need to be able to pay more people to work full time on ZAP if it is to continue to provide real value. In order to do that we need reliable sources of income, ideally recurring income rather than one-offs. As a result we have been investigating all of the potential options for us to raise more funding, as summarised below.
I would like to stress that the whole purpose here is to fund ZAP development as a non profit entity. We are not looking to get rich!
ZAP Funding Options
We have investigated a lot of options. The main ones are detailed here, including a summary of their pros and cons.
Donations
ZAP has traditionally raised money via donations, previously managed by OWASP. While these were of course very welcome, we have not been able to raise anywhere near enough money to sustain ZAP development.
Positives
- No additional cost to the ZAP project
Negatives
- Unlikely to raise much this way
- Typically non recurring
Conclusion: We will not be accepting donations directly at this stage.
Sponsorship
I have relied on sponsorship for funding my work on ZAP since 2012.
As explained above both myself and Ricardo are now sponsored by the Crash Override Open Source Fellowship. We have not been able to get anyone else sponsored on ZAP since the project started, so this is similar to (large) donations.
Grants
In theory grants could be a really good way of funding ZAP, but we have no experience applying for grants and we understand that they can be very difficult and time consuming to apply for.
Positives:
- Can potentially raise significant funds this way
Negatives:
- Hard to apply for, can take a very long time
- Would take time away from ZAP development
- We have no experience doing this
- Non recurring
Conclusion: We will not be pursuing grants at this stage.
Support Contracts
As some of you may be aware, I asked for feedback on this option recently via both X / twitter and LinkedIn.
You will see from the poll results that there do appear to be companies who would be interested in these options.
Positives:
- It looks like some companies may be interested in this option
- This option will allow companies who require such support to consider using ZAP
- Recurring revenue
Negatives:
- Will take time away from ZAP development
- It will potentially impact the free support we can provide
Conclusion: We will be introducing Support Contracts as part of Plan A.
Sponsored Developments
We have in the past accepted money in order to implement specific ZAP developments. This benefits both ZAP and the companies which can accelerate new features.
Positives:
- We get paid for developments that we already want to work on
- Companies get features they need faster
Negatives:
- Can be very sporadic
- Non recurring
Conclusion: We will continue to accept Sponsored Developments as part of Plan A.
Consultancy
Various companies have been in touch asking for ZAP consultancy. Up until now we have not been in a position to provide such consultancy except on a no cost basis.
Positives:
- We know there is a desire for some consultancy
Negatives:
- Will take time away from ZAP development
- Non recurring
Conclusion: We will be available for Consultancy as part of Plan A.
Licensing
We know that a significant number of companies use ZAP to provide online commercial services. This is permitted by the Apache v2 licence under which the majority of the ZAP code base has been released. While some of the smaller companies have been supporting ZAP, the majority of the larger companies have either never supported ZAP or have not done so recently.
We believe that these companies are potentially a good source of ZAP funding. They already use and benefit from ZAP and some of them will be making a significant amount of money from ZAP.
As most of the companies using ZAP in this way have never supported ZAP we believe that in order to get enough licensing revenue we would need to relicense the ZAP code.
This is something we are very seriously considering.
Positives:
- Potential for raising significant revenue
- Recurring revenue
Negatives:
- Potential for ZAP forks
- Could impact customers who use ZAP but do not sell services based on it
Conclusion: This is a definite possibility as part of Plan B.
Training
Positives:
- Can be outsourced
Negatives:
- Significant initial investment
- Unclear if there is significant demand
Conclusion: We will not be providing training at this stage.
SaaS
Positives:
- There is demand for such an option
- Recurring revenue
Negatives:
- Significant initial investment
- Significant ongoing investment
- Will potentially compete with companies we would like to buy ZAP licences
Conclusion: We will not be providing a SaaS at this stage.
Closed Source
One option for us is to close source ZAP, as happened to the original Paros Proxy. This is not an option we are considering. We believe that there is a real need for an open source project like ZAP.
Conclusion: If we cannot make this work then it will be time to try something else, potentially something completely different.
Open Core
Another option is to keep ZAP open source but to add additional closed source features, especially those that would appeal to companies using ZAP at scale.
Conclusion: This is not an option we are considering at this time.
Plan A - Support
We do not know which of the above options will work for ZAP, so we are going to try various options and see what does and doesn’t work.
The first thing we are going to try is offering professional services, including:
- Support Contracts
- Sponsored Developments
- Consultancy
While we do not expect a very fast take-up of these services we do want to see that there is enough initial take-up to give us confidence that this could provide the funding we need.
If we have not had enough interest in these services within 3 months then we will start planning for Plan B in addition to Plan A.
For more details see the Support page.
Plan B - Dual Licensing ZAP
The second option which we are very seriously considering, in addition to commercial support, is dual licensing ZAP.
The plan would be to dual licence ZAP, with the 2 options being a different OSS licence and a commercial one. The OSS licence we are currently considering is GNU AGPL as we believe this is the one most likely to encourage large companies to purchase a ZAP code licence.
We understand that there is a danger that companies may just not update to using the re-licensed version of ZAP or may choose to maintain their own fork. If we go down this route then we are likely to charge for the ZAP commercial licence on a sliding scale based on company size. The most expensive licence for very large companies is still likely to be significantly less than the cost to them of maintaining and enhancing ZAP themselves.
As noted above we will only be considering this option if there has been minimal take-up of the services in Plan A after 3 months. We would expect the planning and associated changes to take another 3 months, so the licensing changes are at least 6 months away.
If this option looks likely then we will publish another blog post which will go into this in more depth, but in the meantime this is something we would like your feedback on ASAP.
Would re-licencing the main ZAP codebase to be GNU AGPL + a commercial licence cause you problems?
You can get in touch with us via the ZAP User Group (thread to be started ASAP) or you can email the ZAP Core team directly.