VersionEye Sunset Process

I’m shutting down VersionEye by end of this year!

I started the project round about 6 years ago and so far it was a journey with many ups and downs. The typical StartUp rollercoaster thing. I raised Money from a big VC in Berlin and almost went bankrupt after that. Raised Money again from small Angel Investors to prevent bankruptcy. Won one of the biggest Software companies in the world as customer and established a stable income for the company.

Why to shut down?

There are several reasons for that.

  • Revenue: In 2016 the company generated 103K EUR through the product itself and a couple 10K through consulting services which are not related to the product. That’s not very much for a company. If you subtract cost for office, servers, salaries, consulting fees, travel expenses, sales commission, unexpected costs and tax & accounting than suddenly it’s a very small amount. And unfortunately the revenue stream isn’t growing very fast. Actually this year product revenue & traffic even went down and costs went up.
  • Sales: The biggest chunk of the revenue comes from on premise installations at a handful of big Enterprises. Unfortunately I failed building a real sales team. There wasn’t enough revenue there to hire a full time sales guy, that’s why I worked with a sales guy on a commission only base. Beside that I did sales by myself, part time. But that wasn’t very successful. Enterprise sales cycles are usually very long. Some times it takes years to close a deal. And most of the sales efforts are not successful. Sometimes you work for months on a new deal and then you lose it. Or you win a new deal and then it causes so much support afterwards that it’s a bad deal overall.
  • Support: Right now has more than 50K signed up users from all around the world. Sad fact is that 99.8% are NOT paying anything for the service. 99.8% are using the cloud solution for free. And even worst, they cause a lot of support. They write emails, tweets and open new tickets on GitHub like there is no tomorrow. Especially the non paying users are very demanding if it comes to new features, sometimes in a very rude way. Or they complain that the free tier is too restrictive. A big part of my day is occupied by responding to support emails/tweets/GH-tickets. And somehow my inbox is never getting empty and that is stressing me! It’s like running in a hamster wheel without making any progress. I know how to build scalable software, but most of the time I’m busy with answering emails from people who are not paying for the service. That’s very demotivating! That’s why I’m stopping it right now!
  • Competition: Then I started this project there was almost no competition. Actually I was actively looking for a tool which can notify me about new versions of my open source dependencies, but I didn’t found anything, that’s why I started to build a solution for myself. The landscape today looks completely different. Every couple months a new competitor is coming up and usually they have some serious VC funding and a huge team. Beside the new VC funded kids, old players in the market are going into open source analysis as well. Now GitHub notifies you directly about security vulnerabilities in your Gemfile. No need to use VersionEye anymore. They will roll out that feature to other languages and soon they will have the same language coverage as VersionEye does (17 package managers are supported by VersionEye). I’m sure that Bitbucket and GitLab will follow. They have to! For me there is no reason to compete with GitHub on a small margin market.
  • Motivation: Then I started the project I was highly motivated. But actually the whole business side was always very tough. In 2014 then I was moving from Berlin back to Mannheim the company was just 2 weeks away from a bankruptcy. I only kept going because I wanted to prove everybody that VersionEye is more than just a side project. I wanted to prove that there is a business behind it. And I proved it. But if you work your ass of and all the effort is not reflected by positive numbers on the bank account, then that is a very bad thing for long term motivation. It feels like riding a dead horse. If I would work the same amount of hours as employee or freelancer for a big company I would have a much better income, less responsibilities, less stress with my inbox and more vacation days. Beside that I’m pretty much done with that whole OS domain. After 6 years of OS analysis everything else seems to be more interesting to me. Since round about 1 year I find DevOps, ChatBots, AI, Bockchain, Crypto currencies and many other things much more interesting than writing parsers & crawlers for open source package managers. It’s time to move on.

What about paying customers?

What will happen with paying customers who paid in advance for the service?


Don’t cry. You get refunded!

The majority of the big Enterprise contracts are running out by end of this year. VersionEye GmbH will not renew them. So it’s a clean cut. Some contracts are running until summer 2018. Those customers are partly refunded.

The big majority of the paying cloud customers are on a monthly subscription. Just a few paid 1 year in advance to get a small discount. If you have a monthly subscription on and you don’t quit your subscription until mid of December, then the VersionEye software will switch you automatically to the free plan.

If you paid 1 year in advance for the cloud solution, you get partly refunded. Let’s say you started your yearly subscription by the 1st of July, then you will get 50% of the Money back by 1st of January. If you don’t get refunded automatically then please write an email to and include your VersionEye username and the name of your VersionEye organisation.

What about the software?

The software solution itself behind is completely open source. All code repositories are on GitHub: Most of the repositories are implemented in Ruby, the most aesthetic programming language I know so far.

In this repository is a description how to setup your own VersionEye instance: There is a set of Docker images which can be started through Docker Compose. There is a also a Vagrantfile available, if you prefer that.

Feel free to use it, but don’t expect me to answer open GH tickets any time soon.

What’s next?

Every end leads to a new start.



Security Vulnerabilities for JavaScript

VersionEye is aggregating data from different data sources, such as repository servers and security advisory databases. This week a new security database for JavaScript was integrated. Now VersionEye is matching security vulnerabilities from Retire.js with JavaScript modules from If you are using to manage your JavaScript dependencies then VersionEye can automatically point out potential security issues in your dependencies.

Screen Shot 2017-08-11 at 10.09.13

Try out this new feature and leave a comment here if you wanna give feedback.

New Feature: Inventory Diff

VersionEye has an open source inventory list for every organisation. That list simply shows all unique dependencies of an VersionEye organisation. The inventory list can be filtered down by different criteria of course.

Now VersionEye can show you the difference between 2 inventory filters. On the new “inventory diff” page you can configure 2 different filters for your inventory and VersionEye will output the differences.


That is especially useful if you are tracking 2 different versions of a project in VersionEye and you want to see the changes in the dependencies. In the example above we can see the differences between Java projects in version 3.11.4 and 3.11.5. We can see that in version 3.11.5 the graph-api 0.9.1 was added and the testNg 6.11 dependency was removed.

Try out this new feature and leave a comment here if you wanna give feedback.

Ignore UNKNOWN licenses on pull requests

Since a couple months VersionEye can check your dependencies on each pull request on GitHub. That was described here. VersionEye will mark the status of the pull request as failed if:

  • a dependency has a 1 or more security vulnerabilities
  • the license of a dependency violates the license whitelist
  • the license of a dependency is UNKNOWN

An UNKNOWN license is as dangerous as a violation of your license whitelist. Simply because the maintainers of the dependency can come up with a dangerous license afterwards and that could harm your company. That’s why strongly recommend NOT to ignore UNKNOWN licenses.

However, some people want to simply ignore UNKNOWN licenses in their projects. That’s why we introduced this option now. On the license whitelist there is a new checkbox now.

Screen Shot 2017-07-22 at 12.42.22

If that option is checked and the license whitelist is assigned to the project, then UNKNOWN licenses will not cause a failed status on the pull request check. Use this checkbox wisely!

“fetching meta data for undefined” – Bug

If you are running your own VersionEye instance since more than 4 weeks then you might see a message like this in the UI:

“Meta information about the project dependencies are currently fetched from the public VersionEye API. Currently fetching meta data for undefined.”

“undefined” is NOT the name of a dependency! In some cases a variable in JavaScript is undefined. This UI bug is fixed in the newest VersionEye Docker images. Unfortunately the bug is related to some indexes on the database which are not valid anymore. To fix this permanently you have to drop “obj_type_id_index” index on MongoDB. That can be achieved with this commands on the VersionEye server:

 docker exec -it mongodb bash
 use veye_enterprise;

That will remove the index and fix the problem permanently. A new index with the same name will be created automatically in the next 24 hours, from a background job.

Keep your global NPM modules up-to-date

npm can be used to install npm modules to packages (package.json), furthermore npm can be used to install npm modules globally with the command line flag "-g" for system wide usage. Usually this is the way to install „grunt“, „eslint“ or „npm“ itself.

These globally installed npm modules cannot be monitored. They are not updated with "apt-get" or any other system updates. This is usually not a problem on developer machines but it can lead to problems on servers without any interactive logins like Jenkins build server. „versioneye-update“ in the new version 1.4 can create a list of the globally installed npm modules and upload it as package file to VersionEye. The VersionEye server will send you a notification as soon as there is a new version of one of the globally installed modules available.

Read more about this cool feature at the Onwerk blog post. Onwerk is a small company in Mannheim / Germany, specialised in custom software development with Node.JS, JavaScript and .NET. They are very active in the local Node.JS & JavaScript community and they are very interested in working with cutting edge technology.

Perl Support

We just added support for the popular programming language Perl. Right now there are more than 41250 Perl packages in the VersionEye database.

Screen Shot 2017-07-12 at 20.29.14

The API is crawled once a day to keep the VersionEye database up-to-date. You can follow any of the Perl packages and you will be notified as soon a new version of the followed package is released.

Screen Shot 2017-07-12 at 20.29.47.png

Beside that VersionEye can parse & monitor the file format “cpanfile”. A cpanfile describes the dependencies of a Perl project. VersionEye can actively monitor your Perl project on GitHub and notify you about out-dated dependencies.

Try out this new feature and feel free to give feedback.