Question is what form will those tools take. I wouldn't be too surprised if the OS just became a ginormous browser that could talk directly to hardware like the graphics card and a huge cache for storing "installed" web apps.
Kind of the same thing that we see in web sign-up forms where for every extra piece of information you ask, a huge number of potential users drop off.
I just can't help but think that for webapps to get fundamentally richer, they are going to need increasing access to client resources, such as the ability to communicate with each other across process boundaries. At that point, security concerns will probably dictate a somewhat more formal installation process for them as well.
Let's say I had a company that wanted to compete with your company -- how do you prevent me from making a different GUI for your software and aggressively marketing my version, perhaps with in-house developed features that aren't open source? Is this difficult/undesirable to prevent?
If you wanted to compete with him on this ground (trust and security), you'd need to be a good security hacker too and obviously you wouldn't need to copy his code because you could write it yourself.
However, if I've done my job properly, I'll fail -- because the first design principle behind tarsnap is that nobody will be able to steal your data, even if they force me to cooperate with them.
Open Source is great, but after spending a year working on this I don't want end up competing with someone else who is using my code.
We're not worried at all about people taking our code and using it to build proprietary products. In fact, we are going to encourage people to do exactly that because, as far as we can see, other companies having a vested interest in our platform is pretty much a win-win situation for everybody.
Of course as a business, we have revenue generating activities with the platform planned for ourselves, but it really seems unlikely that another company would choose to compete head on with us about that. We wrote the platform after all, so there are many different ways we could rain on their parade if they decide to use our software in an antagonistic way.
But yes, they could then pick up that development on their own by forking the platform from an older version.
The most important way that we could 'rain on their parade' though is just by being way better than them at creating applications based on the platform since we will always understand the internals better than anybody else.
We only want to reserve a small number of commercial opportunities for ourselves out of a large number of possibilities. Cooperating with us to develop one of those other possible product ideas is going to seem a lot more attractive than competing directly with us.
Please don't worry at all about challenging our ideas about this stuff. We are trying to understand the same things you are and our open source business strategy is largely theoretical at this point.
Why not doing it in the first place, then?
> The most important way that we could 'rain on their parade' though is just by being way better than them at creating applications based on the platform since we will always understand the internals better than anybody else.
If the internals are not well-designed and not well-documented, yes. In that case, once again, why bother releasing the source code?
We don't want to do it at all and probably never would. I'm only mentioning it as something that somebody evaluating risks from the other side might imagine that we could do.
> If the internals are not well-designed and not well-documented, yes. In that case, once again, why bother releasing the source code?
No, we're not going to deliberately obfuscate anything because that would be against our goals of encouraging as many people as possible to adopt our platform.
I think it's not really necessary to create artificial obstacles for us to have an important advantage. Very large systems take time and experience to understand even when they are both well designed and well documented.
Linus and Alan Cox have an advantage over newcomers at extending the Linux kernel, right? Hypothetically, if Linus, Alan, and say Rusty Russell got together and created a startup to implement a Linux kernel based idea, would it make sense to compete against them on exactly that idea?
Bill Gates, is that you?
[edit]
I'm pursuing the idea that a programer can do art with his programming (and his programs), and actually be good art, not just "look what i did with some code because I'm cool and can write some lines of code just like that" kind of crappy art, but something that a regular person listens, and say, "wow, thats sounds great", without explaining them first how the piece was made and trying to win some points with that explanation.
I know that if the music doesn't sound good then i have to get better at it, else I'm just fooling myself ... pretty much in the same way you just can't make a web app and say "i code it myself!", and then expect it to be a success.
[/edit]
I think the hardest thing is to actually get a good sounding thing (synth, efx, etc).
Is very exciting, to be a programmer and a "music maker", to be able to come up with crazy ideas for music instruments and then actually build them. Just wanting to know how will they sound is a very strong motivation.
You can listen to some of what i've been doing (music tracks) if you are that curious:
Most of it its done with my software, i just use audiohijack and logic to masterize - add "punch" - and to do some edits - cut the bad parts, put together the good parts.
The track called "Setup Seeker" is an exception, there i only used a sequencer and a midi controller I made, but the sound actually comes from commercial software.
I realize its not really good, I'm working on getting better at it ;)
Some one else doing music apps here?
it would be nice though, but the thing is that since right now im making apps for my own, this apps are very "hermit" apps, they work for me, but for others they would be very clumsy, unintuitive, buggy, pain in the ass apps ;)
but when i do i'll let you know ;)
i do use mac, by the way, these apps are build using cocoa
hey, do you have some of your music online?
music link: wooleyandswift.com - i'll hit you up on myspace too.
I know everyone here is game-set-match convinced that web apps are it and that's that. I think that apps involving LOADS of data like youtube, facebook or (my absolute favorite) fuzzwich belong on the web. But I'm really not that into the notion of replacing previously desktop based apps w/ web apps.
I've said this before, but it feels like a camping trip. You can survive, just not comfortably. I used fauxto the other day to edit some images and it was great. But it was only really great b/c it was free and b/c it was there when I needed it. But... I picked on tool to suck a color from one place and put it in another. I was confused for a long time b/c I was so used to the mouse pointer changing to represent eye dropper thing but it was still the arrow. Maybe they're new, and maybe this can be done through a browser but it brought home the feeling that I was on a camping trip carving meat with a swiss army knife. Take gmail, amazing interface, amazing search but how do I sync the contacts w/ my iPhone? I'm sure there is a 3rd party app that does it but you'll still use the desktop crutch.
I think that the tendancy toward web apps is more of a move away from microsoft than toward something better. But ironically you actually don't avoid the x-platform problem b/c browsers are all different.
The thing that's great about web apps is that you get:
1) automatic updates.
2) no install.
3) works from any machine.
4) access to reams of data.
5) collaberation.
But:
1) no iPod.
2) no graphics card.
3) no digital camera.
4) no phone.
5) no clipboard for anything but text.
6) if I want to email my image from fauxto or flickr to someone via gmail I have to download them it upload it. (Nobody ever mentions this elephant in the web 2.0 living room. How do you get data from one web app to another? An un-started startup perhaps?)
7) Half ass interfaces. I really give props to the fauxto guys for pushing the limits but only half ass users like me will ever see it as a worthy replacement for photoshop.
8) No OS integration. I like how Address Book, iPhoto and iCal can talk to Mail.app.
The tack we're taking is having the desktop richness along w/ a web component that allows publishing and sharing of data as well as intrinsic backups. A user can log in from another machine (w/ our app installed) and see all of his data as if he was on his own box. He can also access loads of data that other users have generated and made public. We use Qt for easy x-platform w/ native feel. We don't touch the registry. Users don't even need to be admin to install. The only thing we don't get is auto-updates. But we're taking the firefox tack and having them download in the background and install on the next app boot.
Much of my direction was inspired by a number of Steve Jobs speeches. Once my phone is a computer, when am I gonna need "my apps" on another person's computer? I'll never touch another person's computer. Thus partially negating the need for web apps.
Re: But 6) and 8): at the current stage there hasn't been a lot of interaction between web apps. There isn't a reason why this can't happen. I'm not sure about images in gmail (why not send a link?) but applications like fauxto can get your images from links. All these i-products are made by one company, a web company can make its programs just as intertwined. As a parallel to your example I think a fair number of web applications work with google calendar.
Re: But 1-4: If your company wants to work at the stage people get data off their devices then a web startup makes no sense. Once they've done that though - the first things they want to do is share it. Thats why the internet is huge, there are other people on it.
what are you describing as a desktop app?
-you can always create a plugin.
2) no graphics card. -there are a number of 3d accelerated plugins out there -http://www.papervision3d.org/
3) no digital camera. -i think flash connects to your digital camera
4) no phone. - flash and voip are being used together
5) no clipboard for anything but text. - link to a web copy of it
6) if I want to email my image from fauxto or flickr to someone via gmail I have to download them it upload it. (Nobody ever mentions this elephant in the web 2.0 living room. How do you get data from one web app to another? An un-started startup perhaps?) - we are using a combination of flash, javascript, and web proxies
7) Half ass interfaces. I really give props to the fauxto guys for pushing the limits but only half ass users like me will ever see it as a worthy replacement for photoshop. -its hard but the pay off is huge because of the reasons you listed above for a web app.
8) No OS integration. I like how Address Book, iPhoto and iCal can talk to Mail.app. that can all work together between web apps.
2) I've heard of papervision. But see #1. I also went to their site and I couldn't get past the landing page in safari. I'll try it in FFX later but I just would have lost every mac user who tried to install someone else's plugin.
3) If flash connects to your digi camera then it can probably connect to an iPod or any other USB device. If that's the case you've got me, I didn't know that.
4) I didn't mean voip I meant phone as a device to sync contacts. But if, like you said, flash talks to USB then you've got me here.
5) I used a bad example. What if I want to edit a song in a web-based mp3 editor and bring it back to anywhere.fm. Unless each web app has access to the other you can't do that w/o a download and an upload. The file system is neutral territory on the desktop. It's the place every app understands. There is no web file system that every web app can access yet. (I actually think that would make a mean startup though.) Even if you're using a combo of flash, js and proxies, you still have to have an interface to the other web-app. Is there a common web-app to web-app interface that the industry has decided on?
7) You're right it is hard. And I really do commend the people who have taken it so far. But most of your answers remind me of the people I see camping who have solar showers, fold out chairs and a battery powered TV. I look at them and say, "why not just go home?" There are a million hacks that get the job done but each one waters down functionality and increases complexity. Almost every answer you've given involves non-browser SW on the desktop. So we're both straddling the desktop and web-based world. We just don't agree where the balance point lies. I think that in most cases existing desktop apps should be connected to web-services that facilitate backups, sharing and collaberation. You tip further toward the web end. I'm sure there is a time and place for both.
The main issue, I think, is privacy and authentication. The only reason I can't have gmail directly slurp my images from facebook is that Google isn't on my friend's list. Though the last time I tried to upload an image with facebook, the interface didn't let me use a hyperlink. That's not a limitation of the internet, that's just a sucky interface.
So the issue does get talked about, just not in those terms specifically.
The whole thing's a financial application written in Smalltalk, interfacing to pricing libraries written in C, with the same type of image working as both the desktop client and distributed compute node.
The Seaside web development framework (http://www.seaside.st) has attracted a lot of attention and there's a drive to push as much reporting through there as possible, but the day-to-day book and portfolio management looks to be desktop software for at least some years to come.
However, I love good Internet-enabled desktop applications, not the Visual Basic crap that wannabes did before.
I hate that flash 'apps' never have proper scrolling. No mouse wheel support, non standard behaviour, etc, etc.
And I hate that flash 'apps' can't use the right mouse button. See Portal flash version for the stupidity of it.
And most of it: I hate that a single stupid RIA eats all my CPU cycles in what a desktop application would not even use a 1% of it. Ugly flash video included (I see my Internet videos in stage6, thanks).
Nothing wrong with 'em. Depends on what you want to do, where the market is, and how your business model is going to work.
People are infatuated with the web: it's easy, it's universal, it's cheap. But everything has good things and bad things, and I could see the case for certain types of software being on the desktop. The way to make money is to make the user happy, not follow the herd. :)
When you develop embedded software you can choose between a grab-bag of tools (using open source tools like the GNU toolchain; very configurable but rather complicated) or an IDE.
It's interesting to have both because, usually the learning cycle is the following: you generally start by using IDEs (when you're at school), then when you start working you like to configure the complete toolchain to learn how everything works and finally, after some time, you're getting really tired of having to do all this stuff manually so you start using IDEs, libraries and the like.
That's why I don't understand the idea behind toolkits that let you write desktop apps using web technologies; it seems like you get the worst of both worlds!
Using HTML + JS + CSS + Flash to develop desktop stuff is a PITA.
I myself work in the game dev industry, currently providing services of game dev, and it's not for the web but for heavy desktops.