|
|
||
David Herron's BlogOpen Source ArchivesGive one Get onePosted by robogeek on December 03, 2007 at 11:26 AM | Permalink | Comments (3)I just saw Tim Bray's blog post about the Give One Get One program. He says "I can’t imagine any self-respecting geek not signing up for this, so I just did.".. I bought my OLPC on the first or second day the program was running, so that must make me a self-respecting geek. Or at least one who respects the nature of the digital divide. And while at one level it seems the last thing local villagers need is a computer, and that their more pressing need are for things like clean water supplies, energy services that don't require burning animal dung, and for adequate food supplies, and for governments that don't actively suppress them or put them into near-slavery (as happens in some countries)... it's hard to look at the effects the Internet has had, and not recognize how the playing field has been leveled around the world. The Give One Get One program is that someone can buy a 'One Laptop Per Child' laptop for themselves, but they actually pay for two laptops and the second laptop is given to a child somewhere in the world. You send them U.S.$399, you get one laptop, and some child somewhere in the world gets another one. What a deal. While I'm here writing about this, on this weeks On The Media (an National Public Radio program focusing on media and media critique) they had a piece on this program. $100 Dream .. discusses how the program hasn't quite worked out as Nicholas Negroponte had envisioned, especially that some places had resistance e.g. it doesn't run Windows. Sigh. They have an interesting 'take' on this program. gphone is doomed? The Open Incompatible Handset Alliance?Posted by robogeek on November 07, 2007 at 12:06 PM | Permalink | Comments (0)There sure has been a lot of words flying around this week regarding the Android (gphone) phone. I've been tracking some items about the gphone and it's pretty wild all the different points of view. It reminds me of that story about the blind men trying to describe an elephant, none of them can see the whole thing so they describe the part that they can touch. Okay, risking being called a blind man, let's move forward and see what's here. Let me start by referencing Terrence Barr's post... Sooo, what about Google Android and phoneME? ... Wow.. And What's the Point of Google's Phone? ... I'm highly skeptical that whatever results from Android will actually change how cell phones are distributed. As others have noted there is a curious absence in the partners in terms of major cell phone carriers. And the cell phone market has a long long long long history of tightly closed phones and tight control. They have a tough row to hoe here if they are to make any headway on the dream of an open cell phone. What I find on the OHA website is rather curious. Like Dalibor I wonder why they didn't wait another week so the SDK would be ready with the announcement. Anyway we'll certainly know much more come the 12th. If the Open Handset Alliance is giving it all away for free, how will the platform be differentiated?Because the Apache license does not have a copyleft clause, industry players can add proprietary functionality to their products based on Android without needing to contribute anything back to the platform. As the entire platform is open, companies can remove functionality if they choose. Applications are not set in stone, and differentiation is always possible. For example, if you want to include Hotmail instead of Gmail, it will not be an issue. Hoooooboy!! Is that a canoworms or what???!? Hey, it sounds very nice and innovative to have the freedom to mix and match and yank features and whatnot. But, hey, compatibility matters. Since we've already lived through this story let me describe how it's going to turn out. "How to avoid potential pitfalls of Microsoft's non-standard SDK for Java" If you remember back, ah, heck, that was almost exactly 10 years ago... my how time flies when you're having fun ... Anyway, what good is an "open platform" (as Android calls it) when customers can't be assured their app is going to run on any random instance of that platform? That is.. suppose Google/Android is successful and there's a couple dozen OHA phones out there. If each vendor is free to remove features and mix and match features, that leads directly to incompatibilities. That leads to an Aunt Millie who gets an OHA phone and wants to install OHA software which then doesn't run because there is no compatibility. What good is that? Granted there are multiple considerations pulling back and forth on this question. For an open platform one obviously wants the ability to innovate. But I think openness also means the end users must have the freedom to install whatever they want, and that requirement means compatibility is important. Clearly I'm viewing the world through the lens of being embedded in the Java SE team. However a couple months ago I posted Java is doomed to failure, referring back 10 years to the Microsoft incompatibility nonsense... And The Unix wars and Java compatibility ... There's a cost to incompatibility. Think of the extra overhead work that's involved with each software project having to reconcile differences between different Unix or Linux or xxxBSD implementations. Yeah there's freedom in the definition of what Unix is that allows vendors lots of room to innovate. But that leads to incompatibilities, and I think of the "configure" script that goes along with most open source projects as a symptom of a disease. Cell phones play a critical role in our lives in that occasionally we face an emergency and need a reliable way to get emergency help. Do we want to risk our lives to a cell phone that works most of the time? Which makes me think of how some try to use VOIP services in place of their regular phone service and run into trouble making emergency calls using their VOIP phone. As Terrence said, "Welcome to exciting times." Let's see where this goes. The Freedom to get a shell prompt on an iPod TouchPosted by robogeek on October 26, 2007 at 11:59 AM | Permalink | Comments (4)A few days ago I bought an iPod Touch.. I've been curious what the buzz about the iPhone was about, but as I have a year still in my Cingular contract I didn't want to get an actual iPhone and the iPod Touch is an interesting compromise. At first I was wowed by the user interface, its responsiveness, how well it responded to flicks of the fingers, the video quality (e.g. playing podcasts), etc. At the same time it's a rather limited device. The UI has some flaws in what's available and the choices you're given. And the functionality out of the box is very limited just to the things Apple thinks you want. Okay, so they've put some interesting functionality in it. This phenomena of unlocking iPhone also extends to the iPod Touch. A bit of yahoogling led me to an application named iJailBreak and I finally had a script-kiddie experience of downloading some canned script which exploits a security hole. The iJailBreak has you visit a given web page that then makes the Safari in the iPod crash.. and having crashed in a specific way the iPod is then opened so that software can be squirted into the gadget. Within a few minutes of breaking my iPod out of jail.. ah.. I had the distinct pleasure of looking at a shell prompt (green letters on a black background) on the screen of my iPod. So.. yeah.. I spent $350 to get a sleek black gizmo that.. has a Unix shell prompt. Hurm.. Well, there are other applications besides the terminal window. Such as MediaCast, an app that directly downloads podcast content rather than forcing you to use iTunes to get podcasts into your iPod. But it's that terminal window which demonstrates an interesting train of thought that itself demonstrates an interesting principle. We are tool-using animals. We look for tools to help us do the things we desire to do. I think our essential nature is not "consumers" but "tool users" and "tool builders". A "consumer" is passive and accepts whatever is put in front of them. A tool user/designer is not satisfied with the status quo and looks for ways to improve their life. My posting from a few days ago about open source green vehicles is an interesting case in point. The consumer part of society accepts whatever car the car makers provide. Even though the vast majority of people want a clean environment etc, the car companies only provide cars that burn gasoline or diesel derived from fossil fuel and which clearly has bad environmental effects. As passive consumers what are the people to do but buy whatever is made available. The shell prompt on my iPod shows a different direction. Not being satisfied with the status quo I'm building myself an electric motorcycle. Not being satisfied with iPod Touch's as Apple designed them, some people have made available the iJailBreak (and other) applications along with a suite of app's that can be downloaded into the thing. In general the direction both of these point to is the essential nature we have, if the status quo is not acceptible, that we are tool designers and we can remake the things in front of us to attempt to solve problems we are facing. The companies that make gadgets have gotten into the pattern of strictly controlling what the gadget can do. When a gizmo is a hammer, well, there's only so many things you can do with a hammer and as the saying goes if you have a hammer in your hand the whole world begins to look like a nail. But today computerized gadgets are proliferating and they beckon with the ideal that because it's computerized it can serve any purpose you want it to do. But there is a tendency in makers of gadgets to control what the gadget does. Consider some of the gadgets made by Linksys.. a couple of which were built using the Linux kernel, a web server, and some ethernet hardware. Linksys wanted to sell a closed box but some people took it on themselves to work out the tricks to installing more software on these gizmo's than Linksys really intended. I once bought an NSLU-2 and hacked into it using software from www.nslu2-linux.org ... that was interesting and you can install a wide range of stuff on the slug (like mysql). I don't understand gadget makers and their insistence to control. I think that if a gadget maker puts together some really useful hardware design, that the ability to customize the software ought to positively impact sales of the gizmo. A customizable gizmo is more useful to me than one with set-in-stone features. For example while I find digital cameras generally very useful and offering a far more flexible picture taking experience than the film cameras of the 70's ... digital cameras have a locked down and controlled featureset. There are things one can imagine doing with a digital camera, which the camera makers don't provide in the camera. You can yahoogle "hack digital camera" and find some useful resources, fortunately. But I think a digital camera with e.g. Java in it, that supports installing whatever Java app you want into the camera, that would be very flexible. I've been reading a lot of articles recently with excited guessing over what Google will (or won't) do for a cell phone. It's curious that the guesswork sounds a lot like the guesswork circling around the iPhone before it became a concrete thing people could buy in stores. I think the speculation on Google's gPhone (or.. e.g. with JavaFX Mobile we at Sun could have a jPhone product) ... it's really coming from the same thread of thinking I have here. That we as tool using and designing animals, we see these computerized gizmos, the modern cell phone for instance, and we want it to do anything because that's the ideal form of computerized gizmos. That you can install any software you want and make it do anything. But the history of cell phones has been tight control by the carriers, right? Just because we as individuals want our portable computing devices to be extremely flexible.. does that mean Apple or Google (or Sun, for that matter) will actually provide the infinitely customizable portable computing device of our dreams? I have a nagging concern here. It's highly related to the Network Neutrality debate that's gone the last year or so. Freedom is more than a word. Freedom is the ability to choose any action, think any thought, etc. But when gizmo makers sell us controlled devices or controlled services or limit our choices etc.. they are limiting our freedom. In the book 1984 Big Brother was thought to be an overbearing government bent on dominating us all. What if Big Brother is instead corporations limiting our choices and forcing us to spend money to feed the corporations? Is that our sole purpose in life? To feed money to corporations? I think not.. Oh.. wait.. I just got a paycheck this week. Hey everybody, forget what I just said. Please go to store.sun.com and buy a few servers so that they can afford to pay me in two weeks... Open source green vehiclesPosted by robogeek on October 23, 2007 at 05:52 PM | Permalink | Comments (2)I'm a bit obsessed by electric vehicles and green transportation in general. There's a lot of reasons behind this, from global warming to climate change to global economics to health to stupid illegal wars in the Middle East etc I just see reason after reason why "we" need to move to using different/better ways to move our butts around the world. Normally I post about this elsewhere but I just learned of three projects to build "green" vehicles, as open source projects. I have the projects linked here: Open Source Green Vehicle The Open Source Green Vehicle is working on an open vehicle platform, and their hybrid electric vehicle just reached: Upcoming Preliminary Design Review (PDR) for SSM’s Kernel™ Hybrid/Electric Crossover. The Kernel™ Crossover design is flexible in that it allows any power source to be plugged in so long as it conforms to certain specifications. They have their own license (SSM-OSGV Open Design License Agreement) which probably is not OSI certifiable, and has some interesting aspects. Rather than specify every part in the vehicle must be open source and completely open design, instead all interfaces to each part in the vehicle must be openly documented. The parts may have closed source innards, what they're requiring to be open are the interfaces. While this isn't following the purist open source model it may be good enough for the goals to be achieved. However this does fall into a version of the (hopefully soon-to-be-defunct) 'Java Trap'. The 'Java Trap' being Richard Stallman's description of the quandry faced by an open source software project implemented in Java. So long as Java was not open source the OSS project had limits to its freedom. Even now with the OpenJDK project nearing a fully open source unencumbered existance, the specifications that make Java are not themselves open source, nor could the JCP process be described as "open source". One step at a time, hopefully. This limitation to freedom will apply to the OSGV project as well. I raised this issue in the Open Source Battery Project for Electric Vehicles ... they say they don't care to be that purist. For example Texas Instruments makes charge controller integrated circuits for Lithium-ION batteries, the IC chip is obviously closed source proprietary to TI, and if TI were to stop making that chip then the OSBP4EV project would be stuck, but they said they're okay with this. The Electric Auto Association - Plug in Hybrid Electric Vehicle was said by Green Car Congress to be an Open Source project to create do-it-yourself plans for plug-in hybrid conversions of existing hybrid vehicles. Among EV fanatics like my self the saying is "it's not electric unless you can plug it in" and no matter how much the existing hybrid vehicles improve our world, you are still 100% addicted to gasoline while driving one. The plug-in hybrids are different in that the battery pack is large enough to drive the vehicle for a significant enough distance at a useful speed, and that the battery can be recharged by plugging into the power grid. Electricity is everywhere already so why not use it to power our vehicles? My Open Source Electric Vehicle is a diary that appears to be about building an electric motorcycle. I oughta look this over since I'm also building an electric motorcycle (My Lectra project). The c,mm,n Open Source Car project .. er.. I wasn't able to make much sense out of the web site (it's a flash only site) but a posting on autobloggreen claimed they're an open source project. (The open source car, known as the c,mm,n is powered by hydrogen) The OScar Project is showing on their site a reverse-trike design (3 wheeled motorcycle with two wheels in front, one in the rear). In the U.S. these are registered as motorcycles which means they have very little safety testing as compared to the rigorous testing done on four wheeled vehicles. The safety testing requirements is on the one hand a blessing because our cars are generally safe (depending mostly on how dorky the driver is) while on the other hand makes for a barrier to entry for small companies to begin selling vehicles. The OScar site doesn't describe (that I can find) the license, and it appears the project is struggling along with getting enough involvement to make much progress. There are significant challenges to designing a vehicle to use on the road. Vehicle safety and testing is clearly a huge challenge and very expensive .. in the U.S. this involves crash testing, meaning a vehicle designer must have deep enough pockets to afford crashing a few cars until the D.O.T. is happy with it. Doing such a project in open source only adds to the challenges. To be purist on open source and require that all parts are open source... for example the D.O.T. certifies parts like lights and such, and to take "open source" all the way down to designing light bulbs as open source would be a long detour. I think OSGV's stance of requiring that the interfaces be openly specified is a good middle road to take. For example.. batteries are the achilles heel of electric vehicles. There's no way the battery companies will any time soon make open source battery designs. If you think it was hard to get Sun to embrace open source, try looking for details on how batteries work much less having replicatable open designs for batteries. It's much more practical to rely on batteries being widely available from several manufacturer. While this is true for lead-acid batteries when one gets to the advanced battery chemistries you begin to have single vendor solutions. Opensville?Posted by robogeek on April 28, 2007 at 08:45 PM | Permalink | Comments (4)Welcome to Opensville, Population Zero is a blog that's been referenced by Slashdot right now. It's an interesting blog posting. I've never heard of this William Hurley, but he has an interesting thing to say. When I started with open source, in the 1980's before the phrase "open source" had even been coined and Eric Raymond was still living in Texas (if I remember right) ... there was little of big companies making anything off the software we passed back and forth over the network. It was all freely shared, the kind of nirvana whurley refers to as opensville. The parks are beautiful, the shopping is amazing, and the nights are pure Vegas. Sounds like a great place, huh? But, he says, nobody wants to live there. hmm, seems that in the 80's anyway all of us who were on the Internet did live there. The later commercialization of the model does seem to have changed a few things. But as a Sun employee it cannot escape my mind hearing our past and current CEO's both saying Sun was founded upon open source software. They claim the original Sun OS was based on the "Open Source BSD distribution". Hmm, that's always struck me as a strange claim because to get the BSD distribution one had to possess a valid AT&T Unix license, which absolutely was not open source. Further the BSD distribution still had some AT&T code in it. It wasn't until later that some people whose names I've forgotten worked to de-AT&T-ize the code to make the first 386bsd distribution. And that led AT&T to sue UC Berkeley. So tell me how the BSD distribution of 1982 was open source? Maybe Bill Joy et al took only the bits which were BSD licensed and worked to fill in the gaps with code written by Sun employees? If so then why did Sun later buy a perpetual Unix license from USL? Anyway, getting to the current time. There is clearly a mix of styles of interaction between various companies and the various open source projects. Clearly there are some companies who, as whurley says, act as leech's only taking code and not giving anything back to the project who maintains the code. Just as clearly there are some companies who participate in the projects from whom they get the code they turn into their products. He asks What separates legitimate use from outright exploitation? And I'm astonished... Clearly the open source licenses allow for this situation to exist. Clearly the open source licenses generally do not require that changes be fed back to the project. Clearly the open source licenses generally allow for the recipient of code from a project to do pretty much as they wish. After all, one of the core tenants of open source software is the freedoms which are granted to the recipient of the code. He goes on to suggest some kind of rating system that I suppose he wants to use to punish the moochers. I think there is an informal system like that ... e.g. I think one of the network router gadget makers is known to be using open source code but not abiding by the licenses and making it hard for the community to fiddle with the open source software that was used to build those boxes. And that some are saying they boycott that company, because of that product. And, of course, it is his right to agitate in any way about perceived misuses of open source software. But, I ask again, if the license allows for this then is there any real room for complaint? Even more interesting is the impact this idea has on one of the age-old arguments in the open source community. That is the relative worth of the various types of licenses. The BSD-versus-GPL debate has been present with us since at least the 90's maybe the 80's I kind of forget when I first saw that debate raging. And the debate is with us today. But getting back to whurley's blog posting ... the BSD license explicitly allows for corporations to mooch off open source projects without returning anything to the project. The GPL license on the other hand tries it's darnedest to make mooching hard. Which just reminds me of a posting I read once with someone talking about the open source license they prefer ... they prefer everybody elses code to be under the BSD license, but they prefer their own code to be under GPL. It's easy to imagine a corporate manager who's just invested $n million in engineer time and other resources to beef up a piece of open source software. How happy is that corporate manager to be about sharing the results of that investment with "the community"? Is the corporate manager going to grasp what that means? Or is the corporate manager going to see overhead, wasted resources giving something to these other people, and perhaps even seeing an advantage fly out the window? Clearly there is another viewpoint the corporate manager could take. For example the longterm maintenance of the code is enhanced if they feed their changes to the main project. If they instead hoard the changes they have effectively forked the project, and then they have the overhead of maintaining the fork. Depending on how widely the fork varies from the main code that can become a huge headache. Open source project maintanencePosted by robogeek on June 14, 2006 at 03:12 PM | Permalink | Comments (5)You may have heard of this announcement "it's a matter of when" .. well, that's turned into a lot of planning and meetings and discussions inside the java team. I haven't been able to post any blog entries, because my time has been consumed with those discussions and there's basically very little I can say because of the nature of those discussions. But what just came to mind is an open source project I once led .. long before the phrase "open source" had been invented. And, how I contributed to the death of that project due to mishandling its governance. In the 1980's I was a system/network administrator at the University of Kentucky Mathematical Sciences department. Our systems became known as ukma when we joined Usenet in 1985 or thereabouts (which I instigated), and later became known as ms.uky.edu when we joined Suranet/NSFNET a couple years later. One of my roles was running the CSNET connection that, before we joined NSFNET, was the primary path our email took to get onto the Internet. In the 1980's the Internet Service Provider business had not been invented until UU.NET and PSI.NET went into business around 1990. Because of our CSNET connection I had configured our systems to use MMDF rather than the ubiquitous Sendmail. It was my considered opinion back then that Sendmail had a horrendous configuration file which didn't make any sense, while MMDF's configuration was rather straightforward. It pretty easily handled interfacing to multiple email channels, writing email addresses appropriately for UUCP or BITNET or CSNET or the Internet all with little fuss other than understanding the configuration file details (which were tons easier than Sendmail's). MMDF began life as a project by Dave Crocker to supply an MTA to the Defense Department. At least I think that was the history. In any case by the time I learned of MMDF, CSNET had adopted it, including handling maintainence. In modern open source terminology, the MMDF project had migrated from Dave Crocker at the Univ of Delaware to Chris Partridge and a couple others at CSNET. I, and my U of KY colleague Ed Bennett, did so much work to fix bugs in our copy of MMDF, that the CSNET team then handed leadership of the MMDF project to us for further maintanence. We handled the project reasonably well for a couple years. But then we graduated. Ed got a Masters in EE while I got a BS in CS. We both ended up working for The Wollongong Group. Our job was to create a commercial MTA for the networking world of the early 90's, derived from PP, an MTA that handled both the RFC-822 Internet as well as the X.400 ISO world. In the early 90's the X.yyy world of ISO standards was supposedly going to take over networking, but fortunately the TCP/IP Internet won out and the ISO standards are merely an asterisk in network protocol history. That is, except for LDAP which derived from X.500. Our availability to continue MMDF maintainence went to around zero, partly due to time commitment to our employer, and partly because we didn't have system resources to continue MMDF testing and development. What we should have done, and eventually did, was to hand off maintainence to someone ... but we didn't, for whatever reason. That meant a long dry period where the project was not maintained. I kept receiving bug reports and fixes, but could only file them away into the MMDF mail folder hoping I could have some time to work on it. Time which never came. There were no updates, and the user community dried up. By the time we handed off MMDF maintanence it was too late because the user community had largely gone away. Due to mishandling governance a worthwhile project (MMDF) lost momentum. I'd like to think that MMDF could have taken a place alongside Exim, QMAIL and Postfix as a viable Sendmail alternative. Getting back to today ... I'm participating in meetings about open sourcing the Java source, governance models, infrastructure needs, and on and on, and this gives me pause to think about that ancient history. Followup to my experiment in community processPosted by robogeek on October 18, 2005 at 04:42 PM | Permalink | Comments (2)A couple weeks ago I did a little experiment in community processes. Supposedly community driven processes are better quality because there's more eyeballs. That's an interesting claim, and I wanted to test it. The Register has an article along the same lines as my test: Wikipedia founder admits to serious quality problems My test is written up here: An experiment in community process Basically, was reading a book about collaborative development processes and remembered an article I saw several months ago about a test of the wikipedia ability to fix their encyclopedic project through their own community process. In that test someone posted a bogus article expecting the wikipedia community to notice it and do something about it. When they didn't notice it after a week the guy went "hmmm...". In my test I posted a bogus article, specifically a randomly generated computer science paper. I wanted to test that community to see how responsive it is. This time the wikipedia community came through and within 18 hours my article was gone. It's kind of mixed results. In some cases bogus articles stay in place, and in others they get deleted. However the Register article weighs in with their analysis that there's a lot of problems with the community process on the wikipedia, with the evidence being the large number of questionable articles. Well, I haven't made a deep study of the wikipedia, but the articles I've looked at were generally good. That is, except for the ones related to a peculiar niche interest I have in "energy healing" (See peaceguide.com or reiki.7gen.com for some resources that demonstrate what energy healing is). The related wikipedia entries are rather spotty, but it's such an out-of-mainstream niche one would expect poorly informed articles. One thing the Register article talks about is the tortured quality of the writing in general. I suppose that's a direct result of the communal process, since you've got hundreds of volunteer editors running around each tweaking what other people have already tweaked. That's surely a recipe for strangely written prose if I've ever heard of one. Looking at it from my perspective in the Java team, I can't help but think about different software development models. You've got open source projects and their collaborative development model, and you've got the Java team with it's long-standing largely closed development model that we're searching for a way to open to the larger community. The open source advocates claim the collaborative model is better repeating mantras like "with enough eyeballs, all bugs are shallow". I'm interested in actually testing this claim rather than accepting it on blind faith. The result with the wikipedia quality gives me reason to doubt that a collaborative process is going to always result in high quality. As another test I'm looking a little at the Hibernate project, and using the Findbugs tool. I'm really getting familiar with using findbugs as part of a normal software development process, but I thought to also run it on several versions of the Hibernate build. I've only just begun this but I did find something very interesting. Namely ... in Hibernate 3.0 there are several very shallow bugs ... which all the eyeballs in that project did not find. For example code like if (obj == null) { throw new SomeSpecificException("unknown object " + obj.toString()); } Clearly that code is going to throw a NullPointerException rather than the specific excpetion the author of that code expected it to throw. Clearly no software development model is perfect, and bugs slip through the cracks of every software development model. An experiment in community processPosted by robogeek on October 09, 2005 at 09:40 PM | Permalink | Comments (1)On friday I was reading some discussion about open source projects. Among the claims was the typical statement that the thousands of eyeballs results in high quality. The assumption is that with that many people, there is continual ad-hoc testing going on and any problems get spotted quickly. Well, I don't think that's actually the case. First it presumes the project has a lot of active participation. Projects with few participants don't have thousands of eyeballs, do they? The way the model works is if there are thousands of users each doing their thing, who then effectively serve as an ad-hoc test team. Having few users means the daily usage of the participants doesn't cover much of the code, and there could easily be bugs lurking in the corners. The second presumption is that daily usage by the thousands of users is going to cover a large part of the code. Any quality professional knows that valuable testing has broad coverage of the code being tested. Your testing only validates the code the tests cover. If you rely on the users to run the software and effectively ad-hoc test it for you, but if they all have the same or similar usage, they're all going to be hitting the same lines of code. Hence, there will be bugs lurking in the corners. So in any case, let's get back to my experiment. When I read that on Friday I thought "let's test this". I'd remembered a slashdot story several months ago of someone posting on the wikipedia a bogus/random article and then waiting. The Wikipedia is supposed to have the same advantage that open source projects have. Lots of eyeballs and the ability of anybody to change/edit anything. One thinks this would lead to chaos, but the wikipedia shows that it actually leads to a pretty good result. For the most part the wikipedia has a lot of good information in it. However in that experiment mentioned on slashdot, the guy left the article there for a week. Nobody touched it, until he deleted it himself. Hmmm.... so much for the wisdom of the masses? So, here's what I did for my experiment. First, I took this article Hash Tables Considered Harmful from my personal web site. This is a randomly generated computer science paper that comes from some software also previously discussed on slashdot. The final citation to the paper links to the software. Second, I created myself an account on wikipedia. (Robogeek) Third, I posted this article. It took me quite awhile to clean it up for the wikipedia formatting, and I dropped the images because I didn't want to pollute the wikipedia more than this one article. Fourth, I waited. The article: You'll notice the article is no longer there. It was deleted within 18 hours of posting the article. Heh, "Patent nonsense - and a lot of it", why thank you. Anyway, this experiment shows that in this instance anyway the wikipedia community process worked. | ||
|
|