Adding Python Support

VersionEye 2.0 started with only 3 languages. Ruby, NodeJS and PHP. Now Python was added as well!

VersionEye supports the package manger PIP. You can simply upload your requirements.txt file to get a BOM (Bill of Materials). By default the ‘requirements.txt’ file contains only the direct dependencies. I would recommend to use Pips freeze feature to lock down all transitive dependencies. That can be achieved with this command: 

python -m pip freeze > frozen-requirements.txt

That command will take all direct dependencies from the requirements.txt file, resolve all transitive dependencies and create a new file frozen-requirements.txt which contains ALL (direct & transitive) dependencies with fixed versions. That’s much better then the pure requirements.txt file because the frozen version contains all dependencies which are shipped to production. That contains ALL dependencies which are necessary to run the application.

Here is an example for a Python VersionEye scan:

Try it out and let me know how you like it! Would love to hear your feedback.

If you don’t have an account yet, signup with this promotion code “Ve2Python“. That code is valid until 4th of June and gives you a 50% discount on the monthly subscription!

VersionEye 2.0

More than 3 years ago I discontinued VersionEye. A SaaS tool for Open Source License Compliance & Security. VersionEye 1.0 could monitor your package manager files on GitHub, notify you about outdated dependencies and show you which of your dependencies are affected by security vulnerabilities and copyleft licenses (AGPL, MPL-2.0 and so on).

I was operating it for almost 7 years and at the end I was pretty much burned out! The reason why I discontinued it are described in this blog post. Working on it was not a joy anymore. My mailbox was flooded with support emails and after 6 years pretty much everything else looked more interesting to me than OS license compliance and security. That’s why I joined LivePerson at the End of 2017. I got a new challenge, met a lot of smart people and helped to grew the LivePerson Mannheim Office from 15 to 60 people in less than 3 years.

In 2018 Alex Spinelli, former head of Alexa OS at Amazon, joined LivePerson as the new CTO. He made a lot of organisational changes and did teach us a lot about Amazon management principles. Things like writing PR/FAQs, single threaded ownership, 2 Pizza teams, mission statements, leadership principles and many more things. That was very valuable and I enjoyed learning a lot of new things.

Of course, License compliance was a topic at LivePerson as well. Software teams had to ensure that they are compliant with a company license whitelist. The tools which we had to use for that at LivePerson have been far away from user friendly and good. With a crying eye, I looked back at VersionEye. I had no interest in resurrecting VersionEye 1.0 because I still remembered all the pain points of that solution. But somehow the topic was keeping circling in my head. So I started to think about how VersionEye 2.0 should look like. Not just on a technical level, but also on a lifestyle level. How would a version 2.0 look like which I would enjoy working on and wouldn’t burn me out again? So I thought about all the points which stressed me out at version 1.0:

  • Customer Support: With VersionEye 1.0 I had a lot of non paying users. Less than 1% of all signed up users (52K) paid a monthly subscription. More than 99% of all signed up users did not pay a single dime but most of them caused server costs and some of them caused support.
  • Too much data: In 2017 VersionEye supported something like 20 package managers and crawled all repository servers for them to collect all kind of information about software libraries. VersionEye had meta information for more than 2 Million software libraries/components. Every component can have multiple versions. A specific version of a component is an “artefact”. VersionEye had meta information for more than 50 Million artefacts. That’s of course a nice vanity KPI. Kind of cool if you can tell investors that your database contains meta information for more than 2 Million software components and 50 Million artefacts! Right? But the truth is that 99% of these software components are never referenced in customer projects! 99% of them are garbage! Even my biggest customer at that time, a big software giant from Germany, did not use more than 6K unique open source components for their active Java/NodeJS software development.
    Keeping the database with 2 Million components up-to-date requires a lot of crawling activities and that causes again a lot of costs.
  • Not focused data: VersionEye 1.0 collected even information which was not relevant for open source compliance & security. For example, the crawlers collected information about the authors of the software components and about the relationships between the components. That’s all kind of nice to know but not really necessary for the core business. Customers of VersionEye have only 3 questions:
    • Are my dependencies compliant with a license whitelist?
    • Are my dependencies vulnerable?
    • Are my dependencies outdated?
  • Open sourcing: VersionEye 1.0 was fully open source. I open sourced it because I assumed it would offer more transparency and therefor bring more new customers. And I assumed I would get a lot of contributions from open source developers. Both assumptions have been wrong! I did not really get more paying customers after I open sourced everything. My existing paying customers did not really care because they did pay for the service, implementation of new features and SLAs.
    Open sourcing the whole thing actually caused even more support. Because all suddenly more people opened GitHub tickets. Just very few people actually implemented an improvement and send a pull request. Most people just opened a ticket and waited for an reaction. All together I had to spend more time on GitHub tickets. I needed to read them, think about it, respond to them, doing more code reviews and so on. All activities which are very time consuming.
  • GitHub Integration: One feature of VersionEye 1.0 was that it could monitor your package manager files directly in your GitHub repositories. For that, users had to grant VersionEye access to their GitHub accounts/organisations. VersionEye then received a token per user/orga, which could be used to fetch files from the corresponding GitHub repositories. That of course, caused a lot of background processing. But the real pain point was that these tokens expired at some point in time and then VersionEye had to reach out to the users to ask for permission again. And that caused even more background processing.
  • Competition: I did focus too much on competition. At that time GitHub was announcing to offer security alerts on their platform and I thought that’s the End of the game. But it wasn’t! GitHubs security database is good but not complete. And not everybody wants to host their code on GitHub to get security notifications. Of course there are more competitors in the field. But they are all kind of expensive and difficult to use. There is still much space for improvements!

So I thought about these things and how I would do it differently for VersionEye 2.0:

  • Customer Support: VersionEye 2.0 would be for paying customers only. People could still sign up for free and test the solution. They would maybe get 5 scans for free and then they would have to convert to paying customers. I would be happy to do support for paying customers!
  • Datensparsamkeit: VersionEye 2.0 would only crawl data which is relevant for customer projects. There is no reason to fill the database with meta information about 2 Million OS components if customers only use a fraction of them. That’s why VersionEye 2.0 would do crawling on demand!
  • Focused data: VersionEye 2.0 would collect as few data as possible and as much as necessary. Version information, license information and information about security vulnerabilities are necessary for the core business. Information about authors, transitive dependencies, meta tags/labels, description in Markdown files and so on are not necessary.
  • Closed source: Open sourcing the whole solution is not necessary! For some parts of the solution it makes sense to be open source. For example for API clients and so on. But the parsers, crawlers, license normalisation engine, API and WebApplication can be closed source.
  • GitHub Integration: A GitHub integration like in version 1.0 would not exist anymore! There might be an integration for GitHub Actions, which is a push mechanism to the VersionEye API.
  • Competition: I would focus more on the product and less on the competition.

VersionEye 1.0 started as a fun project but over the years it mutated to a huge software monster which sucked me in and have eaten up all my time. VersionEye 2.0 should be fun again and that means it must be lean again. In April 2020 I started to work on VersionEye 2.0! I started completely from 0. Did not reuse the old code base. I thought about the data structure and started with a new database schema. Much more focused and lightweight than the first version.

The main idea of VersionEye 2.0 is that there is one single API Endpoint where you can send your package manager files to and you get back the most important KPIs as JSON, in seconds! You can send your files via Curl, like in this example: 

curl --http1.1 -X POST https://api.versioneye.com/v1/scans \
     -H "Authorization: Bearer 9PAtYY4VzBfcYwGDvFTTtt910CCzlooAh0YZZ1oQ" \
     -F "pm_file[]=@package-lock.json" \
     -F "pm_file[]=@package.json" \
     -F "project_name=game-ui"

And you get back a result like this: 

{
  "dependencies": 1317,
  "outdated": 541,
  "license_violations": 2,
  "unknown_licenses": 2,
  "security_vulnerabilities": 1,
  "report": https://www.versioneye.com/en/organisations/ve-demo-orga/scans/5f9f2024a38b31d9e082600c"
}

Curl is already installed on most Linux/Unix based machines. That means you don’t need to download an additional client. With Curl you can already integrate a VersionEye scan into your CI/CD pipeline! You just need an API Key from VersionEye.

Now VersionEye 2.0 is online since a couple months and it has the first paying customers again. It supports less package managers than the old version and has a much smaller database. It’s much more focused and much faster than the old version. And I enjoy working on it again.

If a paying customer is requesting support for a new package manager, I will take some time and implement it. I’m also fixing bugs very quickly and I’m constantly improving the license normalisation engine. But it’s all not that time & brain consuming like at version 1.0. Much less emails now and the few emails I’m getting are mostly from paying customers or prospects.

Check it out and give it a try. If you sign up, use the Promotion code “VersionEye20“. With that you get a 50% discount on the monthly subscription. Would love to hear your feedback!

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 http://www.metaeffekt.com/index.html.

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.

6858b8f0-fc3a-4426-adf5-ded4abf8e966

414557ed-3be3-4d4c-af2b-a654db4d1dbb

9c16584a-2100-4356-aff9-de2b77dddbfc

00630d1f-436c-4c68-8817-70fd7c9f5744

bdf24e29-df08-4fa1-a3f0-f59d9ca21be6

Transition

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 VersionEye.com 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?

shutterstock_291431081

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 VersionEye.com 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 support@versioneye.com and include your VersionEye username and the name of your VersionEye organisation.

What about the software?

The software solution itself behind VersionEye.com is completely open source. All code repositories are on GitHub: https://github.com/versioneye/. 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: https://github.com/versioneye/ops_contrib. 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.

startofanewjourney

 

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 Bower.io. If you are using Bower.io 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.

InventoryDiff.png

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
 mongo
 use veye_enterprise;
 db.sync_statuses.dropIndex("obj_type_id_index");
 exit
 exit

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.