VersionEye goes open source

We have some exciting news for our community – VersionEye is now open source, licensed under MIT!

VersionEye is a popular platform for software developers, which notifies you about out-dated dependencies, security vulnerabilities and license violations in your software projects. This makes your agile software development more productive, reduces problems, risks and ensures compliance. Currently VersionEye supports 12 package managers and is well integrated with GitHub, Bitbucket and Atlassian Stash. GitLab support is coming soon!

Our SaaS solution is used by thousands of software developers every day and the number of visitors and users is growing constantly. For VersionEye Enterprise we have a handful big installations at well known DAX companies where it’s used as on prem. solution, successfully integrated with LDAP and private Git & Maven repositories.

Why open sourcing the code?

I talked with many people about open sourcing VersionEye. Some of them recommended to do it and others not. Like everything in life it has pros and cons. But in the end, I decided to open source it to provide more transparency because many of our users care a lot about privacy and transparency. Specially big insurance companies in Europe have to follow very strong privacy laws. Up to know VersionEye Enterprise was a black box delivered as VMWare image without any root access for the customer.

For many big companies this is an issue because they don’t know what’s really happening inside of the black box. As more and more big companies are rebuilding their entire infrastructure with open source components like Linux, Archiva, CoreOS, Docker, Kubernetes and GitLab, as less they want to have proprietary black box software. Now VersionEye is open source under MIT license and everybody can use the software for free, just like CoreOS, Docker and GitLab!

Transparency

Nobody has to unjustifiable fear any longer that VersionEye is doing any unauthorised action like copying source code, exposing confidential data or causing any harm. You can simply go to GitHub and do a code review by yourself! Being an open source project means to be fully transparent and trustable. Since VersionEye is open source nobody is questioning statements to privacy anymore. It adds a lot of trust to the project because every change on the code base is public and everybody can review what’s going on.

Contributions

Until now the biggest part of VersionEye was closed source and the only way to contribute was to open a ticket in our public ticket system and wait until somebody from the VersionEye team implemented it. In the last couple years ~ 800 tickets have been opened from the community and we could close most of them. But now it’s different. If you know how to code you don’t have to wait for the VersionEye team anymore. You can implement new functionality by yourself and send back a pull request to VersionEye.

The VersionEye API is online since 3 years and the open source community created already a lot of AddOns & Plugin on top of it. For all major build tools there is a native VersionEye plugin, there are several command line tools, Slack connectors and even a native Mac OS X app for VersionEye. All build on top of the public VersionEye API. This is awesome because all this work is coming from volunteers. Nobody paid them to do this work. They did it in their free time because they wanted to use this tools for themselves and they shared it with the community. You guys are all awesome and by the way you created an ecosystem around the VersionEye platform! Many Thanks for that! 

In the meanwhile the VersionEye API is processing more requests than the web servers! That shows me that the people are using the VersionEye platform strongly customised in their own tool chain and in their component lifecycle management. They use VersionEye through native plugins, AddOns and other tools which are based on the VersionEye API.

Now we take it to the next level. Now versioneye-core, versioneye-api and versioneye-www is open source as well and everybody is enabled to add new features to the product and I hope to get a lot of contributions from the open source community.

New Business Model

As the software itself is published under MIT license, we can’t charge Money for VersionEye Enterprise anymore. MIT license means everybody can use the software for free, even for commercial purposes. The software is provided “AS IS” and “WITHOUT ANY WARRANTIES”. The cloud offering at VersionEye.com remains the same of course. You can still pay us for the hosted version if you don’t want to maintain the VersionEye software by yourself.

API

If you spin up your own VersionEye instance with Docker Compose your database is empty, of course. That means you can upload a package.json to your VersionEye instance but in the project report all your dependencies will be displayed as unknown because the database is empty and your local installation doesn’t has any information about NPM packages.

With an empty database the software isn’t much fun 😉
Luckily there is a “sync” mechanism build into VersionEye Enterprise and as soon there are new project dependencies in the system, the local installation will fetch the missing meta information from the public VersionEye API. The access to the VersionEye API requires an API key and is limited to 50 requests per hour by default. For more requests a paid account is required.

Of course, anyone could run and maintain their own crawling framework but this neither an easy nor  a cheap thing. We are constantly improving and monitoring our crawling framework. In addition to that we run regularly data repair jobs to improve the quality of the data and we do a lot of manual edits as well.

If an Enterprise customer is using an old JAR file which doesn’t provide a license in the pom.xml file we are opening the JAR file and try to find a license inside of it. If that fails too, we are looking up the contact details of the core committers and ask them via Email about the license of their software.

If an NPM module on GitHub doesn’t provide the license in the package.json, we add it and send back a pull request. If the GitHub repo of the NPM module doesn’t has a license at all we are opening a ticket and asking for the license.

That are just a few examples we do to improve the quality of the VersionEye service.

Support

If you think you have a serious issue with VersionEye you can now study the source code and try to fix the problem by yourself, which might create some effort. But if you have a service/support contract with VersionEye GmbH you can just post into our Slack channel or send us an email and you will get a response in hours and in most of the cases we can fix your problem asap.

Custom Development

Maybe you want to have custom reports, custom emails or you want to have support for your self-developed package manager? This are all things you can implement by yourself, but obviously we can implement it faster and more economical than anybody else as we do know the VersionEye code inside-out 🙂

If you want to have a custom feature feel free to contact us at support @ versioneye.com.

VersionEye on Docker

Since almost 3 years VersionEye is running on Docker!

Now the VersionEye Docker repositories on Docker Hub are public. Every time we do a deployment to production a new Docker images gets published on Docker Hub. In this GitHub repository there is small tutorial how to spin up the VersionEye Docker containers with Docker Compose: https://github.com/versioneye/ops_contrib.

If something is unclear feel free to open a ticket or to send a pull request 😉

Plase see the comments at Reddit.