I thought the monetization was pretty obvious. I also mentioned it in the post. We're simply going to take care of your virtual machines (host them and make sure they always work) and give you awesome software to work with them!
But just another interesting web service that demands my card details before it will tell me how much anything costs! Fundamental mistake? I think so...
Thanks for pointing this out! Spoon seems to have found a nice niche in hosting up individual applications. StackVM right now is more about the entire operating system and geared towards hackers for the time being, but we may pivot into other areas. There are a lot of potential niches in this domain which is part of the reason why the problem is so exciting!
They poorly handle the OS requirements (both in terms of implementation and notification). I had to go into the FAQ to find this:
> Spoon currently supports Internet Explorer 6, 7, and 8, Firefox 3 and 3.5,
and Safari 2, 3, and 4, on the Windows platform. Support for the Chrome and Opera browsers is coming soon!
Which isn't even mentioned where you might expect - where they discuss the plug-in. If you go to any individual app in Linux (Chrome, FF3.5) you just get "this browser isn't supported".
you might want to rethink about plugins depending on your expected audience. People who are looking for good remote desktop solutions would be OK with installing plugins. I played the game on the front page on spoon.net and there was very little lag, it was a smooth experience. People who use remote desktop would prefer smooth experience over ease of installation.
We plan to offer some kind of rdesktop or vnc backend for powerusers, since our software hooks into these on the backend anyways. This is a useful point!
Completely disagree with this idea. If you can avoid browser plugins without major issue, and it seems you have been successful at that so far, by all means continue to do so. Not only will the technorati appreciate not having to install yet another piece of (usually unnecessary) software, but corporate customers will be more inclined to deploy in their environments if it means there won't be another piece of software for them to install and maintain across their entire enterprise.
curious: Did you ever have to access computers using a web interface remote desktop client? Very few of them are good and does the job. Anyone who wants to do something real would no doubt install the plugin. Also in the winXP demo there was obviously a lag between the real cursor and the cursor on VM. It might not seem annoying until you need to use it for an extended period of time.
I agree that they should avoid plugins if their app works fine on html & js, however, this is unlikely with the current html and js. (Think of playing games). Maybe with the improvements in HTML5 this might be achievable, but currently it's not.
1. This isn't a web-based remote desktop client.
2. Your concept of "something real" is clearly different from mine.
3. Their app appears to work very well, in my opinion, without having to resort to browser plugin messiness.
4. This particular solution's primary value proposition is that it will work on almost any recent browser, without other installed software.
Nice. I'd suggest demoing Windows XP before the Linux OS - not only is it more widely recognizable but there may be more users who have old desktop XP (or 98, etc) apps that could use your software.
I can see a few use-cases where this can be quite useful especially if easy to use.
To me the more interesting aspect of it is the - Complete open-source , idea-open and source-code open. For a startup looking for funding (applying to YC) , this is new, i wonder how it would gell with the investors.
Yeah, it is one of the big unknowns we are testing with this startup, but for us it makes a lot of sense. By being open about our technology, we hope to gain eyeballs, traction, and goodwill from fellow hackers who might be our future customers. By being open about our ideas, we expose them to criticism so that we can reform them to be more realistic and to exploit new opportunities that we hadn't considered.
Looks really impressive, congrats. I don't really see why it is called VM though, did you actually implement an emulator? How does this differ from online remote desktop solutions (say logmein)? Also if you want to reach beyond the geek community you might want to focus on a few of the ideas instead of the many ones that you currently have. For example, making the screencast great or making the demo of an application on a StackVM great. If you don't come up with a particular use case you might need to compete with giants like VMware or XEN.
We didn't implement an emulator but since we're bringing virtual machines to the web, we decided to add 'VM' to our title to give an idea that this is related to virtual machines.
Addressing your other questions, sure, we won't have like 100 features where we get lost ourselves. We'll have a small set of standard features and we'll have an API that will let developers hack on stackvm and make it do all other wonders.
I don't know much about logmein at this point but they are corporate company and we are awesome and enthusiastic hackers.
I was skeptical from the title. My first thought was "isn't this what EC2, and every other VPS provider does?" I have to admit, your pitch won me over - this looks interesting.
On second thought, you did say "web", not "internet". I'm so used to people treating the two as synonymous that I didn't make the distinction myself. So I'd say make that more clear.
Well, for most of the people "web" and "internet" are the same things.
I think there was a Google experiment where they asked what is the internet, and people would just say internet explorer, meaning web is their internet.
It's awesome to see a startup developing some genuinely new interesting tech rather than yet another project management or GTD app on $framework. Really neat stuff!
"... At the moment StackVM is in its 3rd major iteration already and is almost entirely built on node.js. Since we're doing everything open-source, we've written a bunch of reusable node.js modules: ..."
We haven't really looked yet into licensing stuff. We'll do that quite later when we get ready to start offering the service. For now we're just building the stuff up and not thinking too much about anything else.
That strikes me as dangerous - if MS Windows licenses then rule out what you're wanting to do you're up the creek without a paddle (perhaps you'll still ahve a spoon to paddle with, same system but only OSS VMs). If the licenses can be worked around then you're better building that I'd have thought.
I would recommend worrying about Windows licensing now. I worked for a company doing something quite similar for two years and I remember that Windows licensing is a bit of a sticky spot.
OK, didn't see that one. But technically it should be possible to do that(i.e., pure web rendering through JS) for TS as well.
What I meant to ask was - how does it compare using VNC against RDP. Probably you have through and rejected RDP, so was curious to know the technical details. (xrdp for Linux exists as well)
To be honest, we haven't looked at RDP yet. We're been building everything on top of VNC. We did not look because we didn't have the necessary libraries written like node-bufferlist (for easy binary protocol parsing) and dnode (for sending stuff around easily). But now that we have, we'll soon look into RDP.
The use cases are really interesting; online product demos will be a killer feature, and we wouldn't have to worry about piracy (we're able to monitor the piracy rates of our desktop app, and it's about 25% of our paid subscriptions)...
Wanted to reach out to you through email but was unable to find any contact information.
We'd like to work more closely with you on perfecting the online product demos feature. Would you be interested in testing it out on your website soon? Please contact me at peter@catonmat.net!
First, I have to say that this looks ambitious. There are some pretty exciting things in the gameplan; I am especially interested in the vmcasts idea. While I have to wonder if they can accomplish all of the ideas they lay out here, given the posts I've seen from catonmat.net before, I think they can do it. From what I can tell, Peteris is not just clever, but very motivated and loves to code and introspect his talents. This is usually a winning combination.
I am excited you decided to open everything, but I wonder if you're going to be able to raise the money necessary to fund the infrastructure. Do either of you have a lot of business experience? If you can seize your opportunities well enough, you can probably monetize your idea while letting others do what they will with the code.
We don't have any business experience but we hope to gather enough attention that by the time we launch everyone wants a copy of our software already. :)
I wouldn't be so positive about open-source everywhere. I'd recommend keeping some amount of the server-side closed source. The risk I see is that competitors can simply use your code and run the cheapest hardware they can find, while you have to run the cheapest hardware you can find and maintain and improve the software. Unless you have a different edge on the hardware side, you have no sustainable competitive advantage.
So I'd suggest you stick with the open API, and perhaps have an open reference implementation, but add value in a secret sauce on the server side which competitors can't simply copy.
And I would expect my comment to elicit their thinking. From the post, it seems a little pollyannaish, paraphrasing: open source for the hackers, charging money from the start for the business, everybody wins, yay!
On the other hand, perhaps their thinking on this is part of the secret sauce, and it's being kept secret for good reason.
Open Source could be an advantage for them if they change their license to the AGPLv3. With an AGPLv3 license, any competitors would be required to make their modifications available for download. But as the copyright holder, the OP would not have to release any source he didn't want to, giving him the flexibility to run private, closed source extensions/enhancements if he chooses.
Keeping in mind that he can't make use of any competitors' (or even friendly open source contributors') patches because they will be licensed under the AGPLv3 and not under his copyright.
I guess they could sign the copyright over to him, but I don't see another way around that. (IANAL)
You only have to sign it over if you want it in the official distribution, which I suppose most normal contributors do.
But if someone (competitor or not) forks and adds SuperAwesomeFeature (without signing the copyright over), pkrumins can't pull that into his and license it commercially. It'd have to only exist in his AGPLv3 version, which sounds like hell.
Any GPL-like license, yes. But people like to bring up the AGPL because it means "Muhahaha, if they ever run it as a service over the net it means they have to share their source!" as if it has any benefit to their commercial product.
This is an interesting thought exercise. I'm going to postulate that there is a benefit of the AGPL. Lets take a look at a company like JBoss, who may have benefited from the AGPL opposed to the LGPL they use.
A company who wanted to use their products for commercial use must provide a link somewhere on their page to the source, and share any mods. I think this is a big incentive to buy a commerical license from them, as it may look a little less than professional.
Assuming they don't though, and they publish their changes, there is still incentive for them to sign over the copywrite. If they want any backwards compatibility for updates and bug fixes (very important for a runtime platform), they need to. Its that or port everything back over.
No, he can't pull their changes into his commercial version, and he'd probably want to avoid pulling their changes into his AGPL version. But, the hypothetical forkers would also have to re-apply their patches to pkrumins version each time he comes out with an update, assuming they want to incorporate his changes. It's close to a level playing field, with what I'd say is a slight advantage for pkrumins. As opposed to the situation he's in with any other Open Source license.
The only danger for pkrumins is if the "forker" is able to make his new fork the more popular, more advanced fork. That doesn't happen very often, and really, when it comes down to it it's just a case of being out-competed, which is a danger every business faces.
IMHO, it comes down to whether pkrumins is going to gain more (in mindshare, in community contributions, etc.) by going open source, vs entirely closed source. If he's going open source, AGPLv3 lets him minimize the leverage his source releases would give to a direct competitor, with no likely reduction in his upsides (i.e., the previously mentioned increase in mindshare, the community contributions, etc).
That's of course hypothesizing that there are upsides for him in going Open Source. Clearly he seems to think there are.
FWIW I think saying "doing a startup" sounds pretty childish. Why not say that you're starting a company? "Doing a startup" sounds like you're just messing around with a concept, testing the waters. "Starting a company" makes you look more serious, like you know what you're doing. Just my opinion.
I think there is a certain sense of excitement and anticipation in the term. This is a new beginning and a start of a new life for these guys.
Frankly, I could care less how they reference what they are doing, or whether or not they put .ly on the end of their name! As long as they are doing something relevant and are having a good time doing it, more power to them.
Have you considered offering a customer self hosted option? It sounds like you could easily position it as a lightweight alternative to Citrix and Windows Terminal Services.
I was thinking some kind of supported version or support agreement. Lots of companies won't run anything internally that doesn't come with some kind of vendor support.
Excellent execution. I'd certainly be interested in the paid service when it comes out. The 100% opensource idea is probably a distraction you can do without at the moment. I want the paid service to be great. I won't care if it is opensource or not.
The 100% opensource is actually very motivating. We want to create new libs that everyone else can use, then the same people who use it contribute back and fix bugs for us. It's lovely.
And we can also reuse our libs later in more projects. Very awesome.
Cool stuff. The first thing I thought about was the latency. One of the problems running VNC or remote desktop over internet is always latency. I tried running VNC to EC2 instances for a test but the experience is terrible. It will be nice to see this run faster.
105 comments
[ 2.8 ms ] story [ 156 ms ] threadA question, though: how do you plan to monetize it? Without a business model, it's a web app, but not really a startup.
Doing this as a paid service from day one is definitely the right way to go. Again, good job.
> Spoon currently supports Internet Explorer 6, 7, and 8, Firefox 3 and 3.5, and Safari 2, 3, and 4, on the Windows platform. Support for the Chrome and Opera browsers is coming soon!
Which isn't even mentioned where you might expect - where they discuss the plug-in. If you go to any individual app in Linux (Chrome, FF3.5) you just get "this browser isn't supported".
I agree that they should avoid plugins if their app works fine on html & js, however, this is unlikely with the current html and js. (Think of playing games). Maybe with the improvements in HTML5 this might be achievable, but currently it's not.
1. This isn't a web-based remote desktop client. 2. Your concept of "something real" is clearly different from mine. 3. Their app appears to work very well, in my opinion, without having to resort to browser plugin messiness. 4. This particular solution's primary value proposition is that it will work on almost any recent browser, without other installed software.
To me the more interesting aspect of it is the - Complete open-source , idea-open and source-code open. For a startup looking for funding (applying to YC) , this is new, i wonder how it would gell with the investors.
We didn't implement an emulator but since we're bringing virtual machines to the web, we decided to add 'VM' to our title to give an idea that this is related to virtual machines.
Addressing your other questions, sure, we won't have like 100 features where we get lost ourselves. We'll have a small set of standard features and we'll have an API that will let developers hack on stackvm and make it do all other wonders.
I don't know much about logmein at this point but they are corporate company and we are awesome and enthusiastic hackers.
http://code.google.com/p/fabulatr/
On second thought, you did say "web", not "internet". I'm so used to people treating the two as synonymous that I didn't make the distinction myself. So I'd say make that more clear.
I think there was a Google experiment where they asked what is the internet, and people would just say internet explorer, meaning web is their internet.
Assuming that you will have reasonable pricing and a fast connection, I would be very interested in using this service for my own startup.
I couldn't find your contact information so I am replying here. Can you reach me at peter@catonmat.net?
I'd like to know more about how you'd use stackvm at your startup, so that when we launch stackvm we already had a usable product!
Peteris
Keep up the good work!
The very best of luck with your YC application.
A similar project you may get inspiration from:
http://lifehacker.com/5590935/phpvirtualbox-manages-your-vir...
Most significant bit, many thx.
Best of luck with this.
If you are going to support Windows, how does stackvm compare against "Terminal Services Web Access (TS Web Access)" [1]
[1] http://technet.microsoft.com/en-us/library/cc771908(WS.10).a...
"You must install TS Web Access on a computer that is running Windows Server 2008."
With stackvm you don't have to install anything, no plugins, not even flash and you don't need a modern web browser.
We're making our software work in all the browsers, even as old IE as 5.5.
What I meant to ask was - how does it compare using VNC against RDP. Probably you have through and rejected RDP, so was curious to know the technical details. (xrdp for Linux exists as well)
Wanted to reach out to you through email but was unable to find any contact information.
We'd like to work more closely with you on perfecting the online product demos feature. Would you be interested in testing it out on your website soon? Please contact me at peter@catonmat.net!
Peteris
I am excited you decided to open everything, but I wonder if you're going to be able to raise the money necessary to fund the infrastructure. Do either of you have a lot of business experience? If you can seize your opportunities well enough, you can probably monetize your idea while letting others do what they will with the code.
Looking forward to see how this evolves.
I'm so disappointed you didn't open the XP VM inside XP's Chrome!
What happens when you open a VM inside a VM?
You get an awesome feedback/recursion effect!
I'll try to do a video about it in a few hours and post it here. :D
Also posted it to HN: http://news.ycombinator.com/item?id=1536011
So I'd suggest you stick with the open API, and perhaps have an open reference implementation, but add value in a secret sauce on the server side which competitors can't simply copy.
On the other hand, perhaps their thinking on this is part of the secret sauce, and it's being kept secret for good reason.
Linode already has an in-browser interface to Lish, and I don't think Lish would work over VNC anyway, since it seems to operate on a lower level.
I guess they could sign the copyright over to him, but I don't see another way around that. (IANAL)
But if someone (competitor or not) forks and adds SuperAwesomeFeature (without signing the copyright over), pkrumins can't pull that into his and license it commercially. It'd have to only exist in his AGPLv3 version, which sounds like hell.
A company who wanted to use their products for commercial use must provide a link somewhere on their page to the source, and share any mods. I think this is a big incentive to buy a commerical license from them, as it may look a little less than professional.
Assuming they don't though, and they publish their changes, there is still incentive for them to sign over the copywrite. If they want any backwards compatibility for updates and bug fixes (very important for a runtime platform), they need to. Its that or port everything back over.
The only danger for pkrumins is if the "forker" is able to make his new fork the more popular, more advanced fork. That doesn't happen very often, and really, when it comes down to it it's just a case of being out-competed, which is a danger every business faces.
IMHO, it comes down to whether pkrumins is going to gain more (in mindshare, in community contributions, etc.) by going open source, vs entirely closed source. If he's going open source, AGPLv3 lets him minimize the leverage his source releases would give to a direct competitor, with no likely reduction in his upsides (i.e., the previously mentioned increase in mindshare, the community contributions, etc).
That's of course hypothesizing that there are upsides for him in going Open Source. Clearly he seems to think there are.
Frankly, I could care less how they reference what they are doing, or whether or not they put .ly on the end of their name! As long as they are doing something relevant and are having a good time doing it, more power to them.
this might be exactly the best way to start something like this.
And we can also reuse our libs later in more projects. Very awesome.