Category: Update

New project view with more details

VersionEye can monitor your software project and notify you about out-dated dependencies, license violations and security vulnerabilities. Up to now we had for each of them a separate tab in the project view page. That was bit confusing and many users even didn’t noticed that there are different tabs. That’s why improved that. Now there is one unified table view which shows all the desired information. Here an example:

Screen Shot 2017-05-10 at 09.09.47

Everything what is red is an issue. In the above example you can see immediately which dependencies have security vulnerabilities, which are outdated and which are violating your license whitelist! There is no need of switching between tabs anymore!

The header was refactored, too. Now you can download all the available project exports from the same page. By the way the version.pdf export is new 😉 Beside that you can download here the license.pdf and security.pdf for your project.

versioneye-exports

The skipped the license tab completely but kept the security tab because it’s still a nice summary for the security vulnerabilities!

Let us know how you like this new view.

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.

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. 

New Pricing

Now there is a new pricing for VersionEye. The new pricing is more consistent and easier to understand. Please check out the new pricing page.

Screen Shot 2015-09-18 at 10.45.18

You can still sign up for free and monitor unlimited open source projects at GitHub/Bitbucket for free. The paid plans are required for private and closed source projects and for additional features like PDF/CSV export. Now the PDF and CSV export for the Bill of Materials in the license tab are only available in the higher paid plans.

The old plans are going to be continued. You don’t have to switch to a new plan if you don’t want. The old plans are available for booking until end of this month. You find the old plans in the settings area under “plans“.

Screen Shot 2015-09-18 at 10.24.42

The old plans can be booked until 1st of October. After that the old plans are closed for booking and only the new plans are available.

Geek2Geek at Delodi

The last Geek2Geek event was at Delodi in Berlin. This time we talked about Configuration Management Tools. Probably you heard about Chef and Puppet already. We had 2 talks to the new kids on the block. To Ansible and Salt.

A couple weeks ago I pushed out a tweet about Ansible and Frederic responded with an answer. He mentioned that he is using Salt Stack, but he would like to learn more about Ansible. I mentioned that we could do a Geek2Geek event to that topic and if he agrees to do the Salt talk I would do the Ansible talk. And so we did! That’s how I found the topic to this Geek2Geek event 🙂

Frederic just arrived the day before in Germany, coming in from San Francisco. He had a bit jet lag. That’s why he did the first talk about Salt.

02-Geek2Geek

Frederic gave us a very good overview about the architecture of Salt. You can find his slides here.

After a short break I did the Ansible talk. The special thing on Ansible is that you don’t have a Master and you don’t need to install a client on the servers. It works via SSH and the configuration is done in Yaml. Here are my slides to Ansible.

The Geek2Geek group was this time a bit smaller than last time. All together I counted 30 people. It was a good round with interesting talks afterwards.

03-Geek2Geek

A special thanks to our Sponsors.

Guarana Brause

Guarana Brause sponsored this time the Pizza. Many Thanks for that. Guarana Brause is a powder with natural caffeine. You can mix the powder with water or any other drink. It’s much better than coffee and very popular in the tech scene of Berlin.

Screen Shot 2014-10-12 at 18.36.43

Delodi

Delodi sponsored the Drinks and of course the space. Delodi is a cool tech company in the heart of Berlin. They build solutions for their clients, mostly with PHP & JavaScript.

Screen Shot 2014-10-12 at 18.39.31

They have a really nice office in Kreuzberg at Oranienstrasse, with a lot of free space. And by the way, they are currently looking for another PHP Senior Developer. if you want to work with smart people, on cool projects in the heart of Berlin you should contact Delodi.

The Heartbleed Bug

If you don’t live behind the moon you probably heard already about the Heartbleed bug in openssl. This bug is so critical for the security of the internet that it even gets his own domain, logo and marketing campaign.

heartbleed

Here you can test if your server is affected: http://filippo.io/Heartbleed/

Unfortunately VersionEye was affected as well. We don’t have any reason to believe that we have been compromised! But we exchanged anyway all secrets and revoked all tokens from GitHub and Bitbucket.

What does that mean for you? If you signed up at VersionEye with your GitHub or Bitbucket account you have to grand VersionEye access again to your GitHub/Bitbucket account. Just use one of the social media login buttons on this page:

https://www.versioneye.com/signin

If you are currently signed in at VersionEye you can re-connect your GitHub/Bitbucket account here:

https://www.versioneye.com/settings/connect

If you signed up with your email address please use the “password reset” function, because we reset all passwords in our database to some random values.

https://www.versioneye.com/iforgotmypassword

I’m really sorry for this inconvenience. But safe is safe!

You can believe me that my heart was bleeding than I was clicking the “Revoke all user tokens” button at GitHub :-/

Email trouble

Currently we are using PostmarkApp as email provider to send out our notification emails. They have a nice API and a pretty good Ruby Gem.

Unfortunately we had last week some issues with PostmarkApp. They paused all our emails for almost 3 days. The reason for this was our newsletter. Somehow it’s fine to send out every day a couple hundred notification emails but it’s not OK form them to send out newsletters. However, we promised not to use PostmarkApp anymore for newsletters and so they send out all our paused emails.

Probably you got 2 or 3 emails at once. We are sorry for that. That should not happen again.

Updates for Cocoapods support

TL;DR

We made the following changes for Cocoapods:
– Now we can watch your project’s Podfile as well as the Podfile.lock.
– We display all dependencies for a Podspec file.
– If there are dependencies to subspecs, only the corresponding spec is displayed.
– The pages show the actual version release dates for pods hosted on Github.
– Now there is a link to the original podspec file in the Cocoapods Specs repository on Github.

Details regarding VersionEye’s support for Cocoapods

Since we initially announced support for Cocoapods we got a lot of feedback from you. So, we want to say thank you for pointing out bugs and suggesting improvements which helps us to make the product better day by day.

First of all we improved our crawler to better represent Cocoapod’s podpecs. There was a small bug that prevented dependencies to display correctly.

Since Cocoapods doesn’t have the original release dates we try to get them from the corresponding git tag now. We use the Github API to do this, so currently this works only for pods hosted on Github. This is how version dates for AFNetworking look like now.

And because we have the release dates for most of the CocoaPods artefacts now, we can display proper KPIs for CocoaPods. That means we’re able to show you the average release dates of a Pod as well as number of references from other Pods.

KPIs for AFNetworkingVersions of AFNetworking

We also display a link to the original podspec file in the Cocoapods Specs repository on Github. This should simplify comparing the original podspec with the data we display.

Subspecs

When we first introduced the list of dependencies for Cocoapods, we realized that Cocoapods has a feature called “Subspecs”. This is a cool feature that actually makes a lot of sense for the development of iOS apps. But subspecs is also a feature we couldn’t found in any other package manager yet.

When we first displayed dependencies, we saw that a project which depends upon Sharekit/Facebook and Sharekit/Twitter wouldn’t link to the Sharekit page on VersionEye. This made sense, because VersionEye‘s internal database domain model doesn’t support anything like subspecs yet.
ShareKit itself also depends on several subspecs of Google-API. This is how it looked like:

dependencies for sharekit

Since the version number is global in a Podspec file and all subspecs share the same version number, we thought it would be better to just summarize subspecs and show the podspec’s name instead. So the new version looks like this:

display consolidated dependencies

While we recognize this isn’t 100% correct, we feel that it improves the usability of VersionEye for iOS and Mac developers.

Since we have a little bit historical data now, we can show a nice chart about new Pod versions and packages. Check out our Objective-C page.

Screen Shot 2013-11-29 at 12.50.17

We hope you like all the new changes. If you have suggestions or find a bug, please let us now in the comments, via email or on Twitter and Facebook.