VersionEye 2.0

Posted on Categories Continuous Updating

More than 3 years ago I discontinued VersionEye. A SaaS tool for Open Source License Compliance & Security. VersionEye 1.0 could monitor your package manager files on GitHub, notify you about outdated dependencies and show you which of your dependencies are affected by security vulnerabilities and copyleft licenses (AGPL, MPL-2.0 and so on).

I was operating it for almost 7 years and at the end I was pretty much burned out! The reason why I discontinued it are described in this blog post. Working on it was not a joy anymore. My mailbox was flooded with support emails and after 6 years pretty much everything else looked more interesting to me than OS license compliance and security. That’s why I joined LivePerson at the End of 2017. I got a new challenge, met a lot of smart people and helped to grew the LivePerson Mannheim Office from 15 to 60 people in less than 3 years.

In 2018 Alex Spinelli, former head of Alexa OS at Amazon, joined LivePerson as the new CTO. He made a lot of organisational changes and did teach us a lot about Amazon management principles. Things like writing PR/FAQs, single threaded ownership, 2 Pizza teams, mission statements, leadership principles and many more things. That was very valuable and I enjoyed learning a lot of new things.

Of course, License compliance was a topic at LivePerson as well. Software teams had to ensure that they are compliant with a company license whitelist. The tools which we had to use for that at LivePerson have been far away from user friendly and good. With a crying eye, I looked back at VersionEye. I had no interest in resurrecting VersionEye 1.0 because I still remembered all the pain points of that solution. But somehow the topic was keeping circling in my head. So I started to think about how VersionEye 2.0 should look like. Not just on a technical level, but also on a lifestyle level. How would a version 2.0 look like which I would enjoy working on and wouldn’t burn me out again? So I thought about all the points which stressed me out at version 1.0:

  • Customer Support: With VersionEye 1.0 I had a lot of non paying users. Less than 1% of all signed up users (52K) paid a monthly subscription. More than 99% of all signed up users did not pay a single dime but most of them caused server costs and some of them caused support.
  • Too much data: In 2017 VersionEye supported something like 20 package managers and crawled all repository servers for them to collect all kind of information about software libraries. VersionEye had meta information for more than 2 Million software libraries/components. Every component can have multiple versions. A specific version of a component is an “artefact”. VersionEye had meta information for more than 50 Million artefacts. That’s of course a nice vanity KPI. Kind of cool if you can tell investors that your database contains meta information for more than 2 Million software components and 50 Million artefacts! Right? But the truth is that 99% of these software components are never referenced in customer projects! 99% of them are garbage! Even my biggest customer at that time, a big software giant from Germany, did not use more than 6K unique open source components for their active Java/NodeJS software development.
    Keeping the database with 2 Million components up-to-date requires a lot of crawling activities and that causes again a lot of costs.
  • Not focused data: VersionEye 1.0 collected even information which was not relevant for open source compliance & security. For example, the crawlers collected information about the authors of the software components and about the relationships between the components. That’s all kind of nice to know but not really necessary for the core business. Customers of VersionEye have only 3 questions:
    • Are my dependencies compliant with a license whitelist?
    • Are my dependencies vulnerable?
    • Are my dependencies outdated?
  • Open sourcing: VersionEye 1.0 was fully open source. I open sourced it because I assumed it would offer more transparency and therefor bring more new customers. And I assumed I would get a lot of contributions from open source developers. Both assumptions have been wrong! I did not really get more paying customers after I open sourced everything. My existing paying customers did not really care because they did pay for the service, implementation of new features and SLAs.
    Open sourcing the whole thing actually caused even more support. Because all suddenly more people opened GitHub tickets. Just very few people actually implemented an improvement and send a pull request. Most people just opened a ticket and waited for an reaction. All together I had to spend more time on GitHub tickets. I needed to read them, think about it, respond to them, doing more code reviews and so on. All activities which are very time consuming.
  • GitHub Integration: One feature of VersionEye 1.0 was that it could monitor your package manager files directly in your GitHub repositories. For that, users had to grant VersionEye access to their GitHub accounts/organisations. VersionEye then received a token per user/orga, which could be used to fetch files from the corresponding GitHub repositories. That of course, caused a lot of background processing. But the real pain point was that these tokens expired at some point in time and then VersionEye had to reach out to the users to ask for permission again. And that caused even more background processing.
  • Competition: I did focus too much on competition. At that time GitHub was announcing to offer security alerts on their platform and I thought that’s the End of the game. But it wasn’t! GitHubs security database is good but not complete. And not everybody wants to host their code on GitHub to get security notifications. Of course there are more competitors in the field. But they are all kind of expensive and difficult to use. There is still much space for improvements!

So I thought about these things and how I would do it differently for VersionEye 2.0:

  • Customer Support: VersionEye 2.0 would be for paying customers only. People could still sign up for free and test the solution. They would maybe get 5 scans for free and then they would have to convert to paying customers. I would be happy to do support for paying customers!
  • Datensparsamkeit: VersionEye 2.0 would only crawl data which is relevant for customer projects. There is no reason to fill the database with meta information about 2 Million OS components if customers only use a fraction of them. That’s why VersionEye 2.0 would do crawling on demand!
  • Focused data: VersionEye 2.0 would collect as few data as possible and as much as necessary. Version information, license information and information about security vulnerabilities are necessary for the core business. Information about authors, transitive dependencies, meta tags/labels, description in Markdown files and so on are not necessary.
  • Closed source: Open sourcing the whole solution is not necessary! For some parts of the solution it makes sense to be open source. For example for API clients and so on. But the parsers, crawlers, license normalisation engine, API and WebApplication can be closed source.
  • GitHub Integration: A GitHub integration like in version 1.0 would not exist anymore! There might be an integration for GitHub Actions, which is a push mechanism to the VersionEye API.
  • Competition: I would focus more on the product and less on the competition.

VersionEye 1.0 started as a fun project but over the years it mutated to a huge software monster which sucked me in and have eaten up all my time. VersionEye 2.0 should be fun again and that means it must be lean again. In April 2020 I started to work on VersionEye 2.0! I started completely from 0. Did not reuse the old code base. I thought about the data structure and started with a new database schema. Much more focused and lightweight than the first version.

The main idea of VersionEye 2.0 is that there is one single API Endpoint where you can send your package manager files to and you get back the most important KPIs as JSON, in seconds! You can send your files via Curl, like in this example: 

curl --http1.1 -X POST https://api.versioneye.com/v1/scans \
     -H "Authorization: Bearer 9PAtYY4VzBfcYwGDvFTTtt910CCzlooAh0YZZ1oQ" \
     -F "pm_file[]=@package-lock.json" \
     -F "pm_file[]=@package.json" \
     -F "project_name=game-ui"

And you get back a result like this: 

{
  "dependencies": 1317,
  "outdated": 541,
  "license_violations": 2,
  "unknown_licenses": 2,
  "security_vulnerabilities": 1,
  "report": https://www.versioneye.com/en/organisations/ve-demo-orga/scans/5f9f2024a38b31d9e082600c"
}

Curl is already installed on most Linux/Unix based machines. That means you don’t need to download an additional client. With Curl you can already integrate a VersionEye scan into your CI/CD pipeline! You just need an API Key from VersionEye.

Now VersionEye 2.0 is online since a couple months and it has the first paying customers again. It supports less package managers than the old version and has a much smaller database. It’s much more focused and much faster than the old version. And I enjoy working on it again.

If a paying customer is requesting support for a new package manager, I will take some time and implement it. I’m also fixing bugs very quickly and I’m constantly improving the license normalisation engine. But it’s all not that time & brain consuming like at version 1.0. Much less emails now and the few emails I’m getting are mostly from paying customers or prospects.

Check it out and give it a try. If you sign up, use the Promotion code “VersionEye20“. With that you get a 50% discount on the monthly subscription. Would love to hear your feedback!

Leave a comment