Slashdot Mirror
Open Source Course for Managers?
faqmaster asks: "I teach systems analysis and design as part of programming and project management tracks at a community college, and I'm interested in putting together a course for project-managers on open-source software. What suggestions would the Slashdot community have as far as what managers need to know/understand about Open Source? What books would you suggest? Anyone have any especially good case studies of successful OSS implementations in the business world? Any insight as to how project managers and the like can successfully incorporate open-source into thier projects? What advantages might they see? What are the pitfalls?"
Comments in the source-code are the most crucial thing for any serious company looking into open-source...if they want to customize their software they need to be able to understand it.
-Chardish
Make sure to mention the fact that open source developers have access to tons of already excellent code, making the development time much shorter. :)
I hope that this is true...heh
Now for buzzwords. They need to hear that it is scalable, robust, and will boost productivity.
And they need to know about programs such as StarOffice That are in a great many cases, better then Microsoft Office, along with offering compatibility with existing systems. In short, there's almost nothing that a large firm puts out that cannot be replicated in an open source enviroment.
01101001 01100001 01101101 01101110 01101111 01110100 01100001 01101100 01100001 01110111 01111001 01100101 01110010
Describe the license differences... that way they'll know which license fits specific projects... Then tell them that open source does not have to be platform specific...
-- Jim
Keep teams streamlined. By consolidating work into a smaller group, you can reduce the number of necessary meetings and the amount of time spent trying to keep everyone informed.
Define terminology. When you begin working on a project, nail down work-related definitions and make sure everyone involved understands them.
Document decisions. Any time you and your team makes a project-related decision, write it down. Include an overview of the rationale behind the resolution.
Group project deliverables. For long-term or ongoing projects, you can reduce project-management administrative burdens by delivering work in batches.
This will reduce the number of times that you need to contact your client and will allow you to consolidate feedback sessions and next steps.
Rework notes immediately. After you finish project meetings or phone calls, review your notes immediately and fill in details you remember from the session but did not write down. At the same time, make a list of next steps and mark the date they need to be completed on your calendar.
Keep everyone informed. Nothing is worse for a project team than to be left in the dark. Morale will drop quickly if team members complete work, and then discover the project has shifted direction and their efforts were for naught. Missteps like this also waste project resources, lengthen timelines and increase costs. Make sure the communication processes you have in place keep everyone informed. It is better to copy people on e-mails that may not directly affect them than to leave them off these communications completely.
Set realistic expectations. Project success is often measured in three ways: on-time delivery, high quality and reasonable cost. A typical project will allow for two of these items to be achieved, so while it's important to reach for all three goals, good managers prioritize them. They know that if they want a project on time and at cost, the level of detail they can hope for may slip. Likewise, if they want high quality at a low cost, they may need to stretch timelines.
If you celebrate Xmas, befriend me (538
only users and hackers....tell the managers to read all the man files and create a powerpoint presentation to sum up open source, that ought to keep them busy for awhile.
"The Most Fun Possible on 4 wheels" is at SunBuggy in Las Vegas
Start interviewing project leaders of popular software titles at Freshmeat or Sourceforge.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Assuming you are up against the "free" prejudice (nothing good is free), one of main points of emphasis would probably be the quick release / report / revise cycle that a successful, widely used OSS product enjoys. Major (or minor) flaws are quickly discovered that might not appear during even a rigorous bug-hunt by the developers. Given that OSS makes the source available, any customization needs can be handled in-house if necessary - flexibility is the key .. would you
rather wait for a corporate entity to raise itself from the rust to release a patch or a new revision, or adopt an OSS product for use that allows you as granular a control as you need?
Without any overriding reason to use a non-OSS product, the choice would seem obvious, all other things being equal.
I'd like to recommend Open Source Development with CVS
as a good starting point.
I was very surprised a while back to read these articles on a big companies actually saving a lot of money, and one of them is none other then Intel! The article details about how Intel was inspired by Napster and switched some stuff to linux. From the article:
"Free operating system Linux was another unexpected result from ad hoc Internet collaboration embraced by Intel, saving the chipmaker $200 million," Busch said. The company ditched expensive Unix servers with proprietary Unix software and replaced them with cheaper servers equipped with Intel's own chips that run Linux software.
Amazon also made the switch In some ways, this is even better.
Online retailer Amazon.com shaved millions of dollars from its technology costs last quarter by switching to the Linux operating system, a disclosure that could provide some guidance for other companies seeking to cut expenses in a stagnant economy.
Provide guidance for other companies? And the title, "Linux saved us millions." Sounds great to me. At least some corporations finally seem to be learning that OSS does have advantages, and they can in many cases be spelled out in nice, crisp greenbacks.
- How to get involved
- An email from an Apache developer that explains how he got started
- Project Guidelines
- Understanding Opensource
Yeah, ok I'm a karma whore. Still, if it helps this guy what's the harm?That which does not kill me only makes me whinier
Many companies, including Cisco where I work, have made strong use of open source software and deployed it extensively - this is different from developing it. Make sure you deal with them separately.
All the problems that exists in traditional software development, also exists in open source plus some new ones because of communication and distributed control issues. It's not like you can easily fire an open source developer (and that is good
A manager who uses open source software should know how to help his/her team get support. Showing them a working example of a bug being fixed from a user mailing list for some software product might be helpful. After they see it work once, they might be the first to browse the archives for help with a problem encountered by the team.
Communism fell with the Berlin Wall, no matter how much Richard Stallman and comrades might want to bring it back.
OSS is just like any other aspect of business..there will be pros and cons, advantages and disadvantages to an OSS solution to a problem. These all need to be weighed to decide if OSS is the right way to go for a particular aspect of business operations.
A lot of the problems I see with the ManagerOSS business relationship come down to lack of information. Let's face it, if I were a decision maker with a clearly defined solution on my left hand with well understood capabilities and limitations and I was weighing that up against a (potentially much better) solution on my right hand but with poorly defined risks etc. then I'm going to go with the certainty.. Imagine the inquisition if a gamble failed on something where I hadn't characterised the risks!!! I like my job!
Contrary to popular opinion, a great many managers are smart people - they can weigh things up when they're given the information. If they don't get the information they're frequently too busy to go search it out for themselves, so instead they default to the safe option...even if it's sub-optimal.
So, explain the various OSS licences and their capabilities and limitations (especially the differences between GPL and BSD type licences). Explain the 'ethics' of the OSS community and *how* and *why* people build OSS code (often the most difficult thing for BusinessHeads to get their minds around). Then (the most difficult bit) explain _clearly_ and _without editorial_ the limitations of OSS and how these might be contained in the particular circumstances you face.. then you might find you get a pleasant surprise from some of those higher ups...
I'll admin I have second hand knowledge about project management, but I learned what I know from those that are/were very good at it.
Most people in a team/project enviornment fall into one of these catagories:
1) Coder; the one that can hack code like there is no tomorrow.
2) Cheerleader; the person that "cheers" everyone on and tries to motivate everyone.
3) Idea man; a person with a gift of "thinking outside" the problem. Usually very smart and somewhat competent as a coder/pseudocoder. Usually thinks of everything except the "how" to do something.
4) diplomat; Usually the project manager him/her self. The one that can "herd cats" or talk to the previous 3, iron out differences and balance all the powers of 1 thru 3.
The more you think about it, the more it is dead on. I've had the advantage, if you will, of observing several teams after learning this little tidbit. Once you see it, you can not un-see it.
The point is: You need all of these types, period.
As the PM you need to recognise these talents reguardless of working in person or via email/IM or whatever communications are your norm.
I give you Linus and Bill G. as prime examples.
They know how to motivate people by using their natural talents, they both know when to say "good job", "work on it some more" or (bill g, IIRC) "that is the stupidest fucking thing I've ever heard of".
As a PM you have the most challenging job, but have to realise that w/o the 3 types, the project is hobbled or dead.
Example of MS/FSF, again offers plenty of insight as to what goes right/wrong with development.
With MS, the divisions are political, social, and idealogical.
With Free Software, timezones/distance, language barriers and occasionally egos.
So, if a book is not around to help, go to a university nearby, and see these dynamics for yourself.
Never know, you might be the one to write the book yourself, with or without the help of a psychology and computer sci. phd.
Cheers,
GISboy
If it is not on fire, it is a software problem.
I've been slowly integrating GNU/Linux into my company, but it's been a struggle. I work in an IT training company who are used to Microsoft fulfilling all their needs. They've become so used to Microsoft, their fees and their wide range of integrated products, that the notion of going with something as radically different as open source or free software just seemed ridiculous to them at first. No matter how many big names I mentioned (IBM, Sun, the EU), they just thought it wasn't for them.
I think that to start with, The Cathedral and the Bazaar is a good read. Though it's a little outdated, being somewhat in the dot-com mood, it offers some well reasoned argument behind using open source methods alongside more traditional business practices. But the real hurdle is convincing people that software written by "amateurs" (because that's how they often see unpaid programmers, unfortunately), and distributed for free, can be reliable and powerful. You also have to impress upon them how easy it is to integrate open source with their current goods, to get them out of the mindset that offices have to have Microsoft-everything.
One thing I would say is that most managers, unless they're in financial difficulties, don't jump at the "it's cheap" idea.
Teach them what commercial advantages an open source strategy can offer. For example, most managers don't understand why it can be advantagou s to allow people to copy the software. They see it as a loss in (potential license) profits. But in reality this (increased) use of your company's software will draw more customers to you who want custom changes to the software. Often the profits for these custom changes are more interesting than the alternative (license profits).
While commenting code can be extremely valuable, it is often done as an afterthought. In other words, instead of abstracting, grouping, and naming (e.g., functions, variables, etc) the code properly at the get go, so that comments can be of significant value, comments are very often thrown on top in a manner that is of little help or, worse yet, is simply incorrect and confusing. Often times it's simply not possible to comment in a meaningful way until the code is properly designed. Ergo, I think most programmers are better advised to write clear code first and worry about the actual act of commenting second. My two cents.
I wrote the book "Embracing Insanity: Open Source Software Development" to educate management about the ways of Open Source. It deals less with project methodology and more with the social dynamics of the community, but you might find it helpful.
Here's a pointer to the Slashdot book review of it.
I started a project that I call OSS-Leaders for OSS project leaders a few weeks ago. The idea is to create a place where OSS leaders can exchange ideas. It sounds like a simple idea, but when I was leading an OSS project and needed some advice from my peers I discovered that there really wasn't anything like this.
/. email if you have any questions or suggestions.
It is really just a (closed, moderated) mailing list right now, but I hope to distill some of the discussion into some sort of "OSS Leadership How-to" or something.
It is still in the preliminary stages, but we can't grow without members . . .
If you are the leader of an OSS project I hope you will check it out!
Feel free to mail me at my
-Peter
PS: I use "OSS" above because the project is about the process (as opposed to the philosophy). Truth be known I tend to be a "Free Software Guy" but the project is intended to be agnostic about the OSS/Free Software debate.
Although it (in later chapters) assumes a more organized and linear organization than many OSS projects, I'd highly recommend "Code Complete" (full title, "Code Complete: A Practical Handbook of Software Construction") by Steve McConnell. The bulk of it is essential for good coding.
/.) Microsoft Press but this is BY COINCIDENCE, a mere accident of fate! Please do not doom this work just because of this quirk of fate! It really is an MS-free book, guaranteed pure.
Described simply, it tells how to design then write good code and code pieces, and how to document without the usual burden of "oh, rats, I guess I have to document now". Among his suggestions is to use your outline and/or pseudocode _as_ the documentation, by just filling the code in, rather than seeing documentation as a seperate step. If it's good enough for you to code by, it's probably better than any after-the-fact retro attempt at documenting.
He also deals with managing code projects that have high programmer turnover, very relevant to OSS.
The ISBN is 1-55615-484-4, ignore who published it. Seriously-- it's from (he shudders to say on
Actually, all programmers should read it.
A.
There's a high probability that your company already uses free or free-derived software. If you're running an Apache server, there's an example. Run Perl scripts? Perl is vital in my workplace, but I bet it never occured to your boss or many of mine that people gave them Perl. Similar if you use gcc, but there are proprietary alternatives to gcc. If your boss is one that "might get it", you can even talk about how useless Windows was/is if it didn't have all that BSD License code to lean on.
First, I'm going to assume that what you're talking about is projects that use OSS, rather than projects that generate OSS.
At AdAce (shameless plug), I pressured my CEO to let me build the website on top of OSS tools and systems. It was a relatively easy sell at the time, because I (the CSO) and the CTO were both OSS enthusiasts, and we got a lot of respect from our CEO for our technical expertise. This wasn't one of those micromanaging CEOs that some companies have.
Now I'm both CTO and CSO, and I'm quite happy with the result of using OSS wherever possible.
The website linked above is built on top of Apache, Linux, GIMP, MySQL, mod_ssl, and smail. We use gcc and all the other g-tools to build the beast. (We wanted to use PNG for all our graphics, but IE's support for PNG is just too horrible.)
Our system has only two pieces using closed-source closed-source software.
The first is the library provided to us by our credit card processor in order to communicate with their systems (signio, now bought by verisign). But that library was built using ssleay, and knowing that I was able to patch up the binary library to avoid certain SSL attacks against us. (thank you, ssleay!)
The second piece is our ad servers (realmedia). We chose closed source ad servers because we needed a certain set of features, and the OSS ad servers out there are too far behind in that feature set for us to use them. We could have added the features we need, but that would've but a huge engineering burden on us that we couldn't afford at the time. Now that we've come far enough, we're evaluating the current OSS ad servers to see which one we're going to adopt, and add the features that we need (and, of course, commit those new features back to the project).
The selling points that we used to push the OSS point are:
1) The security of an OSS project is superior to the security of a closed source project. This is because either the security holes are found by other people and patches are submitted back to the project, or I (whose duty it is to analyze our security) can find the problems and fix them. While with a closed source project, this is all dependent on the very busy engineers at the software's vendor, who will always prioritize security below where we would want it prioritized (we want it to be the #1 priority). It's so nice to be free of worrying over priority conflicts between us and a software vendor.
2) The stability is superior for the same reason.
3) Licensing fees are trivial. For most OSS projects, licensing is a voluntary donation to the support organization, and the size of that donation is up to us to determine. For other OSS projects, licensing is free. The only real exception is MySQL, which has specified certain donation levels which, nevertheless, are far lower than competing database software's license fees.
4) When (not if) the vendor of a closed source project moves on to other projects, and abandons the software that we're using, we're screwed. But if we use OSS, then we've got the source code, and can continue to support ourselves. Plus, when that happens, we've developed enough internal expertise with the software that it's not too difficult for us to support ourselves.
Apache, in particular, has been a huge boon to us. It's so easy to write modules for Apache that we've got our server packed to the gills with custom modules to perform certain session management and dynamic content tasks for us. These have improved our website's speed and maintainability by a huge margin. (some of these modules have progressed far enough that we're nearly ready to contribute them back to the Apache project.)
In hindsight, we made one big mistake with our OSS work. That is, whenever we brought some new OSS project on board, we would assign it to one engineer, and that engineer was to become our expert on that system. We spread this load around so that no one engineer would be overburdened. But what we should have done (in addition) was to have a "debriefing" a couple weeks after the assignment, so that that engineer could brain-dump a portion of his expertise into the rest of us. As it happened, we had engineers leave us (which is the usual case in engineering) who were the only people with expertise in a particular piece of the puzzle. And when that happened, we were left scrambling to redevelop the lost expertise. It all turned out ok, but it might not have.
These days, as a large result of using OSS wherever possible, we're in a very good position. Nearly all of our competing ad networks have abandoned the market for greener pastures, and that includes every ad network that's bigger than us except for 24/7 and doubleclick. The other big guys have switched to licensing their proprietary ad servers to other ad networks. As a direct result of our adoption of OSS, our total monthly technology costs are trivial, and we can survive comfortably on a truly tiny number of sales in a month. Having leaned heavily on OSS software, we were also able to focus a lot of our engineering on automating the administration of our system to a large a degree, so our administrative burdens are also tiny. This is letting us ride out this deep depression in our industry without worries, and when things turn around we'll be in a very enviable position.
The only downside to OSS is that there are a large number of licenses to read and discuss with our legal department. This number is, of course, similar to the number of licenses that we would be under if each individual portion of our website used equivalent closed source projects. However, closed source projects tend to bundle multiple pieces together under a single license, so we would actually have fewer pieces (and hence fewer licenses) if we used closed source. What's worse, many OSS projects use licenses that are superficially the same, but contain modifications that are specific to that project. So, though it's tempting to read the opening clauses and conclude that the license is the same as this other license that we already analyzed, it's foolish to do so.
But the bundling phenomenon of closed source projects is actually a disadvantage. Since no closed-source project satisfies all our needs, we would definately need multiple. And if different closed-source pieces overlap in their bundling, then either we have to reject a piece that we'd like to use, or we'd have to find a way to disable the pieces that we don't want to use. That's always a pain.
-- Nolite audere delere orbiculum rigidum meum.
Well, the Internet for one. Wouldn't really exist or work that well without BIND (opensource), Sendmail (the killer app, opensource), NCSA httpd and mosaic (the next killer app, you know, all that "web enabled" stuff).
OpenSource has more then a few times created new markets, like UNIX (if bell hadn't shipped source code around no-one would have improved it much and it would have stagnated). Like the Internet, imagine if we were stuck trying to use protocols like DECNET to try and network a few hundred million machines together. Like all these nifty information transfer protocols such as email, www, and so on.
AES is another good source, the development was done as an open call, everything had to be out in public, license free so it could be widely adopted if it won, etc. DES on the other hand was developed by IBM (as a 128 bit originally) and later gutted by the NSA to 56 bits, as well as having the S-boxes modified (making them stronger we are told...). This time around AES is done completely out in the open and people have a lot more trust in the process, and the resulting algorithm. AES is going to be encrypting data communications from money transfers to your network traffic for the next 20-40 years, a decidedly non trivial responsibility.
Make sure the manager understands the license in question and the consequences of using open sourced products. For example, Microsoft is rewriting their licenses all over the place to keep people from mixing their development tools with open source software. They call it "viral" software.
I would personally look at things like the license itself and the maturity of the package.
Is this a project that has been worked on for years? Or did the author(s) abandoned it when they graduated college?
Is the project well documented?
Is there a network of users in place to help newcomers? Does it have one or more popular web message boards or newsgroups that you can go to look for help?
How hard is it to find a guru to consult for you to help bring in the project into your organization?
That's all I can come up with now.
Pedro
----
The Insomniac Coder
If it deals with Open Source in any way, you must have your students read The Cathedral & the Bazaar by Eric S. Raymond.
I strongly suggest you consider "The Software Project Survival Guide" by Steve McConnell, and the info on swetok.org.
"Classic UFO's
Holland used to be the number 1 superpower in the world. It controlled most of the worldwide trade. Why did they control the seas? Because they had the best navy to protect their tradeships. Why did they have the best navy? Because they had the best navyvessels. Why did they have the best navyvessels? Because they had the best shipyards. Why did they have the best shipyards? Because they had the most rivers, and were naturally motivated to improve shipbuilding. Why did they have the most rivers? Because their country is flat.
They fought four wars (at sea) with the British. They won all of them except for the last. Their navyvessels were continually 30 years ahead in development. The British copied their models once they were technically able. Thirty years after the Dutch had build the technically perfect ship that could be build using wood and the British had matched them, they were defeated because the size of the population became the remaining decisive factor. From then on the British became the #1 superpower in the world.
History is knowing mechanisms. So is knowing the future.
In the 1980's it became apparent that only software developed and maintained by a (large) group of people would remain usable. These people need to communicate intensively, hence be in the same building, hence need to be paid as workers, hence had to live from sales of software.
The internet changed that paradigm. Groups of volunteers now have the same communication tools. Code they have written, documented and published under GPL is 'liberated' and cannot be reversly hold captive by closed source companies.
Just a few more years, steady development under the current cicumstances and OSS will rule. Tell the managers OSS will be the ICT development of this decade, riding the internet wave of the decade of the 90's.
Any managers embarking on a project using open source ought to have a clear understanding of licenses and how their IP rights apply.
This may be as simple as reading+understanding the GNU license information page
and what about a "Managers" course for "Open Source" :D
----- Whats wrong with this picture? http://www.revoh.org:1234/whatswrong
As an example, we were initially intending to offer our product with MS SQL Server. We started looking at the numbers and were really disheartened when we realized that at the price we were selling our product, we were making more money for Microsoft than ourselves!
We then started looking for a SQL Server replacement and found that both Borland InterBase and Postgresql were excellent products. Now we use so much open source software that we are at the point where our clients don't have to purchase any software, and since our product has been rewritten in Java, we don't even require windows anymore.
BTM
That was the turning point of my life--I went from negative zero to positive zero.
Someone gets modded up for plugging there crap? I've got some old computer parts you can buy, give me karma.
This is main purpose of Open Source:
to make young boys feel good about themselves.
On other hand all Microsoft's buggy software
mostly produced by young college graduates
without serious skills and experience, it is
why it is so BUGGY. Choise is yours...
Will Open Source for Managers and Open Source for Dummies be the same book?
:)
C//
A**Hole its Troll Tuesday. Guess what you fundamentalists want to do even trolling "against" the World Normal.
--
HappyTroll
who? who? who?
You'll need to discuss at least two situations: (1) using open source software in your business, and (2) developing/modifying open source software. Obviously, the issues are different.
- David A. Wheeler (see my Secure Programming HOWTO)
"The Cathedral and the Bazaar" is one of the OpenSource bibles:a za ar/cathedral-bazaar/
link:
http://www.tuxedo.org/~esr/writings/cathedral-b
At least it was exactly this paper which has converted me some years ago...
--
Karma 50, and all I got was this lousy T-Shirt.
To streamline the readings I have put together a compilation of the key Open Source writings. I call this 80-page book The Open Source Reader (OSR). The OSR is important because it puts into one point the entire key concepts and views. This is good material that is currently disperse across the net. The OSR has been a success for the students and has been downloaded thousands of times from people all around the world.
Regarding the contents of the Open Source class for managers, I put:
I have also taught the course in a Master of Computer Science; there the students develop an eBusiness project that must use only Open Source software. As an additional research project, every student must present Open Source software that may be useful for the rest of the class.
The feedback of teaching OS in the university has been excellent. Every future manager that crosses this class ends knowing that they can:
I am sure that the classrooms (schools, technical institutes, universities) are a key place to plant the seed of the Open Source.
GOOD POINTS:
1) overall cost (license, administration, hardware) is lower for the same functionality.
example: I work for a LARGE bank that used Netscape for an online trading application. Converted to Apache saving anual license cost and was then able to scale without purchasing more licenses (new development servers, etc.).
2) security, for instance Gartner group recently published a paper urging IT shops to stop using MS IIS due to massive security flaws.
example: the viruses out there hitting the net are for MS (Nimda, code red, etc), my linux/bsd stuff was unaffected (not to say that viruses don't exist for linux) where as others in the corporation had to shut down.
3) growth and expansion (scalability of both volume and functionality), a mid-level developer/admin can quickly extend Open Source applications to meet new needs, duplicate existing applications on new hardware to handle more traffic, or cluster the OS to add a few 9's at the end and handle more growth. This can be done quickly and in-house without contract/license add-ons/negotiations.
example: almost half of my workload is adding new functionality to the various trading and back-office applications (which makes the users REAL happy). I can deliver what the users want quickly because standards-based, open-source, community-designed applications and tools make it easy for me (I am no Ken Thompson, Linus Torvalds, or Alan Cox)
BAD POINTS:
1) You have to have good people who want to learn and grow (which demands compensation of some sort i.e. treat them well, sponsor pet projects, pay them well, whatever). This actually runs counter to some HR/IT cultures.
2) You have to PAY ATTENTION TO BUG FIXES POSTED. RedHat auto update handles this for you with little-to-no intervention. But pay attention anyways. Some vendors like IBM will be proactive in updating your infrastructure (MS is not at all as Code Red showed). Open Source puts out A LOT of fixes, I would say 95% of them are minor (engineering-anal-retentiveness), but some are serious.
Community College open source eh, are you also going to teach a course on picking up buckled chicks at ren fair?
open source seems to have become a rather attractive haven for people that can't really code, and now it seems for people that can't really teach.
There is a reason major universities have eligibility requirements for both attending and teaching, this course proves the point.
There is no money in open source.. none, if there is a dime it's because someone somewhere has noticed your hard (free) work and has decided to captalize on it (steal it and pay you shit).
Open Source is a product of the unemployed and the student, don't buy into the hype.
Thanks to everyone who put in their two cents. I had already read a few of the books mentioned here, but you guys came up with some that I hadn't heard of yet. Also, some of you posted course outlines that were very much along the lines of what I was thinking - but again you added some interesting ideas I hadn't thought of. Same with the links... Thanks again!
TMJ
p.s. There always seems to be some one who thinks that every person who submits an Ask Slashdot post should be satisfied with whatever they find on Google. Why is that? I guess if we are asking the Slashdot crowd we want to know what Slashdot thinks about the subject, not just what Google is kind enough to throw our way.
Are you...Are you some kind of genius?
No, ma'am, I'm just a regular Slashdot reader.