License Compliance Management in Practice

VersionEye was set up to aggregate details on the different artifacts you consume in your development projects. The data VersionEye produces can feed important information to your continuous development pipeline or support your quality gates and thereby increase the quality of your software product in terms of security and compliance to the associated licenses or with respect to your specific company policies. The VersionEye whitelist can already be regarded as such a quality gate.

Two years ago, I got to know Karsten from {metæffekt}. He just founded the company in early 2016 with the goal to support others in building up and supporting a continuous development pipeline. While this is all not new, his focus is on adding aspects of continuous documentation and continuous license compliance to the picture. He argues, that any shipment of software using open source components requires documentation on the used third-party components, including the license information, license texts and – if required by the license – the source code. Last but not least the documentation must include notices that support the fulfillment of the obligations derived from the licenses.

Karsten immediately included VersionEye as a source for information in his processes and services. In the meantime, he and his team created a substantial network of layers, companies, and customers. Within that network and as members of different organizations they work on the primary rules of conduct to address the license compliance aspect in industry.

{metæffekt} is primarily a service provider. They support companies to aggregate the information required for the assessment of license compliance of a software product. They drive and moderate the communication between the different stakeholders and disciplines in a firm and discuss questions and ambiguities in their network and the communities. They know the subject in theory and – most important – in practice. They are rather tooling agnostic. Thus, it does not matter too much to them if assets already exist in your company.

Karsten and his team offer different kinds of services. They do seminars and offer initial consulting services for a moderate budget to get an impression on a companies’ status quo. If you feel uncertain on the topic of license compliance management in your organization – in particular after VersionEye is shutting down, I can recommend to reach out to Karsten.

You can find information and contacts on

The start of a new journey

Exactly one week ago on Thursday, I published the blog post about the “VersionEye Sunset Process.” The blog post went viral on Twitter, Facebook, and LinkedIn, and I received a couple hundred emails and some phone calls about it. The feedback was very positive. People understand my reasons, but they are very sad that the service will disappear. It was not an easy decision for me to do this. I had been thinking about this step for a couple months, and now I’m happy that I took it. It’s like a heavy burden has lifted.

Since that Thursday, I’ve received a bunch of job offers. Pretty much every bigger VersionEye customer offered me a position. They would like to hire me so that I can maintain the VersionEye software in house for them. But, as I wrote in my post, after six years I feel like I’m done with that chapter — and ready for something new. The same way Quentin Tarantino switches genres with every new movie he makes, I like to switch tech genres every couple of years. I want to move out of my comfort zone and work on something different, unrelated to VersionEye.

The software behind VersionEye is 100% open source, and it can be used in production even after the sunset process. Right now, I’m working closely with my enterprise customers to set up the VersionEye crawlers on their infrastructure so they can use it even next year and beyond. The learnings from this process will be documented, and I will write a separate article about how to run the VersionEye crawlers in house.

Most people wished me all the best for the future, and they asked me what my next venture will be. They assume I’ll directly kick off my next start-up thing. But I decided to go in a different direction. After six years of VersionEye, I still haven’t lost my entrepreneurial spirit, but, for the next years, I want something more stable. I received job offers from many well-known and large organizations. But one of them stood out, because it will allow me to use my entrepreneurial spirit inside of a very fast-growing and innovative company.

In November, I will join LivePerson as R&D group lead at the new Advanced Technology Center in Mannheim, Germany!

The Mission

We rarely use our smartphones to make phone calls. Calling is so old school! My parents used to place phone calls because they didn’t have apps 40 years ago. Nowadays our smartphones are mostly used for messaging. People talk via WhatsApp, Facebook Messenger, Threema, Twitter, Instagram, WeChat, and other messaging apps — so why isn’t customer support done via messaging?

Last time I had to call the hotline of my phone provider, I had to wait for 20 minutes in a queue. For 20 minutes, I had to hold my phone and couldn’t focus on anything else. For 20 minutes, I was blocked.

Why not replace that stupid hotline with messaging? The big advantage is that it’s asynchronous. After sending a message, I can turn to something else. I don’t need to respond immediately. I can choose to answer a bit later, maybe after I’ve finished another task.

And besides being more convenient for the customer, it makes call centers much more effective. A call center employee can handle only one phone call at a time, but the same employee can handle up to five messaging conversations concurrently because they’re asynchronous. So, that same call center employee can handle up to five times more customers through a messaging system. Call center productivity can be even further improved by combining chatbots with real humans.

LivePerson transforms customer care from voice calls to mobile messaging. I strongly believe in this mission and will be part of the solution 🙂

What will I do at LivePerson?

That’s where the entrepreneurial spirit comes in again. I will be responsible for building a team inside of LivePerson around a new product. LivePerson’s messaging systems are currently extendable through an LP SDK. My team will take this to the next level. We will build an infrastructure where LivePerson customers can simply implement extensions and run code right within LivePerson’s messaging system, without the need to deal with various infrastructure elements. The customer will just be able to push the implementation to the LivePerson cloud. Execution, scaling, and security will be handled by the new infrastructure service. We will build an environment for serverless computing inside of the LivePerson cloud.

I will have the resources to build a team around this new product, and I can hire everybody I want. Some LivePerson employees in Mannheim will join my team from day one on, but it won’t be enough. That’s why I’m looking for great, talented, and motivated people to join me. If you have experience with DevOps, Docker, K8S, AWS, GCE, FaaS, infrastructure as code, Java, JavaScript, Rust and you would like to work with me on a great new product, then please get in touch. You can contact me via email or on Twitter. By the way, I value a good profile on SO and GH more than a fancy master title 😉 I’m looking forward to hear from you.

Why LivePerson

I got many job offers from many great companies. Here are the main reasons why I picked LivePerson:

  • Company: It’s a company, not a start-up. The company been around since 1995 and has many big customers and 20 offices around the world. Inside of the company, there are small teams that can act like start-ups. But they don’t need to worry about money and lack of resources. The teams are getting all resources they need to achieve their goals.
  • Technology: The company itself is more than two decades old, but luckily they keep educating and upgrading. LivePerson is working with modern cutting-edge technologies. The developers are working on current hardware, using modern IDEs in combination with GitHub Enterprise, and they deploy build artifacts to their Kubernetes cloud, which is running on OpenStack.
  • People: LivePerson has an Advanced Technology Center (ATC) in Mannheim with about 20 experts. I had a chance to meet them, and they made a very good first impression. They are very smart people with a strong sense for team building. Each is an expert in his/her field. Some of them I’ve already known for a few years, and I totally can imagine working with them.
  • Location: The R&D office in Mannheim is in the city center, directly next to “Paradeplatz.” It’s a great office in a great location. The office is just five minutes away from my apartment. I could leave my house with a hot cup of coffee and it would still be warm by the time I arrived at the office. The only downside is that it’s difficult to choose where to go for lunch. There are just too many options around 😛

Here are some pictures of the office.







In November, I will start my journey with LivePerson. At the same time, I will work on the VersionEye sunset process. LivePerson is aware and supportive of my current situation. The rest of the year will be a transition period for me. My goal is to sunset VersionEye this year and settle into my new role at LivePerson. In 2018, my only focus at work will be LivePerson.

After six years of bootstrapping a business, I’m looking forward to working in a big company again. To have coworkers around me who work on the same product. To have a stable income and some vacation days. And I’m especially looking forward to not being responsible for everything alone.

Drop me a line.

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.

Rust Security

Since today VersionEye has support for Rust security vulnerabilities. Altogether VersionEye is aggregating 8 security databases now. If a Rust package is vulnerable the security issue is showed directly on the Rust VersionEye page. Here an example:

Screen Shot 2017-07-12 at 13.56.56

If VersionEye is monitoring a Rust project for you and one of your dependencies is vulnerable you will get notified via email.

Try out this new feature and give us feedback. We would love to hear from you.