In the capitalism, the fixed, low salary, is implied as the mainstream method of paymet to the employees. The work force for such a job class is determined by market forces (supply and demand). In most cases there are plenty of suppy (employees), so the salaries tend to be low. On very specific areas, where high training/specialization is required, the proportion may tend to benefit the employees through high salaries (because if one company don't pay a good salary, the others will).
The idea is that the capitalist must pay the risk of having a variable-rate incoming, and so most of the profit is his (as the reward for taking that risk).
The employee pay the price of having security (every month or so he can count on that amount).
Of course there are intermeadiate cases (profit-sharing, productivity rewards, etc), but even so it's clearily a a tradeoff between stability (risk-avoidance) and risk-acceptance.
I used to work as an autonomous programmer, and as such I got both the good and bad sides of being both the capitalist and the employee. My incoming used to be high at some times and low at others, with the average only being sligthly higher than a good job could offer.
But then again, the cost of oportunity must be used to measure the implicit factors: I had benefits employees don't get such as having more free time to spent on my own projects and on my personal life (most employees give up their personal lifes for a project, I don't consider that a thing you should do for your entire life, because otherwise you won't have a life. but that's just my opinion.). I also had other costs: I had to maintain an amount of money as a reserve to cover up my bills on low-incoming months, etc.
Most people tend not to pay the price of being a capitalist (I mean: taking risks), and that price is that most people won't improve their life styles significantly by being good employees.
If a programmer is too skilled but their company won't reward him for that adequately, he would probably consider taking risks and using his productivity in his favour. Productivity is what makes economic advances, and the whole purpose of applied technologies is to increase the productivity.
But that's a personal decision. Money is not among the most important factors for some people, and I think that's ok. Money is just an instrument, not an end in itself. If you cannot use your money to have quality of life, then maybe you shouldn't waste so much time pursuing it.
Re: New solutions thats what we need.
> Sorry for the rant about things braking.
> However by now someone should have found
> a real solution and not just reinvented
> the wheel. Since lots of software today
> uses autoconf, automake, auto.... It
> makes sense to improve things there and
> not just switch to something else that
> may or may not be better. If we can't
> get the old stuff right, what hope is
> there for anything new?
It happens frequently in the open source world, that when some project shows some limitation, someone forks it or start another one from scratch to achieve exactly the same goal, only by slightly different means. In some cases that results in a win, but on others, it's just a waste of time and effort. I don't like to even thing on the idea of restrict people freedom from starting things over and over or improving, after all, the wheel would still be square if all people were limited to only think a way or other. In the case of auto* tools, my vote would be to improving it, after all, it has it's good points. I said on another post some of the points I believe worth attention, but certainly there are others. I don't see any of the points such as using M4 and plain shell as weak ones, I thing that M4 is rather easy to use, as opposed as the article author says. And for the joe user too, consider writing a sendmail configuration profile for parsing with m4 or editing sendmail.cf by hand (which is nonsense because you lose your changes if you have to upgrade).
There's room for other build systems, but some sort of standardization on configure's parameters, some speed improvements and better consistency, followed by an user-intuitive way of managing a project tree would make it a hell of a tool.
> Right now I would like to suggest
> creating a powerful gui app capable of
> using the existing autotools and
> compensating for thier shortcomings...
I vote for a gui, but I believe it should not be created to compensate for current deficiences, instead for managing the entire project while simultaneously the auto* is fixed and improved.
> Of course I am probably wrong and lame
> for even suggesting solving the
> shortcomings of the existing autotools
> and development processes.
I don't think you are. I wouldn't use auto* for every kind of project, in some cases it stands in the way instead of helping, but it worths the effort of improvement! :-)
> Heck at least linux is cleaner and more
> stable than windows.
Windows? I forgot what is that about :-P