Why not donate, say, 3400 of them that you will never read again to a local public library?
Perhaps because, like me, the original poster may be able to state with high confidence that they won't read most of their books ever again, but cannot state with high confidence that they won't read any particular book ever again.
It doesn't require browsers to implement JPEG or PNG, it provides image format-independent hooks that can be used to support JPEG, PNG or any other image format. And the HTML 5 specification is taking the exact same approach by not requiring Theora or Vorbis, but providing codec-independent hooks that can be used to support Theora, Vorbis or any other codec.
Even before mention of Ogg formats was removed, HTML5 would not have required those formats. You correctly note that current the HTML 4.01 recommendation doesn't require JPEG, PNG, etc., but you fail to note that it does specifically mention three image formats, and they are "GIF, JPEG, and PNG".
Of course, if you did mention that, it would be a lot harder to use the current recommendations treatment of images to argue that removing the mention of Ogg formats from the HTML5 draft is consistent with the way prior HTML standards have treated images.
Honestly, if the choice was between "Should" and not referencing it, I'd go for the latter. I deal in construction contracts and specifications, and if there's a word that has done more damage than "should", I'm not aware of it.
Repeat after me:
Shall=imperative May=permissive
That's it. "Should" means "we want it, but making it a requirement will cause a problem, so if you don't do it we're going to whine, but there's nothing we can legally do about it"
A standard (or, even, a "standards-track document at IETF or W3C", which generally end up as "recommendations") is different than a contract, and there is nothing you can legally do about anything in most internet "standards". And, really, since (unlike a contract) there aren't reserved rights that are being relaxed in a standard, "may" is no more compelling than "should" (there are good reasons why "may" is meaningful where "should" is not in a contract; they are equally meaningful, or meaningless, in a standard.)
Still, both "may" and "should" are useful in standards, even though they don't have the weight of "must" or "must not", even though both recommended and permissive items are, strictly speaking, without effect since in a standard everything not specifically either forbidden or required is implicitly permitted. But both "may" and "should" items help to clarify the mandatory items and are useful in guiding implementors.
But just ask the folks at Twitter how well its database access scales to meet demand - it almost put them out of business.
Or, as the case may be, not. See, any of the later discussion of the issue after the first round of back and forth, such as this piece. Scaling is a problem, period, but there is little indication from the experience Twitter had (once they diagnosed their problems) that Rails is a particular source of the problems they were having.
A lot of things that I read obout it remind me of Python in the early days - but I don't recall Guido van Rossum being so Great Leader-ish
How, precisely, is whoever you are comparing GvR too (DHH?) being "Great Leader-ish"?
A lot of things that I read obout it remind me of Python in the early days - but I don't recall Guido van Rossum being so Great Leader-ish, and there's also the difference that Python actually can be used for an amazing range of applications. Ruby can too; it's a beautiful language - until you cut its balls off with Rails.
How, exactly, does Rails limit what you can do with Ruby? There are certainly things that you can do with Ruby that Rails doesn't make any easier, but that hardly merits your rather hyperbolic description.
The problem is not that Yahoo! Answers has false information.
The problem is that schools aren't teaching students how to evaluate sources. If they were, students would learn very quickly not to rely on Yahoo! Answers.
I've cited Wikipedia almost exclusively in my college classes. I've never had an instructor say anything negative about it and most times I'm dinged for formatting issues rather than the content or sources of information.
Ignoring any question of the quality of Wikipedia compared to more traditional encyclopedia, how is that any college course (much less, apparently, all of yours) lets you get away with citing a single source, and an encyclopedia at that, exclusively?
If someone on my schools network downloads an illegal mp3, then the RIAA has the right to confiscate and sell every single router, switch, and hub between the two people... clogging the tubes is bad enough, but taking them away and stealing them?
No, the federal government has the right to, not the RIAA. But don't worry, just as with civil forfeiture laws elsewhere, this won't be used against the property of any of the big businesses whose property might theoretically be within the reach of the law, just the politically easier to target individuals at either end.
The agile guys are right. If the code is written well, it will speak for itself. There's no need to duplicate what the code says in another language (i.e. english).
Perhaps, but before you start writing code (if you are doing TDD, even before you can write tests), you should and probably do already know what it needs to do, and chances are that knowledge is already written down in your natural language of choice.
And, in any case, even programmers who can write code that works are more likely to be able to write a human-readable explanation that is comprehensible to people who aren't equally-competent programmers in natural language that they are to be able to write self-explanatory code.
What do views, HAVING and stored procedures have to do with this?
Views eliminate entirely the "complex applications queries" problem; the view is part of the interface of the database and the application is programmed against the views it needs, not the base tables except when the two are identical.
Stored procedures (specifically, triggers) eliminate having the application update the latest revision flag, etc. Its fundamental to the structure of the DB, and shouldn't be handled in application logic.
But if 1 single extra column can mean the difference between a 200 character SQL query and a 2000 character SQL query, then yes I'd definitely consider adding a bit of redundant data to make my queries simpler.
Have you heard of views? Simplifying queries is a really bad reason to cut normalization short. (Performance, OTOH, can be a good reason, even if, arguably, in the long-run "design it properly and throw adequate hardware at it to deal with performance issues" is often a better solution.)
What part of "phone_number has many digits" is a good thing?
Well, none, since a phone_number isn't an unordered collection of digits as that description would imply. OTOH, if you identified a phone number as having, say, both a country and an ordered collection of digits, that would both be accurate and facilitate substring searching, automated dialing applications that using the db that adapted to the country of use, etc. Of course, most practical DBs have a "string" type that can be properly constrained and that are a better choice than using another table to record certain types of an ordered sequences.
I'll give you another example. In a system I'm working on, we have a 'documents' table with columns (id,title). One of the requirements is that our users must be able to see changes made to a document in the past. So we have a 'document_revisions' table, with the columns (id,document_id,content,created_on,author_id). (I'm using surrogate primary keys here, but let us forget that for the time being.) A document has many document_revisions. Suppose the users want to see a list of all latest revisions (that is, for each document I want the latest revision). Ideally I'd join documents and document_revisions, then group the results by the document's primary key, then *inside* a group order the group results by created_on DESC, then get the first item of each group.
No, ideally you'd create a view which did all that for all documents in the first place, and then query that by the primary key of the document you are interested in.
Unfortunately, to the best of my knowledge, ordering inside a group is not possible, and so it's not possible to do this in 1 query without utilizing a subquery.
IIRC, the databases that support factoring out subqueries with a WITH before the SELECT also do a better job at optimizing those that are factored out that way. I think both Oracle, DB2, and at least one or major database allow that (though Oracle won't let you make recursive queries that way).
In Oracle, you can also use KEEP DENSE RANK (FIRST | LAST) ORDER BY (...) to do this, I think (I've done queries that do essentially the same thing using it).
But if I waste a little space by adding an 'is_newest_revision' boolean column, and have the application update that column every time a new revision is inserted, then the query can be much simpler
Why the application? Since its a fundamental feature of the data model, shouldn't this be done by a trigger in the database, not by the application? (I agree that there may be a good cause to do this for performance reasons, though not to simplify queries.)
So you don't classify this a character development?
The first time it happens with a given set of characters, it may be character development.
The remaining dozen or so per volume, not so much.
also, it's a long series, authors must remind us of how their characters think from time to time or we begin to forget who they are and substitute our own thoughts for theirs.
Certainly true to an extent, which is one thing that makes writing a huge work in an expansive world without losing focus and drowning the reader in minutiae difficult.
But that the task the author has set for themselves is difficult doesn't excuse poor execution.
Details are clearly an artistic choice. Sometimes, though, they are a bad artistic choice.
Its often said that in short stories, more than novels, its important to relate only details that matter (whether its to the mood or to the plot, or its best that if the detail serves the former purpose it also serves the latter) and ruthlessly eliminate the fluff.
I think that that is, perhaps somewhat paradoxically, just as true in works much longer than a typical novel as it is in works much shorter than one. While in the shorter forms you lack the space for both fat and meat, in the longer forms you are more likely to exhaust the readers tolerance for fat, but the effect is the same. A 2 million word megastory, I think, really needs to be nearly as lean, overall, as a 1,000 word piece of flash fiction; you've got some room to be more verbose in the first couple novel-length chunks of the bigger work, but beyond that you really need to buckle down if you want to avoid drowning the reader in a tide of minutiae that overwhelms the story itself.
Great. Perfect normalization. But I would never write such a database schema. I don't even want to think about the huge, ugly, and hard to maintain SQL queries that result from this.
While the specific example doesn't make much sense (what is in the "numbers" table?), isn't the whole point of features like views in an RDBMS to allow you to properly normalize your base tables but then allow queries to be written against a schema that is friendly to the way that the database is used? Applications SQL queries shouldn't be harder to write or maintain or more complex because they are written against a database where the base tables are fully normalized, because commonly needed views of the data should be implemented as, well, views.
(OTOH, the database itself will take more work to develop in the first place if it is properly normalized, which is the real cost issue: and since that's going to happen while your are building your app, especially the first app against a database, it is a serious issue that there is often an incentive to compromise on. OTOH, poor normalization is a source of lots of downstream problems in writing new applications, or extending existing ones, against a database.)
But you could do the same thing in C. The fact that most people don't doesn't really say anything bad about C, but just bad about people who generally use it. A lot of people who write C leave memory leaks and buffer overrun problems. That doesn't mean that it can't be used properly.
Of course C can be used properly. In fact, since Ruby code (other than JRuby or, if it were usable, IronRuby) is running on C, any doing it right in Ruby is dependent on doing it right in C.
C is lower-level than Ruby, though, so in lots of cases it will take a lot more source code, and a lot more time, to do it right in C from scratch compared to doing it right mostly in Ruby and then doing only the parts that really require C, for performance or other reasons, in C.
The problem with that analogy is that a manufactured CPU can still execute code regardless if it's using the Ruby framework, or any other framework, or a custom software API.
And Rails can still run web applications that don't use ActiveRecord in the Model part of the MVC design. In fact, Rails comes bundled with a different base for models, as well (ActiveResource), as well as being usable with models that aren't built on Rails-supplied bases (though, of course, that's more work on the model side than using the Rails-supplied bases, if your use case is close to what those bases are designed for.)
If you are working with a redundant distributed DB (where the satellites don't always have connection so the data is mirrored) trying to integrate added data among the nodes is a nightmare with an auto incrementing numeric key.
So? All that Rails requires (barring use of third-party extensions which allow composite keys, as well) is that the table have a primary key, and that it be a simple key. It doesn't require that it be an integer, and it doesn't require that it be autoincrementing (which seems likely to be the real source of problems in a distributed DB.)
Sure, the default in Rails "convention over configuration" approach is to use an autoincrementing integer primary key, but defaults aren't the same thing as requirements.
I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key....
Rails does not now and never has had such a requirement, it does have a default of an autoincrementing integer primary key. It does require a primary key, and it does require that its simple (not composite), but it doesn't require that it be an integer, and it certainly doesn't require that it be autoincrementing (which seems to be the main problem for DBA's in certain use cases.)
And, for that matter, there is at least one open-source third-party extension to ActiveRecord that supports composite primary keys.
...aren't the primary target of the OLPC: most of the launch countries aren't in Africa, and the launch countries aren't, in Africa or otherwise, mostly the poorest of the poor. And while OLPC is a charitable non-profit, the model isn't one that is fairly presented by presenting a choice between giving a computer and giving rice: mostly, the OLPC project is selling laptops to countries that choose to buy them, but not making a profit in doing so.
It doesn't represent a choice between giving kids rice and giving them computers, at least, not a choice by the West. And the people that are benefitting from them aren't, for the most part, the ones for whom giving rice would make any difference at all. And, unlike giving rice (but like microcredit programs and other programs that have shown lots of success in the developing world), the OLPC project is aimed at developing independence, not developing dependence for the day-to-day necessities on outside aid.
Duverger's Law says that things tend to two-party systems, at least when you apportion votes to geographical districts.
Winner-take-all districts, sure.
Very many modern democracies don't apportion their national legislature that way, and those that don't have measurably higher public satisfaction with government, overall, than those that do.
Even where you apparently have multiple parties, like in England, the coalitions are fairly static and form a close approximation to two parties.
The UK, like the US, uses single-member winner-take-all districts in the national legislature and consequently has (at least in the sense relevant to this discussion) very similar electoral dynamics to the US. Systems that use districts with multiple members distributed proportionally, use national proportional representation, or use mixed systems where part of the legislature is elected in single-member districts and the remainder by a party list system designed to result in proportional results when the entire legislator is considered often don't, generally, approximate two-party systems.
(For more on this, see Arend Lijphart's Patterns of Democracy: Government Forms and Performance in Thirty-Six Countries.)
Basically, with enough random contributions, the counterproductive/arbitrary elements tend to cancel and the coherent parts add up over time. Ironically, this is probably why democracy tends to be a reasonably stable form of government.
Not really. Democracy is fairly stable because the main reason for government instability is that, in non-participatory systems, people often have no effective way to protest unwelcome government action except for seeking overthrow of the government (making those systems unstable, since discontent builds up and then explodes), whereas in participatory systems, direct participation provides an outlet.
This is also related to why, among democracies, systems which feature a wider array of viable parties tend to have much higher satisfaction than those, like the US, with very few, since the array of meaningful electoral choices is closely related to how much of the population feels their ideas are effectively represented in government.
Depending on their pay scale, they will probably initially draw more people into open source development. However, these people are motivated only by the money, which in the end is a very weak form of motivation.
It is a mistake to assume that the people drawn in would be motivated only by money even initially; this overlooks that the lure of money will lower one barrier that leads people to not go into F/OSS development that are otherwise motivated to do so. Further, people who initially come for the money may find other reasons to stay.
ASIDE: cyber cafes do not grow up in areas where private computer ownership is prevalent; California, for example, has a total of 11 [Source: http://www.globalcomputing.com/Cafes.html [globalcomputing.com]].
Or, maybe, the source you are looking at isn't very good. The search engine at cybercaptive.com shows something like 80 in CA. And Google Maps finds 294.
Perverse though it might sound, it's plausible that overall satisfaction & productivity might be lower if some are getting paid compared to when none are.
Are you under the impression no one is getting paid to work on OSS software now?
On reading the article the main thing that jumped out at me was the assumption that Sun, or at least Simon Phipps, believes that most open source programming will be done in India.
No, he states that he believs that most of the expansion in open source programming will be in India. Considering raw population numbers and development trends, that's probably not an entirely unreasonable assumption.
The US and Western Europe, for instance, probably have as a high a percentage of their population programming as they are going to have, and the split between open source and proprietary is probably pretty stable (not that it won't change over time, but there is a lot of inertia built in).
India has quite a lot of people, is seeing lots of growth in the tech field, and is a lot more fluid in how the structure of its tech industry will shake out. So, yeah, lots of growth in open source development is likely there, and spending any given amount of money to encourage that growth is likely to have a lot more effect there, not only because of the greater practical value of the same amount of money in India, but because a lot less of India's programmers or potential new programmers are entrenched in an existing system and unlikely to change their behavior without a major incentive.
On the other hand, the people who pay are the people who set your agenda - and you are essentially working for the boss.
The fact that someone is offering money for OSS development doesn't really take anything away from the people that have their own strong interests that no one is offering money for. It might even broaden the community of people willing to work on OSS without pay, since there'll be a limited number of paid gigs available, and the best way to qualify yourself for them is to get intimately familiar with the software for which they are offered -- and the best way to do that is to actually work on it.
The problem is when Sun etc. start paying, the pool of available programmers decreases for other projects
This presumes that the pool of programmers who will work on OSS is fixed, so that whoever takes the pay is coming out of the pool of people who would otherwise do it for free. But making money available means that you are more likely to pull people who otherwise wouldn't work on OSS into the OSS development world.
Plus, a whole lot of OSS development is done for pay now, by paid employees of firms like Sun, IBM, etc. Heck, offering bounties for particular features from the community isn't new, either.
If I were Microsoft or Google (summer of code), this sounds like a good strategy... just hand out some cash to the communities which don't threaten you in any way, grow them, and thus minimize the communities which might threaten you.
How does this work? Getting paid to work on a feature in, say, OpenJDK doesn't make you less capable of turning around and implementing an open source project (for free or paid for by a competitor) that might challenge Sun's Java.
If anything, it makes you more capable of doing that, if you were inclined to do so.
Slashdot Mirror
Perhaps because, like me, the original poster may be able to state with high confidence that they won't read most of their books ever again, but cannot state with high confidence that they won't read any particular book ever again.
Even before mention of Ogg formats was removed, HTML5 would not have required those formats. You correctly note that current the HTML 4.01 recommendation doesn't require JPEG, PNG, etc., but you fail to note that it does specifically mention three image formats, and they are "GIF, JPEG, and PNG".
Of course, if you did mention that, it would be a lot harder to use the current recommendations treatment of images to argue that removing the mention of Ogg formats from the HTML5 draft is consistent with the way prior HTML standards have treated images.
A standard (or, even, a "standards-track document at IETF or W3C", which generally end up as "recommendations") is different than a contract, and there is nothing you can legally do about anything in most internet "standards". And, really, since (unlike a contract) there aren't reserved rights that are being relaxed in a standard, "may" is no more compelling than "should" (there are good reasons why "may" is meaningful where "should" is not in a contract; they are equally meaningful, or meaningless, in a standard.)
Still, both "may" and "should" are useful in standards, even though they don't have the weight of "must" or "must not", even though both recommended and permissive items are, strictly speaking, without effect since in a standard everything not specifically either forbidden or required is implicitly permitted. But both "may" and "should" items help to clarify the mandatory items and are useful in guiding implementors.
Or, as the case may be, not. See, any of the later discussion of the issue after the first round of back and forth, such as this piece. Scaling is a problem, period, but there is little indication from the experience Twitter had (once they diagnosed their problems) that Rails is a particular source of the problems they were having.
How, precisely, is whoever you are comparing GvR too (DHH?) being "Great Leader-ish"?
How, exactly, does Rails limit what you can do with Ruby? There are certainly things that you can do with Ruby that Rails doesn't make any easier, but that hardly merits your rather hyperbolic description.
The problem is not that Yahoo! Answers has false information.
The problem is that schools aren't teaching students how to evaluate sources. If they were, students would learn very quickly not to rely on Yahoo! Answers.
Ignoring any question of the quality of Wikipedia compared to more traditional encyclopedia, how is that any college course (much less, apparently, all of yours) lets you get away with citing a single source, and an encyclopedia at that, exclusively?
No, the federal government has the right to, not the RIAA. But don't worry, just as with civil forfeiture laws elsewhere, this won't be used against the property of any of the big businesses whose property might theoretically be within the reach of the law, just the politically easier to target individuals at either end.
Perhaps, but before you start writing code (if you are doing TDD, even before you can write tests), you should and probably do already know what it needs to do, and chances are that knowledge is already written down in your natural language of choice.
And, in any case, even programmers who can write code that works are more likely to be able to write a human-readable explanation that is comprehensible to people who aren't equally-competent programmers in natural language that they are to be able to write self-explanatory code.
Views eliminate entirely the "complex applications queries" problem; the view is part of the interface of the database and the application is programmed against the views it needs, not the base tables except when the two are identical.
Stored procedures (specifically, triggers) eliminate having the application update the latest revision flag, etc. Its fundamental to the structure of the DB, and shouldn't be handled in application logic.
Have you heard of views? Simplifying queries is a really bad reason to cut normalization short. (Performance, OTOH, can be a good reason, even if, arguably, in the long-run "design it properly and throw adequate hardware at it to deal with performance issues" is often a better solution.)
Well, none, since a phone_number isn't an unordered collection of digits as that description would imply. OTOH, if you identified a phone number as having, say, both a country and an ordered collection of digits, that would both be accurate and facilitate substring searching, automated dialing applications that using the db that adapted to the country of use, etc. Of course, most practical DBs have a "string" type that can be properly constrained and that are a better choice than using another table to record certain types of an ordered sequences.
No, ideally you'd create a view which did all that for all documents in the first place, and then query that by the primary key of the document you are interested in.
IIRC, the databases that support factoring out subqueries with a WITH before the SELECT also do a better job at optimizing those that are factored out that way. I think both Oracle, DB2, and at least one or major database allow that (though Oracle won't let you make recursive queries that way).
In Oracle, you can also use KEEP DENSE RANK (FIRST | LAST) ORDER BY (...) to do this, I think (I've done queries that do essentially the same thing using it).
Why the application? Since its a fundamental feature of the data model, shouldn't this be done by a trigger in the database, not by the application? (I agree that there may be a good cause to do this for performance reasons, though not to simplify queries.)
The first time it happens with a given set of characters, it may be character development.
The remaining dozen or so per volume, not so much.
Certainly true to an extent, which is one thing that makes writing a huge work in an expansive world without losing focus and drowning the reader in minutiae difficult.
But that the task the author has set for themselves is difficult doesn't excuse poor execution.
Details are clearly an artistic choice. Sometimes, though, they are a bad artistic choice.
Its often said that in short stories, more than novels, its important to relate only details that matter (whether its to the mood or to the plot, or its best that if the detail serves the former purpose it also serves the latter) and ruthlessly eliminate the fluff.
I think that that is, perhaps somewhat paradoxically, just as true in works much longer than a typical novel as it is in works much shorter than one. While in the shorter forms you lack the space for both fat and meat, in the longer forms you are more likely to exhaust the readers tolerance for fat, but the effect is the same. A 2 million word megastory, I think, really needs to be nearly as lean, overall, as a 1,000 word piece of flash fiction; you've got some room to be more verbose in the first couple novel-length chunks of the bigger work, but beyond that you really need to buckle down if you want to avoid drowning the reader in a tide of minutiae that overwhelms the story itself.
While the specific example doesn't make much sense (what is in the "numbers" table?), isn't the whole point of features like views in an RDBMS to allow you to properly normalize your base tables but then allow queries to be written against a schema that is friendly to the way that the database is used? Applications SQL queries shouldn't be harder to write or maintain or more complex because they are written against a database where the base tables are fully normalized, because commonly needed views of the data should be implemented as, well, views.
(OTOH, the database itself will take more work to develop in the first place if it is properly normalized, which is the real cost issue: and since that's going to happen while your are building your app, especially the first app against a database, it is a serious issue that there is often an incentive to compromise on. OTOH, poor normalization is a source of lots of downstream problems in writing new applications, or extending existing ones, against a database.)
Of course C can be used properly. In fact, since Ruby code (other than JRuby or, if it were usable, IronRuby) is running on C, any doing it right in Ruby is dependent on doing it right in C.
C is lower-level than Ruby, though, so in lots of cases it will take a lot more source code, and a lot more time, to do it right in C from scratch compared to doing it right mostly in Ruby and then doing only the parts that really require C, for performance or other reasons, in C.
And Rails can still run web applications that don't use ActiveRecord in the Model part of the MVC design. In fact, Rails comes bundled with a different base for models, as well (ActiveResource), as well as being usable with models that aren't built on Rails-supplied bases (though, of course, that's more work on the model side than using the Rails-supplied bases, if your use case is close to what those bases are designed for.)
so where's the problem with the analogy?
So? All that Rails requires (barring use of third-party extensions which allow composite keys, as well) is that the table have a primary key, and that it be a simple key. It doesn't require that it be an integer, and it doesn't require that it be autoincrementing (which seems likely to be the real source of problems in a distributed DB.)
Sure, the default in Rails "convention over configuration" approach is to use an autoincrementing integer primary key, but defaults aren't the same thing as requirements.
Rails does not now and never has had such a requirement, it does have a default of an autoincrementing integer primary key. It does require a primary key, and it does require that its simple (not composite), but it doesn't require that it be an integer, and it certainly doesn't require that it be autoincrementing (which seems to be the main problem for DBA's in certain use cases.)
And, for that matter, there is at least one open-source third-party extension to ActiveRecord that supports composite primary keys.
...aren't the primary target of the OLPC: most of the launch countries aren't in Africa, and the launch countries aren't, in Africa or otherwise, mostly the poorest of the poor. And while OLPC is a charitable non-profit, the model isn't one that is fairly presented by presenting a choice between giving a computer and giving rice: mostly, the OLPC project is selling laptops to countries that choose to buy them, but not making a profit in doing so.
It doesn't represent a choice between giving kids rice and giving them computers, at least, not a choice by the West. And the people that are benefitting from them aren't, for the most part, the ones for whom giving rice would make any difference at all. And, unlike giving rice (but like microcredit programs and other programs that have shown lots of success in the developing world), the OLPC project is aimed at developing independence, not developing dependence for the day-to-day necessities on outside aid.
Winner-take-all districts, sure.
Very many modern democracies don't apportion their national legislature that way, and those that don't have measurably higher public satisfaction with government, overall, than those that do.
The UK, like the US, uses single-member winner-take-all districts in the national legislature and consequently has (at least in the sense relevant to this discussion) very similar electoral dynamics to the US. Systems that use districts with multiple members distributed proportionally, use national proportional representation, or use mixed systems where part of the legislature is elected in single-member districts and the remainder by a party list system designed to result in proportional results when the entire legislator is considered often don't, generally, approximate two-party systems.
(For more on this, see Arend Lijphart's Patterns of Democracy: Government Forms and Performance in Thirty-Six Countries.)
Not really. Democracy is fairly stable because the main reason for government instability is that, in non-participatory systems, people often have no effective way to protest unwelcome government action except for seeking overthrow of the government (making those systems unstable, since discontent builds up and then explodes), whereas in participatory systems, direct participation provides an outlet.
This is also related to why, among democracies, systems which feature a wider array of viable parties tend to have much higher satisfaction than those, like the US, with very few, since the array of meaningful electoral choices is closely related to how much of the population feels their ideas are effectively represented in government.
It is a mistake to assume that the people drawn in would be motivated only by money even initially; this overlooks that the lure of money will lower one barrier that leads people to not go into F/OSS development that are otherwise motivated to do so. Further, people who initially come for the money may find other reasons to stay.
Or, maybe, the source you are looking at isn't very good. The search engine at cybercaptive.com shows something like 80 in CA. And Google Maps finds 294.
Are you under the impression no one is getting paid to work on OSS software now?
No, he states that he believs that most of the expansion in open source programming will be in India. Considering raw population numbers and development trends, that's probably not an entirely unreasonable assumption.
The US and Western Europe, for instance, probably have as a high a percentage of their population programming as they are going to have, and the split between open source and proprietary is probably pretty stable (not that it won't change over time, but there is a lot of inertia built in).
India has quite a lot of people, is seeing lots of growth in the tech field, and is a lot more fluid in how the structure of its tech industry will shake out. So, yeah, lots of growth in open source development is likely there, and spending any given amount of money to encourage that growth is likely to have a lot more effect there, not only because of the greater practical value of the same amount of money in India, but because a lot less of India's programmers or potential new programmers are entrenched in an existing system and unlikely to change their behavior without a major incentive.
The fact that someone is offering money for OSS development doesn't really take anything away from the people that have their own strong interests that no one is offering money for. It might even broaden the community of people willing to work on OSS without pay, since there'll be a limited number of paid gigs available, and the best way to qualify yourself for them is to get intimately familiar with the software for which they are offered -- and the best way to do that is to actually work on it.
This presumes that the pool of programmers who will work on OSS is fixed, so that whoever takes the pay is coming out of the pool of people who would otherwise do it for free. But making money available means that you are more likely to pull people who otherwise wouldn't work on OSS into the OSS development world.
Plus, a whole lot of OSS development is done for pay now, by paid employees of firms like Sun, IBM, etc. Heck, offering bounties for particular features from the community isn't new, either.
How does this work? Getting paid to work on a feature in, say, OpenJDK doesn't make you less capable of turning around and implementing an open source project (for free or paid for by a competitor) that might challenge Sun's Java.
If anything, it makes you more capable of doing that, if you were inclined to do so.