The commercial implications of the GPL actually resemble a drunken menage a trois between thought experiment, a Rube Goldberg machine, and Pulp Fiction's explanation of Amsterdam's marijuana laws.
How could a UI disaster that informs a user who has problems logging in that "you must be logged in to do that?" and that lacks any kind of official published API possibly win?
You do have a point about taxes and other expenses.
But considering that an experienced Cocoa developer can easily build a high-quality app in a single afternoon (Cocoa is not C++ or Java), and that Apple will be handling distribution and hosting, and that the store will most likely have some kind of rating system that will developers leverage word-of-mouth, doing iPhone applications should still be lucrative for experienced mac devs who are good at crafting good user experiences.
There's seems to be this pervasive myth in the Open Source community that "just because code is open means that it's easily modifiable and understandable" and that all you have to do is "just read the source".
If you have a project with millions of lines of code, a zillion layers of abstraction (many of which do not have clear boundaries with respect to one another other), sparse comments, lots of complex stuff going, and more than a few code cowboys who tried to prove just how clever they were (to the detriment of code understandability), it's going to take you years "just reading the source" without any help at all to get to the point where you can make reliable and effective changes to the project.
It makes far more sense to ask a project's "Lore Master" to guide you to certain entry points where you need to make a few specific changes than to spend years "just reading the code" to become a "Lore Master" yourself to make those few changes.
To hell with ideology. Two completely different user environments, one running on top of another and ultimately requiring someone at some level to be an expert in both, is bad design and asking for trouble.
"So that nobody can ever improve the software for the purposes of selling the improved codebase as a product sold exclusively by their company."
Of course, the GNU statement "You can sell GPL'ed software" really should be reworded "You can sell GPL'ed software provided you don't use exclusive codebases as a business model and instead use other methods of product differentiation like branding and support".
Both Microsoft and GNU tend to shorten things in the interest of catchiness and propaganda.
More importantly, there's no Physical Law Of The Universe stating that just because you gave up your home life you'll be spared from layoffs or outsourcing.
If you put everything into your job and you lose it, your sacrifice will be meaningless. You will have missed babies' first steps, kindergarten plays, and sunday afternoon strolls and you won't really have anything to show for it.
In my experience, a tech job will probably not teach you programming; that's really more the job of your hobby projects and the ensuing battlescars you get from them. It's the stuff you can't get credit for in your classes (that might drop your GPA) that you'll probably never be able to put on a resume and have taken serious, which will develop your skills.
However, a tech job will teach you the politics of IT and software development. You'll learn about how to balance competing interests, how to accept the business doing things in the least efficient, least-technically adept way, and how to subtley sneak in better ways of doing those things under the radar.
It will definitely get you used to end users interacting with your software and learning how to cope with their complaints, feature requests, and the politics about adding features (e.g. if I add feature X, are they then going to ask for feature Y, which will be totally undoable with the current API?).
One reason why you really don't have a plethora of good Open Source GUI apps for PostgreSQL is that there's really no good, reusable Open Source framework for writing PostgreSQL applications. Yeah, you've got basic client interface libraries that let you run basic queries, but to write an effective GUI DB app you need execute lots of those queries in one pass and to save the information in some structured way via objects which can easily be manipulated and turned back into further collections of complex queries. Writing this layer is probably one of the largest and most time-consuming parts of writing a database GUI app, and Microsoft has no problem doing it because they're so gosh-darned huge.
Put in terms of MVC, we really don't have good, documented M, and the M of all the current OSS PostgreSQL clients is so hopelessly intertwined with V and C and so undocumented that reuse of M is impossible. My solution is to build an effective, well-documented and well-tutorialed M in python that many OSS projects can effectively reuse to build their own GUI apps.
Slashdot Mirror
The commercial implications of the GPL actually resemble a drunken menage a trois between thought experiment, a Rube Goldberg machine, and Pulp Fiction's explanation of Amsterdam's marijuana laws.
I never found Paul Reiser funny enough to remember any of his jokes.
When I get into Guiness, the next day I'm hungover and in no position to code. How they managed to achieve eight million downloads is beyond me.
You're a CIO, aren't you?
How could a UI disaster that informs a user who has problems logging in that "you must be logged in to do that?" and that lacks any kind of official published API possibly win?
China might have smarter intruders if they'd just stop making so much stuff with lead paint.
You do have a point about taxes and other expenses.
But considering that an experienced Cocoa developer can easily build a high-quality app in a single afternoon (Cocoa is not C++ or Java), and that Apple will be handling distribution and hosting, and that the store will most likely have some kind of rating system that will developers leverage word-of-mouth, doing iPhone applications should still be lucrative for experienced mac devs who are good at crafting good user experiences.
I understand where you're going with this, but I'd doubt that Martha Stewart would take a paper frying pan seriously.
http://www.nytimes.com/2008/03/10/nyregion/10cnd-spitzer.html?ref=nyregion
Engineer: It's only a model.
I bet she laughed when you phlashed your insignificant bits.
Simply for the hot groupies who will obviously throw their bodies at me when I win.
There's seems to be this pervasive myth in the Open Source community that "just because code is open means that it's easily modifiable and understandable" and that all you have to do is "just read the source".
If you have a project with millions of lines of code, a zillion layers of abstraction (many of which do not have clear boundaries with respect to one another other), sparse comments, lots of complex stuff going, and more than a few code cowboys who tried to prove just how clever they were (to the detriment of code understandability), it's going to take you years "just reading the source" without any help at all to get to the point where you can make reliable and effective changes to the project.
It makes far more sense to ask a project's "Lore Master" to guide you to certain entry points where you need to make a few specific changes than to spend years "just reading the code" to become a "Lore Master" yourself to make those few changes.
You'll need to upgrade that lawn to a football field so we can describe the new data size as "a football field of gigabyte hard drives".
will my phone smell like Gonorrhea?
To hell with ideology. Two completely different user environments, one running on top of another and ultimately requiring someone at some level to be an expert in both, is bad design and asking for trouble.
As a Linux usability discussion grows longer, the probability of someone saying "you can easily do it with the command line" approaches one.
If they had billed it as "a watch so awesome you'll want to hide it up your ass for your descendants" they might have gotten better sales.
"So that nobody can ever improve the software for the purposes of selling the improved codebase as a product sold exclusively by their company."
Of course, the GNU statement "You can sell GPL'ed software" really should be reworded "You can sell GPL'ed software provided you don't use exclusive codebases as a business model and instead use other methods of product differentiation like branding and support".
Both Microsoft and GNU tend to shorten things in the interest of catchiness and propaganda.
The Internet can have a strong influence on the weak-minded.
More importantly, there's no Physical Law Of The Universe stating that just because you gave up your home life you'll be spared from layoffs or outsourcing.
If you put everything into your job and you lose it, your sacrifice will be meaningless. You will have missed babies' first steps, kindergarten plays, and sunday afternoon strolls and you won't really have anything to show for it.
It's never a good sign when the words "reveal" and "Monty" are in the same sentence.
Algorithms to detect big-vs-little endian have been around for some time. It should be easy to find out who has the least significant bits.
In my experience, a tech job will probably not teach you programming; that's really more the job of your hobby projects and the ensuing battlescars you get from them. It's the stuff you can't get credit for in your classes (that might drop your GPA) that you'll probably never be able to put on a resume and have taken serious, which will develop your skills.
However, a tech job will teach you the politics of IT and software development. You'll learn about how to balance competing interests, how to accept the business doing things in the least efficient, least-technically adept way, and how to subtley sneak in better ways of doing those things under the radar.
It will definitely get you used to end users interacting with your software and learning how to cope with their complaints, feature requests, and the politics about adding features (e.g. if I add feature X, are they then going to ask for feature Y, which will be totally undoable with the current API?).
One reason why you really don't have a plethora of good Open Source GUI apps for PostgreSQL is that there's really no good, reusable Open Source framework for writing PostgreSQL applications. Yeah, you've got basic client interface libraries that let you run basic queries, but to write an effective GUI DB app you need execute lots of those queries in one pass and to save the information in some structured way via objects which can easily be manipulated and turned back into further collections of complex queries. Writing this layer is probably one of the largest and most time-consuming parts of writing a database GUI app, and Microsoft has no problem doing it because they're so gosh-darned huge.
Put in terms of MVC, we really don't have good, documented M, and the M of all the current OSS PostgreSQL clients is so hopelessly intertwined with V and C and so undocumented that reuse of M is impossible. My solution is to build an effective, well-documented and well-tutorialed M in python that many OSS projects can effectively reuse to build their own GUI apps.