I was tired of the endless “I’d like to add you to my professional network on LinkedIn.” emails from and I was tired of them trying to sell me a so called “Premium account”. I like the idea of LinkedIn and the German equivalent but I don’t like how they are solving the given problem. Too many emails, too many pop-ups, too slow and too little features for non-paying users. I created ( ) to be a . LinkedIn XING vutuv https://www.vutuv.de free and faster alternative Obviously I didn’t want to create a 100% copy. I want it to be better. More focused on the main feature which is the exchange of contact information and the rating of skills. The networking for people. I’m not a big fan of LinkedIn’s blog/postings like features because Facebook does a much better job for those features. But I’m open for this if users convince me that this has it’s place on such a platform. Facebook I don’t want vutuv to be just a pure career network. It’s potential is bigger. Development History Speed has been a big issue from the very beginning. For people in San Francisco or Berlin it is kind of ok to use LinkedIn. They either have fiber in their office or LTE (4G) on their mobile phone. But the big majority of internet users don’t have fiber or they use very slow 2G or 3G mobile networks. For them those heavy webpages are painful slow to use and they are expensive to use too. Users in most use prepaid data plans which are paid in 10 MB slices. Loading a single LinkedIn profile can cost up to 1 US$ for a mobile user in Zimbabwe. And most internet users in development countries only have their mobile phone to connect to the internet. Botton line: There is a big potential which is totally untapped. developing countries Therefor it became very clear that vutuv would have to have a light footprint and a very good webperformance. As a side effect it would be fast even while surfing on those overcrowded and super slow WiFi hotspots at technical conferences everywhere. According to LinkedIn has more than 100 million active users and about 10,000 employees. According to a they run over 40,000 servers. Those numbers are important to understand why they need to sell not only ads but also Premium accounts. They simply have a lot of bills to pay. Wikipedia Quora posting It became very clear to me that the key for a free service is the use of better software technology and architecture. I can only offer this service for free if vutuv needs less servers and less maintenance. My role model is WhatsApp which was run by some 30 people and had a comparable small amount of servers when it was bought by Facebook but already had an enormous amount of users. I don’t remember when I actually started with the creating of vutuv. There have been many proof of concepts. Some of them with real code but most of them as virtual code in my brain while waiting in some traffic jam. I wanted the site to be free and super fast. The only revenue would be ads. Being a fan I started the first versions with Ruby on Rails. I added as a JavaScript Framework for the client-side. Both great technologies and great open-source communities. I really love them. The biggest advantage is the development speed of Rails and Ember applications. Obviously I used as a CSS framework. and the whole shebang. Ruby on Rails Ember.js Twitter Bootstrap jQuery Long story short: That software stack made for a good development environment but the result was too slow and heavy for our needs. I’m very good with Rails and caching (see ) but the average server rending time of the pages where 3 digits milliseconds. That doesn’t sound much but if you are talking about several million users that adds up quickly and I knew that I needed to be frugal on the server side to make this economically feasible. Plus the single page JavaScript idea was a nightmare for potential development country users. Even Ember’s (BTW: great technology) was not the solution to our problem. The single page JavaScript webapplication was a lot to load plus wasn’t suitable for old or feature phones with small CPUs and little memory. my Railsconf talk about caching FastBoot The situation asked for a different approach. I started with the webperformance aspect and made the decision that each page should aim to be not bigger than 28 KB. And that includes HTML, CSS and the images which are above the fold. If you are wondering why 28 KB (2nd TCP roundtrip has a payload of 1460 x 20 / 1024 bytes) than you should read the book by . To put those 28 KB into perspective: The average size of a webpage (incl. images, HTML, CSS and JavaScript) is currently . But that number is for uncompressed content and the 28 KB are for gzip compressed payload. Still 28 KB is a crazy small number for a webpage in 2016. We had to make sacrifices in the design. This 28 KB limit was the reason for a constant fight with my CSS and graphic guys. They could never believe why I made such a fuzz of 2 or 3 KB more or less. We still have room for improvement here. Expect more in the next couple of month. High Performance Browser Networking Ilya Grigorik 2,509 KB (October 2016) But that was just part of the solution. What good does it make if I deliver a small webpage when that webpage loads several hundert kilobytes of JavaScript afterwards to load ads and to run analytics? That’s the reason why vutuv neither uses nor . Both the defacto standard and not having them were bitter pills to swallow. It meant that we’d have to run our own ad system and that we wouldn’t have any other analytic tool apart from our webserver logs. Google Analytics Google AdSense NGINX The Servers That still left the server question to be solved. The came to the rescue. It was invented by who comes with a heavy Ruby on Rails background. He actually started the development of Phoenix because he couldn’t stand the performance and concurrency limitations of Rails any more. Phoenix is lightning fast and offers nice production features like a zero downtime deployment. Phoenix is written in . A functional programming language which is on top of Erlang. Erlang is the secrete sauce that made success story possible because of it’s speed and scalability. I’m not going to lie to you: The change from Ruby to Elixir is intense and hard for any programmer. The Phoenix/Elixir combo has a steep learning curve. But it was worth it. The average vutuv request is handled in a 2 digits millisecond timeframe. Many request are answered within less than 10ms. Phoenix Framework Chris McCord Elixir WhatsApp Please send me feedback in case you are interested in a more detailed analysis of the architecture. I know this is boring for most people so I try to keep it as short as possible here. We run our own server farm instead of jumping on the train. There are performance reasons but the main reason is budget. For us it’s cheaper to run our own servers in a freezing cold and boring computing center in Frankfurt (Germany). But we’ll have to rethink the one central server farm idea in the future because of webperformance issues. Today users in Sydney are punished unnecessarily. Users in San Francisco could use the page at twice the speed. The length of the network connection between the server and your devise is our main webperformance bottleneck. AWS No JavaScript? Seriously? But it’s 2016! Yes, the current version of vutuv doesn’t contain any JavaScript. We do all the logic on the server. Like in the good old days. The difference is that we do it very fast and the pages have such a good webperformance that it feels good. A good GUI is all about timing. The user wants to get a quick feedback for his/her input. We are providing exactly that and we provide it in a way that every one can access it. The fellow developer in USA with Google Fibre and a family in a developing country who only has access to the internet via an old feature phone on a 2G network. vutuv runs circles around LinkedIn on any devise! But there are many good cases where a single page JavaScript application does make sense (offline mode comes into mind first). So we might publish an additional fancy webclient version for vutuv in the future (probably written with Ember.js or ). We already have the JSON API build in our Phoenix application (it is disabled right now). We go step by step. Our main goal now is to get as many new users onboard as possible. I believe our light weight approach is the best way to do so. Elm Features Done is better than perfect! We start with the minimal system where users can enter their contact information (e.g. phone numbers, email addresses, Twitter and Facebook accounts). Those informations can be downloaded as vcards to be easily imported to your address book. No Passwords There is no reason for us to store a password. Even with a maximum effort in security there is always a slim chance of some evil hacker breaking into a system and stealing stuff. We all have seen it way too often in the last years. So vutuv doesn’t store a password but sends a “magic link” by email which you can use to log in. Easy peasy! Than we set a 90 days cookie which authorize your devise as being you. Less Emails Of course the system will send you emails. But not about every little thing in the universe. We try to optimize the amount of sent emails to a minimum. This is going to be an ongoing optimization process. So don’t be scared if you don’t receive an email for every single new follower. Skills A user can create skills and other users can upvote those skills. There is no downvoting because that is just mean. Once we have a critical mass we will use those skills for a better search (e.g. find a PHP consultant in my area). Search This is a chicken-egg-problem. We just started vutuv so who do you want to search for? ;-) The current search is very basic. The best chances to find somebody is to search for his/her email address. Friends or Followers? Traditionally a social network uses some sort of friend request system. So Alice sends a friend request to Bob and Bob has to accept or deny it. This can become awkward pretty easily. Let’s assume Bob is on vacation or simply forgot the friend request. Than Alice gets the impression that Bob doesn’t want to be befriended to Alice. And maybe he really doesn’t want to. Which is even more awkward. To avoid those situations vutuv uses a follower system like does. So Alice can follow Bob without him having to refollow. Twitter Verified In any social network there is always the potential of having fake accounts. We don’t disallow that because sometimes an anonymous account can be useful for people who live in political systems which don’t grand them all human rights. If somebody has the need of creating an anonymous fake account he/she is welcome to do so. But we are providing a . In the beginning we are going to hand pick those humans and verify them manually. In the future we will find some sort of process to streamline that. Those accounts will have a verified mark near the avatar. verified functionality for real humans What’s in the pipeline for future releases? The next big feature will be a better permission system for your data. In the first version everyone can see nearly all information of a given user. In the next version there will be groups of users who get special access to information. You can grand rights to the people you follow. A little peak into future features. I’ll give you an example: I’d like to give the parents of my kid’s friends access to my land line phone number. But I don’t share that information with my business associates. Expect this feature soon. After that we will give companies the possibility to create accounts and will associate their employees with them. Companies will be able to grand other companies read access to their information. Additionally we are going to improve the search functionality. There is a lot of room for improvement but you need a critical mass to make that feature usable. About the Software vutuv is an open-source software (MIT license). The source code is hosted at . I’m not religious about software licenses. I do believe that the quality of open-source software is better because more pairs of eyes look at the code. I do hope that the community is going to help making vutuv better and more powerful but I’m not relying on it. https://github.com/vutuv/vutuv/ If you want to help with this open-source project send me an email to stefan.wintermeyer@amooma.de. But of course Elixir developers are welcome any time too. Currently we are searching for CSS gurus. Translations We start with a German and an English version. Obviously we’d like to offer other languages too. Please do not hesitate to contact me if you want to participate in this effort. And please . create a bug report if you find mistakes Accessibility But it is an area where we (the developers of vutuv) feel insecure. Please when ever you see a bug or have a better idea. We will invest time to solve those issues. Accessibility is a very important for me. create a bug report as a new issue in our Github repository The Team Being a single child I always talk about “I” but obviously vutuv is made by a team. The following developers create it together. Without them I would still sit in a traffic jam and theoretically think about architectures. Here they are in alphabetically order: Oliver Andrich (Germany) Chris Freeze (USA) Christian Frørup (Denmark) Kasper Tideman (Denmark) Max Mai (Germany) Lennex Zinyando (Zimbabwe) All great guys. All great developers. I’m thankful for their patience. I’m not an easy guy to work with. I want to take this oportunity to say thank you to José Valim for inventing Elixir and to Chris McCord for inventing the Phoenix Framework. I also want to thank the user Dogbert who answered probably a million of my Phoenix and Elixir questions. And I want to thank Ilya Grigorik who’s talks and book ( ) are eye opener for anybody interesting in WebPerformance. stackoverflow.com High Performance Browser Networking That’s it for today. I’d like to invite you to open a free account at and have a look for yourself. Please tell other people about it too. We need word of mouth. Thank you! https://www.vutuv.de Please send me feedback by email to stefan.wintermeyer@amooma.de https://twitter.com/wintermeyer
