As a request from the Italian forums I transcribed the first part of the AMA Jon has recently done. This is to help those who have bad skills on listening English. Also Jon speaks very fast and with a mixed accent which might be complicated for beginners.
This is just the first part, the second part will take longer as it's very complicated to do this.
For more information on the AMA read the blog post, the text follows below.
Narrator
Hi everyone,
A few weeks ago, we asked the Vivaldi community to submit their questions for our CEO and founder, Jon von Tetzchner.
We've got some answers for you.
In Magnolia we had a recent team meetup. We had Bruce Hamilton, some of you might know as Ayespy from the community, sit down with Jon, and ask your questions.
So, here's part 1 of that conversation.
Enjoy!
Bruce Hamilton
My name is Bruce Hamilton, I use to hang on as Ayespy on the Vivaldi community and Vivaldi blogs. I'm an internal tester, known in Vivaldi as a Soprano, and I'm a moderator on the forums.
And today I'm gonna be interviewing Jon von Tetzchner with regard to some of the questions that users have had for him that they can't ask him directly, so I'm going to ask them correctly on their behalf. We're gonna have a little chat.
Jon von Tetzchner
Good to be up here guys.
Bruce
Thank you.
Both Laugh
Getting right into it, first series of questions we have concern privacy and performance. And one user has asked "What is your process to choose strategic product features, I personally would love some improvement on speed for example as well as in privacy centred hackable features and fingerprint protection would be amazing for example.
Jon
It's a good question. And I think, in a way, I love how users think that everything is decided, everything is structured and everything is formal. And for us we know that isn't necessarily like that.
So there are certain things, I mean, we have group meetings where we are discussing where we are going and it is something that we decide as a team, kind of, where are we going and what feature we will be adding combined with the input from the community. I mean, we look at the list from the community and that clearly influences what we want to do.
But in addition to that someone can have an idea, and someone can actually just go and implement that and that's something that happens a bit more ad-hoc at times.
But generally, I mean, what our users want to us to do that’s what we want to do and that's where we are going and then we try to be with it on the way in and find out things that are, maybe, what no one has thought of that would be useful.
When it comes to things like speed that's an ongoing process. That's something that we work on a regular basis, based on the feedback from our users or if we see improvement potential so then we'll go in there and and take into it. It’s a fairly significant task that’s been ongoing. Pettern, in particular, has been spending a lot of time on that which is a significant upgrade on the backend which you may not notice. And broad number of users have been, kind of, saying “Ok, that’s a significant speed improvement on start-up” and that's an effect of the work that we’ve been doing there. That's an ongoing. Everyone is always looking at, “okay, this is something we can do on the speed” and if there is someone that reports something particular, “Ok, I have a thousand bookmarks and with that setting it goes slow” then we dig into that and will look into it. But we need specifics and people are reporting very different issues.
When it comes to privacy, we think it's really important that; we are evaluating, at all times, all the things there that we can do that will make people safer; a lot of it is about your safety online, about your privacy, tracking, and it’s like that.
Bruce
Yes, back to, a little bit, to just performance and Vivaldi’s strategy.
I imagine that you're forced to be somewhat flexible, somewhat nimble, about your development strategy, anyway, just because the developing is on top of chromium which is rather a moving target, they refactor their code, it seems, every 6 weeks.
Jon
Yes
Bruce
And… So you can’t predict exactly what your environment is gonna be so you can’t just say we are going to do this by this day, that by that day.
Jon
Well, I mean, it’s a complicated factor that we're kind of working on a moving target. Luckily we knew what we were getting ourselves into, but it's still a lot of work. We are working on Chromium and they do upgrades every six weeks and that means we decided we’d follow the same pattern; it's what makes the most sense. Every time they do an upgrade we have to combine their changes with our changes and unless we get our changes into their code we have to do it again, and again, and again, and again.
Bruce
Yes, and you're not just using vanilla chromium either you are making Vivaldi changes to the basic code.
Jon
We are making changes to the basic code. And part of that is, I mean, whether in speed improvement or security, or just, generally, integrating our own code in there. And, again, we're hoping that they will be taking change from us in the future; that's our goal because it will also make our life easier and hopefully we can then contribute more to that code base and that's what we'd like to do.
Bruce
In the best of all possible world.
Jon
Yes
Bruce
Our next question from a user, he says “I'm curious about Vivaldi's future plans for privacy, security tracking etcetera, and performance things that we are lacking in comparison to other browsers” and this is, sort of, a new subject. Will those things get higher development priority? There has been questions of your comment on the forums about how does Vivaldi's performance on opening or negotiating a certain thing compared to Chrome or Firefox or whatever and I understand that the unique architecture of Vivaldi is gonna affect that somewhat, but he’s asking here, pretty much, what sort of emphasis is that kind of performance gonna get?
Jon
If you look at the history of Vivaldi, if you look at, kind of, the first version that we sent out and you compare it to the last version, I mean, there's a lot of improvements when it comes to speed. Anyone that has been tracking us well this time will notice that there has been a lot of improvements and, I think, we’re growing in speed tests and the like, and we are doing pretty well. We're always looking at, okay, individuals are experiencing some issues in some setups and then we need to find out, “okay, what's their issue and deal with it”.
Now with regards to the rewrite that I mentioned that Pettern was doing, for example, I mean, that will help a lot of users and I think some of us actually don't really experience any speed issues. And what we are seeing is that people come from Chrome and they say “Hey, Vivaldi is a lot faster!”
So it’s basically dependant on your set up and how you're using the browser. But this continues to be a really important thing for us and I think anyone that's been following has been seeing that we're doing better and better and better.
Also dealing with complexities that the other browsers don't have, I mean, they don't make it easy for you to have a hundred tabs open, I mean, for us we have Sopranos that have 400 tabs open and our goal is to make Vivaldi work for that Soprano with 400 tabs open.
Bruce
And again, it inherits the multi-process format of Chromium is a complicating factor.
Jon
Obviously, given that we are working on top of Chromium we have to think about how do we work that in the best possible way and that's something that we deal with. And there are certain things we can do and there are certain things that it's more difficult. We try to do everything we can on our side. We are building the browser using web technologies, that also mean that as the browser technology becomes faster the browser user interface becomes faster, so there’s a benefit there.
And we are seeing that, I think it’s really good now that there’s a focus on speed in the browsers and I think that typically leads to improvements across the board for every player in the market.
Bruce
Right.
I know that early on part of the emphasis for Vivaldi was to try to work well on older, less capable, hardware. Is that still something of an emphasis or is it just something it would be nice to do if you could?
Jon
We want to support as old machines as possible but we are limited by the fact that we're running on top of Chromium. We want to be able to run on old hardware and run as well as possible, that's a goal for us and that's something we take serious.
Bruce
Okay.
Next is a, something of a repetitive question, but because it's asked a lot I'm going to go ahead and ask it again. And that is “Do you plan to maintain and enhance Vivaldi’s privacy features?”
Jon
Yeah, I mean, there's no question on that. I mean, we will focus on privacy and we are focusing on privacy. There are ideas and tasks that we're working on at this time. It probably, in some ways, our focus has been on other features to begin with, while at the same time, in some ways, our main privacy has been to not spy on our users and, I don't think, that’s something that you can take for granted. I mean, we do not collect information on our users and we don't want their informations and, I think, our business model is not related in any shape or form to the collection of data of our users. So, I think, already there we do have something special, our business is not about collecting data and then we take it from there and trying to keep people safe when going on. We've been thinking a lot about that and part of that has been also speaking out about regulation and the like. There are certain things we can do with the browser and there are certain things, that I think, are better done through regulation and I really think the level of tracking that we are seeing today needs to be regulated much stricter than it has been.
Bruce
Speaking of tracking, is it or is it not necessary, in order for Vivaldi's business model to work at all, to collect anonymous data, as to how many visits to certain sites have been made by Vivaldi users as opposed to some other browser user so that advertisers, or these kinds of things, can recompense Vivaldi for being the gateway that they received their traffic from?
Jon
No, we don't need to collect any data like that. I mean, the only thing that we do get information in about is how many users we have and what kind of platforms they are. So we want to know how many Mac users and Windows users and Linux users. That's kind of important to us, and where in the world they are. That's the level of information that we get up from our users and we don't want to have anything more. That's useful for us to know, that we can say that we have so many users but we don't want to look at what they're doing. There’s a big difference between counting how many users you have and actually saying “okay, we have some users doing this, this and this” we just don't want to know it and we don't need it for a business model.
Bruce
Okay.
This is a different way to ask one of the earlier questions about performance “What is your plan to reduce UI latency and sluggishness?” We have an additional program layer, it seems, in Vivaldi in the UI with the web technologies and the negotiation between that layer and the backend seems to consume some time possibly.
Jon
It is kind of interesting because, always, a lot of us are not really seeing any issues there but some people are talking about that. And this is where we go in and we take the reports that we get and then we dig into that to find out what the issue is. The issue isn't really the way we are writing it, that the fact we are writing things using HTML and CSS and JavaScript and the like. I mean, those technologies are widely used on web pages and they work really beautifully. So there's nothing there that's, I mean, it's just a question which language you're using.
Communication, like I said, that the works that Pettern did on the simplification that’s actually quite useful with regards to the communication between the underline browser code and our browser code. We reduced that complexity quite a lot and will continue to reduce that complexity. But overall my feeling is that if there’s something that is slow it's just a bug and we need to fix it. And we go through bugs one by one and if there are people that actually see problems they should report them and we will go through them and we will resolve any of their issues.
And sometimes it's really a question of you having certain set ups, you mentioned the slower computers. When we got Vivaldi running on the Raspberry Pi for example, I mean, it’s a platform with not a lot of power compared to most computers in use, but we used that as a great chance, also, to look at, “Okay, is there something we need to do to improve our code?” It is quite often a problem that developers, like ours, they're working on computers that are a lot more powerful than everyone else, the average users should we say, and from that perspective it's really important that we test on older computers and get reports from people on systems that we may not have thought about that, okay, if you have a really slow disk and you don't have a lot of memory there's certain things that become slower that we actually can control and then we would like to know about it so we can fix it.
Bruce
Very well. “Given the limitations and constraints of Chromium” – this is another user question – “Do you think it will be possible to, eventually, provide Vivaldi users with that Opera 12 browser experience?” and I assume the user here is asking about, sort of, the infinitely customizable and conformable interface that everybody so fell in love with at Opera.
Jon
Well, in concern to customizability we know that's one of the top items and clearly we’ve done a lot there, but we have a few steps left and we'll get there. I mean, we know that people want to be able to move buttons around and place things wherever they like and then share that with their friends, and that's on our target list and we will get there. There's nothing in the way that we works that would stop that from functioning, and the fact is, that because the user interface that we draw, that's our user interface, we can do whatever we want with that and obviously what we do with that is to provide end users with the way, with ways to do what they want to do. And that's the goal, right?
Bruce
Right. “Is there a technical impediment to not implementing userCSS and userJS in the same way as it had been implemented in Opera?”
Jon
In some ways I'm trying to understand the question here, what is different?...
Bruce
I do not understand it 100% myself.
Jon
Maybe he haven’t found a feature that we already did? We do have Page Actions in there, right? And currently the Page Actions, you can select them on a few page actions and going in editing, we haven't provided editing capabilities, you can go and edit the files directly on disk, and people do. We will provide ways to go and edit them later, so you should be able to do whatever you like in the same way, I mean, basically having your own stylesheets and JavaScript that work on the pages and, again, the page actions do that.
Bruce
Got it.
I think there was an actual file in opera called userCSS.
Jon
There was a file, explicitly a file for that. We're already doing modifications on the pages through Page Actions, we are also doing things with the relation to spatial navigation and the like. So it's just a question of providing the interfaces for users to do the necessary changes. But, I mean, clearly with the Page Actions you can do quite a lot and given that you can actually go and change them, you could do even more. And again, people are doing that but currently you have to go to the disc and find the file and do the editing and we will make that easy. So it’s mostly a discoverability with regards to the actual code.
Bruce
And perhaps having the changes in the CSS be persistent. I know that users are modifying common.css and creating a file called custom.css and referencing the custom CSS and then when it's updated all of that is wiped out and you have to reinstall your…
Jon
You're right, I mean, if you are editing one of those page actions files that we have and then we update you, unless you've taken backups there might be over with. So having a better system for that is clearly a good thing. But you can go in those page actions and you can turn them on and off individually so, they will stay on and off.
Bruce
Right.
Next user question “Are there any distant future plans or speculation about stripping Chromium parts to bare essentials or forking the engine entirely?”
Jon
By Opera we had a hundred people working on Presto.
Bruce
And that’s just on Presto, not on the entire browser.
Jon
Just on Presto, just on the core engine we had a hundred people, and in reality we needed more. But the reality, what does that mean, is that just to be able to maintain this piece of code you would need that many people and more. What the future will bring we don't know, but I think at this time looking at, in any shape or form, forking Chromium doesn't make a lot of sense. So it’s really more of a question of, kind of, working with the code. We don't want to be doing too many changes to the code unless we can get it upstream. Because if we do that, we will have to do it again and again and again and again.
Anything we do we try to, kind of, do a bit on the outside, so it's easier to maintain. And there's a lot of work that we go through trying to structure the code so our changes are easy to maintain.
All our changes are open by the way and we would be really happy if Google were to take those changes into Chromium, and some of those things do improve the code for them, some of them are more about us being able to do the change that we need to do. But if we are spending less time redoing our changes we can do more time actually just improving what it could.
Bruce
Exactly. With 100 developers on Presto you had 100% control of the code, no one ever came around every 6 weeks and changed it on you.
Jon
Yep, a number of them have been working on that code for years, so they would know how to do things. And that's a big difference, I mean, for us to get into the Chromium code is a significant a lot of work. I'm lucky we had people that already had some experience with this, some of them had work somewhat on the Chromium code, so they knew it. But, I mean, this is a massive piece of code, it's really complicated and working with it, so any changes and just to make sure that things don't break is a lot of work. But, again, you never know what the future will bring, but, I mean, the first focus now is to build a great browser on top of Chromium and then take it from there.
Bruce
Got it. One user wants to know whether you think that building the Vivaldi browser on the Chromium codebase is wise. They want to know if you think it's future-proof.
Jon
We felt it was the best choice that we could make. Building from scratch just wasn't an option, we knew how much works that was. Again, just maintaining that code with a hundred people in and getting a code base up to that level would have taken a really long time.
I mean, the reality: none of the big players have built their code from scratch.
Bruce
Not anymore.
Jon
Google got their code from Apple that got their code from KHTML, kind of the KDE project, right? Microsoft initially got their code from Mosaic. So everyone that's in there has gotten their code from previous projects. The fact with Opera, we were there from the very beginning, we had really smart people, for example my co-founder Geir who wrote the original core code, I was more on the UI side. So we had a really fantastic scalable code, but again starting now it would be really, really complex and there's a reason why Apple and Google chose someone’s else code instead of writing it from scratch.
So, the idea of forking is more likely than writing from scratch, but even forking is a significant and difficult task to take on, so. Now we could have chosen another code and when we were making this assessment the Chromium code is the most widely used, that's an important factor, we knew that the Mozilla code was going through significant rewrites, which you see the effects of it now.
Bruce
Exactly.
Jon
So jumping on a code base that you know is going to change under your feet, that's a really difficult thing to do and so we didn't want to do that. And obviously we could have gone straight with WebKit but that also didn't feel like, I mean, a safe solution. Of all the solutions we could have worked with, the feeling was that the safest solution at this time was to go with the crowd and go with Chromium. Again, I would have loved to do this from scratch but that was not an option, and, I mean, Presto was not an option, I mean, it wasn't available to us and if it had been available we would have had to get those hundred people that worked on it before and probably add another 50 people just to be able to get back on track inside a reasonable time frame.
Bruce
Right. “Does the Vivaldi team have any plans to publish or create some kind of API to make creating deep custom modifications easier for users?”
Jon
We definitely want to make it possible for people to do changes, and in some ways they already can and people are doing that. I mean, if you are talking about deep changes we know people are looking at our HTML and JavaScript code and making changes and posting updates on our community site. That as deep as you can get, right? What we would like to provide instead is a more easier way to do changes, just like we did have at Opera that you could actually just change some little files and put in your own graphic and change the order of buttons and things like, that doesn't require APIs. So thinking a way of providing a third level here is not necessary, you can...
Bruce
Like the old skin composer, this kind of thing.
Jon
Well, the skin composer... I'm thinking this to be a little bit different, then easier. So you would basically do your changes and then you would be able to export it, that’s something that I would like to see us to doing in the future that would make it really simple to do changes.
Bruce
Okay the next user question concerns the obvious relationships between Vivaldi and Opera, given that you were one of the original founders of Opera, says “Vivaldi has obvious links to Opera and its Community, not only do to your background, but a big part of its user base are Opera users that were looking for an alternative, especially the ones disappointed after the Presto engine was abandoned. How do you feel about Vivaldi being constantly associated and compared with Opera or people asking for features that they used to have in Opera, like it would be natural that they would show up in Vivaldi, do you feel this is a good thing for Vivaldi or would you prefer to have a more separated image?”
Jon
Obviously we built our image through, after a while, ourselves. But the reason why we're doing Vivaldi is, we had a very strong following at Opera, we had a lot of support, we had users that have been working with us and helping spread the word for a long time, they liked what we were doing, then Opera went in a different direction. And we felt that we owed them to provide with a good browser again. So in many ways, I mean, we have this slogan, we are building a browser for our friends, and that's our friends. So we're building a browser for those people and we take their input clearly and we want to provide them with everything that they want or features that they may have missed from Opera, but also, obviously, we want to innovate and come out with new things and improvements. We are not just building a replacement for what Opera used to be, but we're building on the philosophy of what we had at Opera which is about user-centric design. Listening to the users, giving what they want and that's what we will continue to do. But we love any kind of request and people are welcome. Obviously, from Opera users but also people that have been using other browsers.
Bruce
Very well. Question about email now, user says if they like to stop opening Opera 12.18 to manage their email but they won't be able to do that unless Vivaldi M3 can import existing emails contacts and account, is there any hope of getting rid of Opera 12.18 this year?
Jon
A number of us have been using M3, wish we also call it internally, for quite some time. I mean, it's a bumpy thing, obviously, given that we are still ironing out bugs and finishing the features but the reality is very much there. I've been using that as my default for, I don't know, half and a year, and it's getting better each and every day. And clearly the ideas that you are supposed to be able to move from other mail clients, whether that’s M2 or another one, to M3.
Now the simplest thing is if you, obviously, is just using IMAP and this is easy, you can get your mail from the servers and the like. So we have the IMAP and stuff like that working, the import functions need some work still, well, they need to be implemented.
Both laugh
But we are definitely getting there and the goal is to have all the functionality that you would expect and quite a lot more. And we already do, a lot of the workings of the mail client is in place but there are still improvements to be done.
Bruce
Do you expect to release with IMAP only at first and then later implement POP3? Or do you expect to be able to implement with both protocols?
Jon
I would prefer to have both in when we launch, but there's always discussions and decisions to be made and is kind of this fine line with how long do we wait. We do know that a lot of our users want POP3, so ideally speaking that's what we would have in there as well. We don't have that working in the current internal version, it’s only IMAP at this time, but at least POP is on our road map and we'll get in there. It will be in the first alpha version that remains to be seen. I do hope so.
Bruce
Okay, just a remark from other users “As soon as M3 appears I will switch completely over”.
Jon
Excellent!
Bruce
And again there is the question of “When do you plan to release the email function and what is current development status?”
Jon
I mean, the answer is always “when it's ready” and I think, in a way, a lot of the functionality is already in place. Lot of the basic functionality, those things are working, but there are bugs in the basic functionality which we need to iron out. I mean, there's less and less actual functionality that is missing, I guess one of the bigger ones would be POP. But a lot of the basic functionality is already in there and it's working nicely but we're still tweaking it and improving it and will continue to do so until we feel “Okay, we can put this out there”. We want to put out with a mail you would like to be really good when people start using, even in an early version. We know that losing your mail, and let things like that, is something you don't want to see happening. So we want to feel fairly comfortable with, even in an alpha version, that that is not going to happen. Given that we are still changing underline code to improve speed, to improve, basically details, of how the inner is working. We don't feel it's right to put it out there, we will probably... There’s a lot of people, I think, which would switch, just like me, already to this if they had it, but we feel there’s still, we want to take it a few steps further.
Bruce
A personal comment, of course I've been using the internal email by myself, I have taken note of the fact, over the last few months of using it, is a much more complex and comprehensive piece of software than you really realize when you're just reading your email, responding to emails, this kind of thing. You don't realize how many different aspects there are to just being able to manipulate email until you get an email client that works, but doesn't necessarily have a lot of those things and you go, I didn't realize that email really did this, but...
Jon
We are thinking differently with regards to how email should work. People are spending a lot of time with email, some are, I mean, there's some people that claim they don't do email, at the same time there's a lot of email accounts. And the feeling is that a better tool for email really matters, something that helps you do your work more efficiently and really that's what this is about. This is about helping you focus on the contents of the emails and not have to spend so much time on the structural side, like to still be able to get back to anything as quickly as possible. So that underline database structure, and the like, is really important for this and making sure that is all robust, that's kind of where our focus is. But I really feel from the usability perspective it's getting there.
Bruce
Okay.
We're receiving the question about the mobile version again we receive that a lot on the forums, I'll make this two separate questions. “How close are we to being able to test Vivaldi on a mobile platform?”
Jon
We have an early version running, I have Vivaldi running on my phone, but it is very limited compared to what we'd like to offer. And we are trying out some things and hopefully that will lead to a result soon but I think one of those days it will just, a lot of things will fall into place. But we are still not there.
Bruce
Right. Being able to run on a Raspberry Pi tells you something about the possibility of going mobile.
Jon
Also on the mobile side we want to think differently. We don't, just building a browser. A browser that is more powerful than what you normally finding on the mobile thing. Because a lot of us are spending significant time on our mobile. Yes, some of this is just casual but some of this is more work like or the way we actually feel that we could use some of the features that you find in desktop browser, in particular Vivaldi, but not in mobile browsers in general.
Going against the, kind of, trend which is just “Okay, simplify and...”.
Bruce
“It’s a tiny screen, it must be very, very simple”.
Jon
Yeah, but the reality is that it's not always a tiny screen. I mean, that's one of the things that has been happening, the screens of the mobile phones are getting bigger, the resolution of those screens may be higher than our PCS. Some of them are tablets, you can also put things on two screens using Chromecast and the like. And you could potentially connect a keyboard to your phone and the like. So then you’re really talking just about “okay, it’s a computer but it's a small thing and then you connect it whatever devices that you have available”. And I think, the way you would use things is very different in a setting where you might be sending the signal on top of a big screen and then you combine a Bluetooth keyboard or something like that. And our thinking is that we think about those use cases as well, it's not only about the use case where you have a simple browser on the phone to view pages which you then synchronize with – which is a very important part of this –, but also thinking about “okay, what if you're having a such a big screen”. I mean, there are actually Android devices with 20 inch screens.
Bruce
Yes.
“I still use Opera Mini because of its compression capability. Are you going to implement a mobile version with compression capabilities, no matter if it's a complete rendering from scratch or if it's in image compression tool or something else?”
Jon
We do have things on our list, not doing Opera Mini as Opera Mini was. I mean, there's a reason why Opera Mini by great extend is still running on Presto, from a code called D&M scalability side. But doing some kind of compression is something that would be doable, there's a lot of things that are on our list and we just have to get to them one by one. But being able to provide this kind of compression and the like, I mean, we do see the value of that if you're in, particularly, if you're on a slow connection, and the like. Obviously if you are on a 4G connection and it's actually working you may not feel the same need for this as it was with 2 & 3G. But there's a lot of us that are using 2 and 3G still and there's a lot of us that have lousy 4G. And for all those people there actually is a value in that functionality. But it does require us to set up server farms, there’s quite a lot of cost involved with this and clearly we are trying to do things on a rather low income stream in a bit. It will probably take a little bit longer based on that.
Bruce
I think it would help some users to understand as well where compression actually takes place. Whether it actually is a feature of the browser itself that could be somehow built into a local experience, or if it is a function that doesn't even happen on your desktop.
Jon
That happens on our servers. So that means basically you having a proxy, so we would have to have a proxy service that would then compress the data as necessary. And, I mean, that's a feasible service to provide, I mean, with Opera Mini it did a lot more than that which is why you would get these crazy compression rate of like 95% and the like. The compression rate you get with normal compression is probably more like, I've seen, 60, 70, 80% depending on the content, which is still valuable, but 95 was just crazy. Which is how Mini, in particular, was able to provide people with a way to get on the internet on terrible terrible networks.
Bruce
And when you say it happens on the server I think, realistically, is this something that happens on a server or a server farm?
Jon
This is a server farm and, typically, it would be a server farm that would require to be distributed. That we could put up a server farm on say, Iceland or something like that, but then depending on where you are on the world the connection might slow down so significantly that... I mean, our servers currently are in Iceland and we kind of like that. But if you're connecting to service in Japan going through Iceland is not the shortest route and you might actually experience that things would be slower. And that's what we saw with functionality like Turbo and even with Mini. Depending on where people were in the world, if they were being sent to the wrong server farms they would not see the experience that you would see if your correctly placed. It's related to the data that you are viewing and is related to where you are. So in some ways it's more important to be closer to the data that you're viewing because that's where your fetching most of the data and is more a compressed line to you using the browser. If that’s far away then the latency will hit you and the quality of the service will not be what you’d expect.
Bruce
Which would mean that, essentially, to really do compression right you need to build or lease server space, kind of, around the globe.
Jon
Basically yeah.
Obviously, someone will say “That's simple to do with setting up something like through Amazon and the like” and I say that's the simple way, but that's the expensive way. The reason why we were able to do this like with Opera Mini and provide this free service to everyone was the fact of the cost per user was so low. And the reason why it was so low was because we were doing this ourselves in a very efficient manner, and that really matters with this kind of solutions. When you are talking about solutions, I mean, with Opera Mini we may be handling billions of pages each day, and to handle that kind of volume you need to have really efficient servers and the cost was really important.
When we were deciding to do Opera Mini at Opera there was a big discussion on that, the CFO and the board, kind of, against providing a free service like that. I was very keen to do so and I got to decide. If the service had cost 10, 20 times more, which it would have been if we had hosted with third party providers it would have burned up our cash and, kind of, it wouldn't have worked.
Bruce
Right, understood.
Narrator
Thanks for listening!
Don't forget to tune into the second half of this conversation with Jón and be sure to visit vivaldi.com to get the latest version of the browser and check out our latest news.
Bye for now.