Does any code which people download and run locally count? I'm building an online backup utility -- but I'm planning on giving the code away for free and charging for the storage space, so it's not a "pure" desktop application like a word processor.
I'm curious how you plan on implementing your open source/free business model. Are you going to use a BSD license? GPL 2 or 3?
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 I were him, my main selling point would be trust. That is, I would trust him much more with my data than any random guy who copied his code (because he really knows computer security and cryptography and because he has some credentials, too: he's FreeBSD security officer).
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.
Trust my ability, not my morality. I'm just as vulnerable to court orders, extortion, and corrupt datacentre technicians as the next guy, so you shouldn't be trusting that I'll never try to steal your data. If someone puts a gun to my head, OF COURSE I'll try to steal your data.
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.
I said that the code was going to be free, not that it was going to be freely licensed. Users will be able to see the source code, but it will be "look, but don't touch" license.
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.
I'm going to answer this too because we are in the situation you are describing. We are writing a platform that we intend to release under a liberal no-strings-attached free software license (ie: not GPL).
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.
In which ways could you 'rain on their parade'? stop supporting your software? change the license? They could just hire talented coders to use and update your base from the last point that you did update, or the last point that you had that license. Right? I'm not trying to antagonize you, just trying to understand the legalities of the open-source side of capitalism.
We could relicense components that they need under a less business friendly license so that they could not take advantage of future improvements to the platform.
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.
> We could relicense components that they need under a less business friendly license so that they could not take advantage of future improvements to the platform.
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?
It would make sense: while they would spend their time debugging and fine tuning their beloved baby of a kernel you would just use their work and add value on top of it.
> 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.
How are you planning to scale better than amazon s3 in terms of cost? If someone were to build an open source thin layer storage/backup client on top of s3 you would effectively be dead.
I'm not planning to compete with S3 on cost. I'm planning to compete with S3 on features -- an encrypted snapshotted backup system is vastly better than one which just copies files onto S3.
Nothing except code. Taking second snapshot and only storing the differences is a bit harder. Deleting the first snapshot while leaving the second snapshot intact is even harder.
Yes but as a day job. I can't say enough bad things about desktop software. I like the platform a web browser provides rather than seeing it as a disadvantage.
I know neither desktop programming nor web programming (I do embedded stuff) but as I see it, web apps require an awful mess of ad-hoc technologies (XHTML, CSS, Javascript, some server-side language and framework, SQL, a webserver, etc.) whereas there are powerful, well-designed tools to easily develop desktop software (Visual Studio, Delphi, Python + Qt or wxWidgets, etc.)
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!
I guess thats why I prefer web development, powerful well-designed solve every problem tools just aren't and don't. Qt's the best of that lot and its not that great. I'd much rather different tools doing different things.
You're right. The good solution would be to be able to create network-enabled distributed applications with standard GUI using normal and sane languages and widget toolkits, or even better a very high level language.
Using HTML + JS + CSS + Flash to develop desktop stuff is a PITA.
I seem to be one of the sole dinosaurs of this group. I am building desktop SW. It is a 3d visualization tool heavy on OpenGL. It can't be done on the web the way we want it w/o a java applet (which I think is a terrible alternative.)
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.
You can't do good 3d in a web browser at the moment thats a definite.
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.
Good 3D in the browser should be coming soon. Look up Quake Zero -- a browser version of Quake 3 -- still years behind what we can do on the desktop now, but not that far.
1) no iPod.
-hardware and drivers are a tough science, have you done them, have you certified them? last.fm has a small app that scrobbles, which is a far cry from a desktop app.
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.
1) I personally think installing plugins can be more confusing than installing apps. Inexperienced users see, "please install our plugin," and the lump sum of everything they don't know about computers falls on their head like a cartoon piano and they hit the back button. "What's a plugin? Where do I put it? How will I know it worked?" Before flash video became huge the number one question I got from non-tech friends was, "why doesn't this video work in my browser?" I believe that a plugin that isn't as ubiquitous as flash is almost useless.
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.
Re: iPhone and GMail - There's no fundamental reason your iPhone couldn't sync with GMail. GMail imports and exports contact using CSV. Download / upload the CSV via Safari, and if your iPhone could parse the CSV, you're good. In fact, someone should write an iPhone app to do just that.
Yeah, but what about syncing? I am ALWAYS adding a contact to my phone then another to my email, then I'm syncing them. I can't just wipe everything out on one end w/a csv upload. Really this is something I believe should happen invisibly.
I agree that many desktop apps can't be entirely replaced by web-based equivalents. However, if a webapp can provide 80% of the features of a similar desktop app but with a much lower barrier to entry (nothing to install, cross-platform) and additional web-oriented features (collaboration, publishing, Facebook intergration, etc), this webapp can potentially capture a large market share. Google Docs is a good example -- it will never do everything that MS Office can do but it's easy to use and it's certainly good enough for many users. Desktop apps still occupy a niche, but the Web has made this niche much smaller than it used to be.
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?)
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.
Im making music apps, to make my own music ... im still not really good though.
[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 ;)
do you have any programs to try out? I make music on the mac and I am always on the look out for cool/new weird synths. etc, let me know if you need a beta tester. :) nice tunes.
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
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. :)
You know, eventually the line between the desktop and the web is simply going to disappear. Web apps will cache more data on the user's hard-drive and run more code on the user's CPU. Meanwhile, desktop apps will store/backup more data online and offload more computation to servers (or maybe other desktops). There's huge potential for libraries or tools that make developing half-desktop / half-web apps easier.
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.
I wonder if it's that you have to install anything, or if it's just a "click cost" -- for every extra click you ask of the user, you lose potential customers?
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.
Click + wait, probably. Java applets give you the ability to do nearly everything without installing software, but never caught on because the JVM takes so damn long to start. Flash has been somewhat more successful because it loads faster, and AJAX even moreso because there's virtually no up-front cost if you do it right.
Isn't it more a question of how much of your computer you are willing to expose without explicitly authorizing it? As long as webapps don't demand much, you let them bypass explicit installation. Even Gmail 'installs' something to run locally according to some broad interpretation of the term. The difference between that and signed oneClick type installs with auto update from a trusted source is pretty slim.
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.
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).
Yes, as long as 'building' includes 'extending and maintaining an application that's been in service for 12 years'.
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.
51 comments
[ 7.2 ms ] story [ 132 ms ] threadLet'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?
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 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.
http://unity3d.com/
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.
[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:
http://myspace.com/rugoso
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.
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. :)
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.
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).
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.
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.