Can your company trust every user that has some access to the database?
Yes, if the only thing that has access to the database is the application logic.
I feel that you're better off putting all of your business logic in one place. That can be the database, of course. I know a very clever DBA/developer who built a financial exchange system entirely in the database, accessing everything via stored procedures. It was very cool, as the database took care of many of the hard parts of building a system like that.
But personally, I think putting all your business logic in a database's proprietary language is a pain. The development tools aren't as good, you have a big vendor dependency, and it's hard to find developers who can work in that style.
Instead, I think of a database as the place where the application puts objects when it doesn't need them. In that case, there's no reason to give anybody but the app access to the database. Sure, people may need to run Crystal Reports, but you shouldn't let them do that against the production database servers anyhow.
So these days when I build things, I put no code in the database. And once I made that choice, it freed me up to not even have a database. That makes refactoring much easier, speeding development. Sometimes I still end up using a traditional SQL database, but that's now a choice for me based on performance characteristics, rather than a default.
Our products (both print and online) are geared to the K-12 student and very little else.
Wow. That's fantastically depressing. I hold in my hand a reproduction of the original Encyclopaedia Britannica, which was printed in 1771. The preface opens like this:
Utility ought to be the principal intention of every publication. Wheever this intention does not plainly appear, neither the books nor their authors have the smallest claim to the approbation of mankind.
To diffuse the knowledge of Science, is the professed design of the following work. [...] We will, however, venture to affirm, that any man of ordinary parts, may, if he chuses [sic], learn the principles of Agriculture, of Astronomy, of Botany, of Chemistry, &c., &c. from the Encyclopaedia Britannica.
If the current Encyclopedia Britannica's main focus is on selling to school librarians so that 7th graders can easily do their homework, then as far as I'm concerned the Internet has already put the Encylopaedia Britannica out of business, the important and noble business of providing the common man with access to the wealth of human knowledge. I'm glad that Wikipedia is stepping in to take up the slack.
However, as a product, we don't see our core audience (K-12 School and Libraries) running away from us for Wikipedia in the near future.
That's probably true, but I think that says more about K-12 teachers and librarians than it does about the relative reference-source merits of EB vs. Wikipedia.
If I were a teacher, I'd be worried that continuing to let students depend on a single authoritative source like the EB is giving them bad habits. For the rest of their lives, they're going to have to deal with the Internet and its profusion of information and viewpoints. Better that they learn early how to do this, and I can think of few better places to learn than Wikipedia, which makes the process open and transparent in a way that the EB can't match.
[...] our goal is a meaningful survey and near permanent archive of 1,000 languages. Our intention is to create a unique platform for comparative linguistic research and education as well as a functional linguistic tool that might help in the recovery or revitalization of lost languages in unknown futures. [...] The resulting archive will be publicly available in three different media:
a micro-etched nickel disk with 2,000 year life expectancy; a single-volume monumental reference book; and through this growing online archive.
They put an early version of their micro-etched disk (which is not digital; it's like microfilm) on an ESA space probe, so a copy may end up on a comet.
Not really. Lot's of run-of-the-mill grunts like me in The Stans and at Diego. Standard short tour TDY for DoD and Air Force folks.
I can verify that. Circa 1994, a friend was looking at the phone book's list of country codes and noticed Diego Garcia. Neither of us had heard of this, and since this was back before the rise of the search engine, we couldn't find much out. So we started calling random numbers.
After we discovered that the phone number space for the whole country was 4 whole digits, we started at the low end and worked our way up. We eventually got a Cable and Wireless tech who was really glad for the diversion. He told us a fair bit of nonclassified information about the island, including how boring it was to be posted to a sliver of sand so far from anywhere that the middle of nowhere sounded like a step up.
Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects? People who are familiar enough that they can catch an exploit that may only take 3-4 lines of code to perform?
Care to put your money where your mouth is?
Let's see if you or your minions can sneak a bug into the Linux kernel or a major component like you describe. It would have to be severe enough that it would plausibly disable or degrade a weapon under combat conditions, but not be caught by field testing of that same weapon. It must get released and be in circulation for six months without discovery.
Shall we make it a $100 bet? I'd be willing to go as high as $2500, and if you want to go higher, I'm sure I can find a consortium. If you want, we can use Long Bets to make sure the money goes to charity.
create a miscalculation, how much expertise would be needed to catch that?
It's not who, it's what.
Aside from smart developers who will be suspicious of patches from unknown contributors, open-source projects have two other lines of defense, one of which is utterly unavailable to proprietary products.
One line is test suites. If the DOD is worried about a particular package, they should hire people to extend the automated test suite for that package.
The other is extensive field testing. A proprietary chunk of defense code may get some field testing. But it will be orders of magnitude less than what a popular OSS project gets. If a popular math library has a bug big enough to screw up the relatively low-precision business of putting shells on target, it will utterly wreck some PhD candidate's simulation of colliding galaxies.
It seems to me that a far bigger threat to defense than sneaky OSS programmer-spies is the higher bug rates that closed source allows. And a good runner-up is the absurd expense of most defense projects. I'd rather spend the money where it matters, not on expensive efforts to rebuild free wheels.
Your average company is an even worse customer. They may look to Linux for the perceived cost advantages, but rest assured that they do _not_ want to pay a team that looks under the hood and fixes stuff.
That depends on the company and the market. At my company, we regularly contribute patches back to OSS projects, and have a few things that we'll release once they're a bit further along. Why? Because for some things, OSS is a better financial deal than reinventing the wheel.
Paying a team to open the hood of all those packages and fix things is far more expensive than just getting a packaged closed solution from Microsoft, Sun, IBM, or whoever.
This is probably true for a commodity item that's not part of a core business function. But that's only a portion of the software market.
There's quite a lot of software for which companies buy service and support contracts. It is my frequent experience that these are worse than useless; if you have smart engineers, you'd be better off getting just the source and no support. Of course, that's not an option with commercial software. You pay through the nose for the right to file bug reports that they may never act on, and even if they do, it's not going to help you with your pressing development problem.
Agreed. You have to admit though. There is need for better documentation/tutorials for allot of OSS software. We need this to galvanise what OSS has to offer.
Yep! And I think this is a great place for non-programmers to get involved in OSS projects. It's almost impossible for the programmers to write good documentation; they're too close to the product, and have a hard time imagining what it would be like to come to their product for the first time.
I think Wikis are a big help in this; since anybody can edit, it makes casual contributions much easier. SpamAssassin, for example, is developing a good Wiki.
Step 1 hasn't changed in a long time. [...] Not much innovation recently.
I think that's a plus, not a minus. That's like saying the telephone hasn't seen much innovation because we're still just putting our mouth to a hole and talking.
Caching a copy of the web was certainly innovative. Google's news search was innovative. Their AdWords program broke new ground. They've also continued to add a variety of special features, including special functionality for addresses, phone numbers, calculations, hot news topics, and package tracking numbers. And although you can't see it, their behind-the-scenes operations are very innovative.
And really, I think keeping Google's simple interface has been one of their biggest innovations. For years, everybody thought thing thing to do was to clutter up your main pages with boatloads of crap. Google's relentless focus on what their users want, rather than what their MBAs think is the best way to squeeze revenue from their users, was a huge gamble that has paid off beautifully.
I'll takle an EASY target: "Open Source software allows you to get under the hood and fix problems"
He claims that it's hard and that nobody does it "in the real world."
Yeah, that's no myth. I certainly do it on a regular basis.
And it sure beats the alternative. Discover a bug in a Microsoft product? Well, if you're lucky and work for a Fortune 100 company, you can spend a few days trying to get hold of somebody smart enough to file a real bug report. At which point they will probably ignore it. And if they don't, it'll just be a year or three before it is fixed.
1. "If you're not willing to help fix it then you shouldn't complain about it"
I think the author sets up a straw man. Constructive criticism is great. But I invoke this when somebody is whining, making demands, or generally acting like they paid money for something.
Of course, some people are probably too surly about this. The productive way to approach an OSS project is, "How can I help make this better?" And the productive way to respond to demanding users isn't "Dude, STFU." It's, "Yes, we agree the error messages could be improved. They're mainly in these files. Have fun!"
Haven't done much contracting yourself, outside of your given field, have you?
I've done some, not a ton. But that's irrelevant. I was contradicting a poster who was drawing a flawed analogy with software development. I don't need to have contracted in other fields to know how my field works, thanks.
Theoretically, if you were good enough, you could negotiate a contract in which you retained or shared in the rights.
I've done that myself on occasion. But that doesn't change the fact that the general expectation for custom software development is that it will be done as a work for hire.
Or you could take your own advice, use the application/xhtml+xml media type, and say goodbye to Internet Explorer users, Lynx users, Links users and most search engines. After all, you just have to write to standards, and your job is done, right?
A-fucking-men. I dunno why the just-code-to-standards guy writes software, but I make stuff because I want people to use it. I work hard to hew to the standards, of course. But that's not where my development ends, it's where it starts.
For us, developer boxes are all Linux, so the app works great in Mozilla. The UI designer uses OS X and a manager uses Windows, so we get good casual testing coverage.
But for formal testing, we use VMWare to make sure the app works under older versions of IE. It turns out that IE5Mac has a special set of bugs all its own, so we will be getting an old iMac and serving it up to the developers via VNC.
VMWare is pretty swell, as you can juggle multiple virtual disks in separate files. That way we can bring up Win98, Win2k, or WinXP when we need to test with the IE versions they come with. Even better, it has a non-persistent mode, so that Windows can't get corrupted or set to other than the default settings.
Also, once we discover non-visual browser quirks, we add to our automated test suite, to make sure the app doesn't break in the future. For that, we use HttpUnit with a custom wrapper and a fair bit of XPath assertions.
A few years back, the hype surrounding Extreme Programming got me curious, so I tried the style of development known as Test-Driven Development. It makes development less frustrating and more fun, so I'm a lot less likely to wander off to places like Slashdot.
Basically, the way it works is you sit down, figure out what you're going to do next, and write a few line of test code that don't pass yet. You write a little code to make the test pass. Then you expand the test a little, and make that pass. And so on. There are two main rules: don't write production code without a broken test, and try to keep the time between cycles pretty short, say under 10 minutes.
The short cycles and alternating viewpoints make it feel something like playing chess against yourself. Since everything you write is tested, bug rates are very low, and using the debugger becomes very rare. And although I thought my code was pretty good before, I think it's better now. By starting out thinking how it looks on the outside, the APIs are cleaner and easier to use.
If the bride and groom provided the photographer's camera and film/media, computer, etc, hired a darkroom/Mac on his behalf, paid him hourly to operate them, you might have a point.
But, the photographer provides his own equipment, and the deliverable is an album full of prints. It's more like shrinkwrap software than code.
Haven't done much contracting, have you? I've done fixed-bid software projects using my own gear, and the near-universal expectation is that it's a work for hire.
You're not paying attention. I'm not saying piracy is good. I'm not saying that content creators shouldn't be rewarded for their work.
All I'm saying is that Mozart didn't "do it for the money". He made music, and he did get paid, but the causal connection is pretty weak.
BTW, for the techies, you are mixing types of people. (As you did before with Newton and Einstein)
Now you're really not paying attention. This may amaze you, but a number of entirely different people post on slashdot. If you have arguments with ones other than me, then you should talk to them directly.
Um. Shakespeare and Mozart in fact did do it for the money, but in general they created works for hire. [...] The Beatles definately did it for money, as I didnt notice them giving away all of their profits and living in poverty.
This is pretty sloppy logic. I know a number of musicians; some of them get paid for it and some don't. But pretty much all of them make music because they want to make music; getting paid is a nice bonus, and much of that money goes right back into the costs of making music.
The better techies I know are the same way. I didn't stay up 'til all hours hacking away on my dad's Apple ][+ because I looked forward to a lucrative career; I did it because I had to. I feel fantastically lucky that I can build cool things and make a living at it. But if the bottom dropped out of the market tomorrow, I'd just have to go out and get a day job to support my coding habit.
I guess someone needs to write some David Irving style Holocaust denial to balance the Holocaust entry. As I said, that policy is stupid.
If that were the policy, it would be stupid. It's a good thing it isn't.
If you had done a little research, you could have seen that their Holocaust page has information on deniers. See the section Historical interpretations.
This approach maintains neutral point of view. The vast majority of historians agree that the holocaust happened, so the article is written that way. However, the article acknowledges the minority view by describing it explicitly as a minority view. Nothing is compromised, and nothing important is left out.
You can see similar approaches being worked out on much more contentious issues, like the pages relating to the Israeli/Palestinian conflict. The discussion pages are fascinating; you can see the process where people are eagerly searching out both the parts where everybody agrees and the parts where everybody agrees to disagree.
an article would need checking by just one or two guys who know their stuff, not a million monkeys.
And who determines who those guys are? I'm sorry to break it to you, but all you have to work with are monkeys.
If you look at Wikipedia and in particular the discussions linked to each page, you can see the process. It's not perfect, but the content quality generally improves over time. That doesn't sound like much, but it's all evolution needed to make us monkeys in the first place.
Slashdot Mirror
Can your company trust every user that has some access to the database?
Yes, if the only thing that has access to the database is the application logic.
I feel that you're better off putting all of your business logic in one place. That can be the database, of course. I know a very clever DBA/developer who built a financial exchange system entirely in the database, accessing everything via stored procedures. It was very cool, as the database took care of many of the hard parts of building a system like that.
But personally, I think putting all your business logic in a database's proprietary language is a pain. The development tools aren't as good, you have a big vendor dependency, and it's hard to find developers who can work in that style.
Instead, I think of a database as the place where the application puts objects when it doesn't need them. In that case, there's no reason to give anybody but the app access to the database. Sure, people may need to run Crystal Reports, but you shouldn't let them do that against the production database servers anyhow.
So these days when I build things, I put no code in the database. And once I made that choice, it freed me up to not even have a database. That makes refactoring much easier, speeding development. Sometimes I still end up using a traditional SQL database, but that's now a choice for me based on performance characteristics, rather than a default.
Wow. That's fantastically depressing. I hold in my hand a reproduction of the original Encyclopaedia Britannica, which was printed in 1771. The preface opens like this: If the current Encyclopedia Britannica's main focus is on selling to school librarians so that 7th graders can easily do their homework, then as far as I'm concerned the Internet has already put the Encylopaedia Britannica out of business, the important and noble business of providing the common man with access to the wealth of human knowledge. I'm glad that Wikipedia is stepping in to take up the slack.
However, as a product, we don't see our core audience (K-12 School and Libraries) running away from us for Wikipedia in the near future.
That's probably true, but I think that says more about K-12 teachers and librarians than it does about the relative reference-source merits of EB vs. Wikipedia.
If I were a teacher, I'd be worried that continuing to let students depend on a single authoritative source like the EB is giving them bad habits. For the rest of their lives, they're going to have to deal with the Internet and its profusion of information and viewpoints. Better that they learn early how to do this, and I can think of few better places to learn than Wikipedia, which makes the process open and transparent in a way that the EB can't match.
Every single person on the planet. Does that mean couples can forget about it? ;)
Yes. If you have love, you don't need anything else.
A better option might be to do like The Rosetta Project:They put an early version of their micro-etched disk (which is not digital; it's like microfilm) on an ESA space probe, so a copy may end up on a comet.
Not really. Lot's of run-of-the-mill grunts like me in The Stans and at Diego. Standard short tour TDY for DoD and Air Force folks.
I can verify that. Circa 1994, a friend was looking at the phone book's list of country codes and noticed Diego Garcia. Neither of us had heard of this, and since this was back before the rise of the search engine, we couldn't find much out. So we started calling random numbers.
After we discovered that the phone number space for the whole country was 4 whole digits, we started at the low end and worked our way up. We eventually got a Cable and Wireless tech who was really glad for the diversion. He told us a fair bit of nonclassified information about the island, including how boring it was to be posted to a sliver of sand so far from anywhere that the middle of nowhere sounded like a step up.
Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects? People who are familiar enough that they can catch an exploit that may only take 3-4 lines of code to perform?
Care to put your money where your mouth is?
Let's see if you or your minions can sneak a bug into the Linux kernel or a major component like you describe. It would have to be severe enough that it would plausibly disable or degrade a weapon under combat conditions, but not be caught by field testing of that same weapon. It must get released and be in circulation for six months without discovery.
Shall we make it a $100 bet? I'd be willing to go as high as $2500, and if you want to go higher, I'm sure I can find a consortium. If you want, we can use Long Bets to make sure the money goes to charity.
create a miscalculation, how much expertise would be needed to catch that?
It's not who, it's what.
Aside from smart developers who will be suspicious of patches from unknown contributors, open-source projects have two other lines of defense, one of which is utterly unavailable to proprietary products.
One line is test suites. If the DOD is worried about a particular package, they should hire people to extend the automated test suite for that package.
The other is extensive field testing. A proprietary chunk of defense code may get some field testing. But it will be orders of magnitude less than what a popular OSS project gets. If a popular math library has a bug big enough to screw up the relatively low-precision business of putting shells on target, it will utterly wreck some PhD candidate's simulation of colliding galaxies.
It seems to me that a far bigger threat to defense than sneaky OSS programmer-spies is the higher bug rates that closed source allows. And a good runner-up is the absurd expense of most defense projects. I'd rather spend the money where it matters, not on expensive efforts to rebuild free wheels.
Google bought Dejanews, they didn't innovate the news search.
I was referring to the common meaning of news, found at news.google.com, not Usenet News.
Your average company is an even worse customer. They may look to Linux for the perceived cost advantages, but rest assured that they do _not_ want to pay a team that looks under the hood and fixes stuff.
That depends on the company and the market. At my company, we regularly contribute patches back to OSS projects, and have a few things that we'll release once they're a bit further along. Why? Because for some things, OSS is a better financial deal than reinventing the wheel.
Paying a team to open the hood of all those packages and fix things is far more expensive than just getting a packaged closed solution from Microsoft, Sun, IBM, or whoever.
This is probably true for a commodity item that's not part of a core business function. But that's only a portion of the software market.
There's quite a lot of software for which companies buy service and support contracts. It is my frequent experience that these are worse than useless; if you have smart engineers, you'd be better off getting just the source and no support. Of course, that's not an option with commercial software. You pay through the nose for the right to file bug reports that they may never act on, and even if they do, it's not going to help you with your pressing development problem.
Agreed. You have to admit though. There is need for better documentation/tutorials for allot of OSS software. We need this to galvanise what OSS has to offer.
Yep! And I think this is a great place for non-programmers to get involved in OSS projects. It's almost impossible for the programmers to write good documentation; they're too close to the product, and have a hard time imagining what it would be like to come to their product for the first time.
I think Wikis are a big help in this; since anybody can edit, it makes casual contributions much easier. SpamAssassin, for example, is developing a good Wiki.
Step 1 hasn't changed in a long time. [...]
Not much innovation recently.
I think that's a plus, not a minus. That's like saying the telephone hasn't seen much innovation because we're still just putting our mouth to a hole and talking.
Caching a copy of the web was certainly innovative. Google's news search was innovative. Their AdWords program broke new ground. They've also continued to add a variety of special features, including special functionality for addresses, phone numbers, calculations, hot news topics, and package tracking numbers. And although you can't see it, their behind-the-scenes operations are very innovative.
And really, I think keeping Google's simple interface has been one of their biggest innovations. For years, everybody thought thing thing to do was to clutter up your main pages with boatloads of crap. Google's relentless focus on what their users want, rather than what their MBAs think is the best way to squeeze revenue from their users, was a huge gamble that has paid off beautifully.
Yeah, that's no myth. I certainly do it on a regular basis.
And it sure beats the alternative. Discover a bug in a Microsoft product? Well, if you're lucky and work for a Fortune 100 company, you can spend a few days trying to get hold of somebody smart enough to file a real bug report. At which point they will probably ignore it. And if they don't, it'll just be a year or three before it is fixed.
1. "If you're not willing to help fix it then you shouldn't complain about it"
I think the author sets up a straw man. Constructive criticism is great. But I invoke this when somebody is whining, making demands, or generally acting like they paid money for something.
Of course, some people are probably too surly about this. The productive way to approach an OSS project is, "How can I help make this better?" And the productive way to respond to demanding users isn't "Dude, STFU." It's, "Yes, we agree the error messages could be improved. They're mainly in these files. Have fun!"
I completely agree with the rest of your post, but this part needs correction:
there is no theoretical reason to believe that the model will even approximate reality.
That's just not true; in theory, theory and practice are the same. It's just that in practice...
Haven't done much contracting yourself, outside of your given field, have you?
I've done some, not a ton. But that's irrelevant. I was contradicting a poster who was drawing a flawed analogy with software development. I don't need to have contracted in other fields to know how my field works, thanks.
Theoretically, if you were good enough, you could negotiate a contract in which you retained or shared in the rights.
I've done that myself on occasion. But that doesn't change the fact that the general expectation for custom software development is that it will be done as a work for hire.
Or you could take your own advice, use the application/xhtml+xml media type, and say goodbye to Internet Explorer users, Lynx users, Links users and most search engines. After all, you just have to write to standards, and your job is done, right?
A-fucking-men. I dunno why the just-code-to-standards guy writes software, but I make stuff because I want people to use it. I work hard to hew to the standards, of course. But that's not where my development ends, it's where it starts.
Yes, you really do need the proper OSes.
For us, developer boxes are all Linux, so the app works great in Mozilla. The UI designer uses OS X and a manager uses Windows, so we get good casual testing coverage.
But for formal testing, we use VMWare to make sure the app works under older versions of IE. It turns out that IE5Mac has a special set of bugs all its own, so we will be getting an old iMac and serving it up to the developers via VNC.
VMWare is pretty swell, as you can juggle multiple virtual disks in separate files. That way we can bring up Win98, Win2k, or WinXP when we need to test with the IE versions they come with. Even better, it has a non-persistent mode, so that Windows can't get corrupted or set to other than the default settings.
Also, once we discover non-visual browser quirks, we add to our automated test suite, to make sure the app doesn't break in the future. For that, we use HttpUnit with a custom wrapper and a fair bit of XPath assertions.
A few years back, the hype surrounding Extreme Programming got me curious, so I tried the style of development known as Test-Driven Development. It makes development less frustrating and more fun, so I'm a lot less likely to wander off to places like Slashdot.
Basically, the way it works is you sit down, figure out what you're going to do next, and write a few line of test code that don't pass yet. You write a little code to make the test pass. Then you expand the test a little, and make that pass. And so on. There are two main rules: don't write production code without a broken test, and try to keep the time between cycles pretty short, say under 10 minutes.
The short cycles and alternating viewpoints make it feel something like playing chess against yourself. Since everything you write is tested, bug rates are very low, and using the debugger becomes very rare. And although I thought my code was pretty good before, I think it's better now. By starting out thinking how it looks on the outside, the APIs are cleaner and easier to use.
If the bride and groom provided the photographer's camera and film/media, computer, etc, hired a darkroom/Mac on his behalf, paid him hourly to operate them, you might have a point.
But, the photographer provides his own equipment, and the deliverable is an album full of prints. It's more like shrinkwrap software than code.
Haven't done much contracting, have you? I've done fixed-bid software projects using my own gear, and the near-universal expectation is that it's a work for hire.
You're not paying attention. I'm not saying piracy is good. I'm not saying that content creators shouldn't be rewarded for their work.
All I'm saying is that Mozart didn't "do it for the money". He made music, and he did get paid, but the causal connection is pretty weak.
BTW, for the techies, you are mixing types of people. (As you did before with Newton and Einstein)
Now you're really not paying attention. This may amaze you, but a number of entirely different people post on slashdot. If you have arguments with ones other than me, then you should talk to them directly.
Um. Shakespeare and Mozart in fact did do it for the money, but in general they created works for hire. [...] The Beatles definately did it for money, as I didnt notice them giving away all of their profits and living in poverty.
This is pretty sloppy logic. I know a number of musicians; some of them get paid for it and some don't. But pretty much all of them make music because they want to make music; getting paid is a nice bonus, and much of that money goes right back into the costs of making music.
The better techies I know are the same way. I didn't stay up 'til all hours hacking away on my dad's Apple ][+ because I looked forward to a lucrative career; I did it because I had to. I feel fantastically lucky that I can build cool things and make a living at it. But if the bottom dropped out of the market tomorrow, I'd just have to go out and get a day job to support my coding habit.
I guess someone needs to write some David Irving style Holocaust denial to balance the Holocaust entry. As I said, that policy is stupid.
If that were the policy, it would be stupid. It's a good thing it isn't.
If you had done a little research, you could have seen that their Holocaust page has information on deniers. See the section Historical interpretations.
This approach maintains neutral point of view. The vast majority of historians agree that the holocaust happened, so the article is written that way. However, the article acknowledges the minority view by describing it explicitly as a minority view. Nothing is compromised, and nothing important is left out.
You can see similar approaches being worked out on much more contentious issues, like the pages relating to the Israeli/Palestinian conflict. The discussion pages are fascinating; you can see the process where people are eagerly searching out both the parts where everybody agrees and the parts where everybody agrees to disagree.
So if one contributer feels 2+2=4 and another feels 2+2=6 So then according to the "neutral viewpoint" on the issue, the entry should be 2+2=5.
Wrong. If you had read and understood their page on the topic you would see that they would never do such a thing.
Of course, if you don't how to write with a neutral point-of-view, that would explain why you're putting words in their mouth.
an article would need checking by just one or two guys who know their stuff, not a million monkeys.
And who determines who those guys are? I'm sorry to break it to you, but all you have to work with are monkeys.
If you look at Wikipedia and in particular the discussions linked to each page, you can see the process. It's not perfect, but the content quality generally improves over time. That doesn't sound like much, but it's all evolution needed to make us monkeys in the first place.