API Breaking Change! Project_Key -> Project_ID

There is a little breaking change in the VersionEye API. Up to know it was possible to use “Project_Key” AND “Project_ID” for the Project endpoints. The “Project_Key” was a unique project identifier inside of a user account. For example “npm_package_json_1″ or “gradle_build_gradle_1“. At the beginning of the project that looked like a good idea. But it wasn’t. Because nobody is typing project_keys by hand. It’s something you receive from the API and you copy & paste it into some kind of config file, depending on the tool you are using. And because it only lives in config files the Project ID is just as good for that use case. Maintaining the Project Key in the code base, means a lot of redundancy. And since the organisations & teams have been introduced, projects don’t belong necessarily to a single user anymore. That’s why the Project Key was removed from the code base and from the API. 

Organisations & Teams

A big new feature was released today! The organisations & teams feature. It is replacing the “collaborations” feature. The “collaborations” feature didn’t worked out very well. It was too difficult and too time consuming to ad collaborators to the project. You had to fill the collaborators list for each project separately. That was just a lot of repeating work and many users asked for a “Team” feature, where you can define a Team once and assign a Team to a project. The new release today goes even one step further.


Now VersionEye has a concept of organisations, just like GitHub. Now projects can belong to an organisation, instead of to a single user. An organisation can have multiple teams, license whitelists, component whitelists and projects. A user can create/belong to multiple organisations.

Screen Shot 2015-11-29 at 17.20.35

The license and component whitelists are now only available through organisations. That way it’s easier to share them with other team members.


Every organisation has by default at least 1 team. The “Owners” team. The users in the “Owners” Team are the administrators of the organisation. They can:

  • edit the organisation detail informations
  • create/delete teams
  • add users to a team
  • remove users from a team
  • create/edit/delete license whitelists
  • create/edit/delete component whitelists
  • create/edit/delete projects inside of the organisation
  • transfer project ownership to the organisation

They can not:

  • delete the “Owners” team
  • delete the last user/member in the “Owners” team. There must be always at least 1 member in that team.

Members of other teams can:

  • remove them self from the list
  • edit/delete projects which are assigned to the team.
  • see all projects inside of the organisation

They can not:

  • edit the organisations detail informations
  • create/delete teams
  • add new members to a team
  • remove other members from a team
  • create/edit/delete license whitelists
  • create/edit/delete component whitelists
  • transfer project ownership to the organisation

Transfer a project to an organisation

If you want to work on a project with multiple team members it makes sense to transfer the project to an organisation and assign a team to the project. First of all you have to create an organisation. If you do so, you are automatically added to the “Owners” team of that organisation. Now you can transfer a project to the newly created organisation. Just go the project detail page to the settings tab. At the bottom you will see a select input field with all organisations where you have admin rights.

Screen Shot 2015-11-29 at 17.35.07.png

Simply select the organisation which should be the new owner of the project and click the “Transfer” button. If you go back to the project list view where you can see all your projects, you will notice that the project disappeared. Above the project list there is a filter. The first input field is the organisation filter. By default your personal account is pre selected. But here you can select and filter for an organisation you belong to. That way you will see only projects from that organisation.


Create a Team

A team is a collection of users inside an organisation which work on the same projects. Navigate to the “Team” page inside your organisation and create as many teams as you want.


Click on the team name to add some team members. Simply start typing the username or full name of a user and you will get some autocompletion with existing users.


Every new member of the team will receive an email notification that he was added to your team/organisation.

Now navigate to a project which you transferred already to the organisation. In the settings tab at the bottom a list of all teams of the organisation will show up. Simply select the team you would like to assign to the project and click the “transfer” button.


All the team members will receive the email notifications to the project. They all can edit the project settings and use their own API key to update the project via the API.


The API was updated as well. If a project is created through the API it can be assigned to an organisation at creation time.


The “orga_name” is optional. If it matches with an existing organisation name and the users API key has admin permissions for that organisation, the project will be assigned to that orga. Otherwise the project belongs to the user which is creating the project.

The other changes of the API are transparent for the users.

What is missing

Delivering this “Organisations/Teams” feature was a big refactoring. A lot of code had to be touched for that and the work is still not 100% done. 3 important things are still missing:

  1. Payment/Billing: Currently the organisation itself can’t have a subscription/plan. This is coming soon. The final goal is that an organisation can subscribe to plan and the whole billing is happening through an organisation, just like at GitHub.
  2. Creating Projects: If you create a new project via the API you can assign it directly to an organisation. This doesn’t work in the web interface yet. If you create a new project through the UI it always belongs to your user account and you have to transfer the project to an organisation if you want to have it in an organisation.
  3. OAuth: If a project was created through an OAuth process, for example from GitHub, Bitbucket or Stash, VersionEye needs OAuth credentials to update the project regularly. As the organisation doesn’t have OAuth credentials itself VersionEye randomly picks a team member of the project and assumes that the team member has the right OAuth credentials to update the project. In future it will be possible to pick a team member which should be used for OAuth update operations.


This is a big new feature and many users and companies asked for it. Please test it and give constructive feedback. I would like to know how well it works for you and what else (beside the 3 points above) is missing to make it super awesome. You can leave a comment here, mention VersionEye at Twitter and simply shoot me an email.

Security Alerts for Java & Python

A couple months ago VersionEye started to track security vulnerabilities for PHP packages. A couple weeks ago the feature was rolled out for Ruby & Node.JS dependencies as well. And now it’s rolled out for Java & Python!

Now you will see the security tab in your Java & Python projects as well. Just like in the example here.


If you click on the dependency link above you will come to the package detail page where more details to the security issues are visible.


If your project dependencies are affected the dependency badge turns to “insecure”, showing everybody that some of the dependencies have security issues.

The security feature is available via the VersionEye API as well. You can filter by language and prod_key. Feel free to build your own integration on it :)


VersionEye notifies you about security vulnerabilities independently from the version & license notifications. The security notification emails are going out on each Tuesday.

Currently VersionEye is crawling 6 different security sources for this feature. For Java & Python we are using the victims db, which claims to have 0 false positives. Please contribute to this db if you know about a Java or Python security vulnerability and help to make the world a safer place.

Do you know more good security databases which you would like to see integrated with VersionEye? If so contact me on Twitter please.

Security Alerts for Ruby Gems

Since a couple weeks VersionEye shows security issues for PHP projects. Now this feature works the same way for NodeJS and Ruby packages. If VersionEye is monitoring a Gemfile for you, then you will see the “Security” tab in the project view. Just like here in this example.


In the “Security” tab all known security vulnerabilities are listed for your 3rd party dependencies. If there is a security issue the dependency badge turns red! By clicking on the package name the package detail page comes up with a more detailed description of the security vulnerability.


On the detail the page a detailed description of the security vulnerability shows up and a link to the original source. That way it’s easy to reproduce the security vulnerability.

Now there is now reason not to use VersionEye. You get notifications about:

  • out-dated dependencies
  • license violations
  • security vulnerabilities

This feature is pretty new, but already good tested through the PHP community. Your feedback is anyway welcome either here in the comments or on Twitter.

Security Alerts for NodeJS

Since a couple weeks VersionEye shows security issues for PHP projects. Now this feature works the same way for NodeJS / NPM packages. If VersionEye is monitoring a package.json for you, then you will see the “Security” tab in the project view. Just like here in this example.


In the “Security” tab all known security vulnerabilities are listed for your 3rd party dependencies. By clicking on the package name the package detail page comes up with a more detailed description of the security vulnerability.


In most of the cases it is recommended to fix the issue by updating to the current version of the software package.

This feature is pretty new, but already good tested through the PHP community. Your feedback is anyway welcome either here in the comments or on Twitter.

Increasing the value of open source usage with tools

Many software companies are leveraging open source software as part of their business models and solutions. The reasons for doing so are simple: Open source software usually does not carry license fees, has high quality and can be easily accessed.

So let us talk about how commercial software vendors are using open source components as part of commercial software. Despite the opportunities and advantages open source provides, there are important development operations aspects, like updating open source components, and risks like security vulnerabilities that have to be managed. So let us look a little deeper into each of these aspects.

Development operations issues

On average, software products usually contain between a few and a few hundred open source components. The complexity gets even worse when we consider the fact that open source components themselves often contain numerous other open source components.

While it is easy for a developer to follow the community for one component, it is hard to follow the communities of dozens or hundreds of open source components. Getting notice of updated and improved versions of many open source components is often impossible. So the usage of numerous open source components leads to high effort maintenance work for developers which lowers productivity. Fortunately, tools like VersionEye allows you to manage and update these components continuously and lets you leverage developer capacity for innovation instead of looking for updates of open source components


One key source of risk of open source besides license compliance are security vulnerabilities, that are not fixed. To determine security vulnerabilities is a high effort activity. Fortunately, many people in the open source community test, collect and fix open source security vulnerabilities. The developer only needs to get notice of these activities.

Nowadays, many updates of open source components are related to fixing security vulnerabilities. Missing a security update is critical. If a developer misses an update, he exposes products and their customers to a hacker attack. Hackers know that a vulnerability exists in an old version of the open source component. Fortunately there are tools like VersionEye that track security vulnerabilities for you and alert you regarding those vulnerabilities and about security related security updates of open source components.

New book on open source best practices

There is a new a book that has all the necessary background information. It provides an overview of business models, processes and tools relevant for commercial software vendors leveraging open source software and open source communities, no matter if the company participates in open source development or not. The one of a kind combination of academic and pragmatic information, from researchers, practitioners and tool vendors like VersionEye make this book a must have for all people in the software industry.

The book is called “Best practices for commercial use of open source software” and it is available in all major online and offline bookstores, in Google Play, iBooks and on Kindle. ISBN 3738619097

Guest Post

This is a guest from Dr. Karl Popp, Senior Director Corporate Development M&A @ SAP.

Dr. Karl Popp is all about corporate development and mergers and acquisitions in the software business, from successful partnerships to successful mergers and acquisitions. He loves to share his wisdom in books and other media like http://www.drkarlpopp.com.