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.
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.
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.
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.
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.
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.
When I read your headline, I was excited to think that someone was building a VM service that was tailored to hosting webapps. I wish there was a service with a UI & API for configuring sites and starting up VMs to serve different areas of the site. For example, I could set up mysite.com on this service and then have requests for mysite.com/blog proxied to a VM running WordPress on PHP/MySQL. Requests for mysite.com/manage would be proxied to CherryPy stack running on another VM. Other requests for mysite.com/* would be served out of an S3 bucket. And of course the hosting service would do logging, monitoring, automatic error recovery, automatic scaling, backups, etc.
You two are doing something different with StackVM, and it looks cool. I currently use FreeNX on EC2 and the NoMachine Windows client. Here are a couple of feature suggestions:
1. StackVM would be much more useful to me if the windows could pop out of the browser. I don't want to use a remote-desktop client that is confined to a browser window.
2. For real productivity, cut & paste must work between StackVM windows and other native apps.
3. Get James or someone with a lighter accent to do the demo video voiceovers.
4. Make it easy to deploy test environments, execute integration tests, and capture the results. For testing webapps, make it work with Selenium and keep videos of tests that fail. I would pay for this if it was sufficiently developed.
I'm looking forward to the private demo. Good luck, you two! :)
1. That is awesome, I have added it to our wiki. This is easily doable and we'll probably implement it.
2. We haven't yet looked into implementing cut&paste. Should be doable.
3. James will join me in the next videos.
4. We're definitely building a test environment. We couldn't do it earlier because we didn't have a good remote method call execution framework, but now James wrote dnode [1] and we can get to implementing it!
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.
"... 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: ..."
Based on the confusion that others and I had, I suggest changing your name and dropping VM from it. It really doesn't convey what you are trying to accomplish. When I first heard it, I thought you were making a VM together with an OS with an eccentric stack allocation algorithm or sth.
Personally I think that the chaps should focus on making the product even better instead of branding - the name can obviously change later when they decide to push for market release and by then they probably would be clever enough to seek the wisdom of someone to help them there.
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 would use it instead of always have to re-download putty when I'm not on a linux box.
For the money part, you might also consider setting up the domain and redirect for a small fee. For instance, my-name.com could be my VMs securised with a password.
Also, what is the limit of GB I can put on the VM? Say I want to upload files and mp3s.. is there a limit? May I pay to increase it?
Finally, I would like to be able to connect to my VM from other way than web. Say I'm on my linux box with my terminal prompt, it would be nice if I could just ssh to my-name.com and get my VM.. upload/download stuff with scp, and connect to it with FTP. But of course, this would work more with the linux part I suppose :p
Anyhow, congrats also for the "I started my startup" which is, in my opinion, amongst the hardest part (starting!).
We still have to figure out the licensing. We're currently more busy with hacking our software than thinking about licensing. So I don't have an answer for your questions.
A small feedback about the site. The email signup UI is the coolest I have seen. However, I would like the string "you@example.com" to be retained when I click in the text box and then click outside. Currently, it disappears when out of focus after clicking inside the text box once.
Thanks for pointing out the right term. However, the site does not use HTML5 placeholder and instead rely on plain JS to do the trick. What I wished for was a behavior like in the demo here: http://diveintohtml5.org/examples/input-placeholder.html
I'd just use placeholder, and screw anyone using an old browser. If people can upgrade their cell phones every year, they can install a modern browser. ;)
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 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!
I think the most interesting aspect of this is that you have implemented a VNC client in JavaScript and HTML. That realy is your core technology and probably has the most value. I could see that being realy useful for implementing things like 3d CAD in the browser, the interface and controls could be plain HTML/CSS and use your vnc technology to show the 3d graphics being drawn on the server.
Could you offer some insight into how your JavaScript vnc works?
I'll soon start doing in-depth blogposts with examples on how stackvm works.
But a quick summary is that we have node-rfb collect VNC updates, push them to node-png or node-jpeg which merges the updates and creates an image that then gets pushed via dnode to browser, which then draws it at the right location (absolute positioning of images).
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. Is it only a matter of time before someone implements hardware virtualization in pure Javascript? Perhaps FireFox 10 will open machine instances as a supported MIME type.
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.
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.
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!
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!
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...
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.
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.
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.
This is awesome. Our company also does virtual appliances through different operating systems. It'd be nice to learn more. We also use the virtual appliances for exchange, saas, NFS, and web servers.
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.
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!
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.
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.
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.