We put up a jar filled with éclairs and asked the audience to guess the number of éclairs in the jar and note it down on a piece of paper and hand it over to us. Obviously, we were excited to know the results – if the experiment worked, did someone guess the correct number?
Here are the results:
We had responses ranging from 25 éclairs to 786 éclairs. The actual number of éclairs in the jar was 204. Out of the 134 responses, only 1 person got the number right. The average, the ‘collective wisdom’ of the ‘crowd’ was 161.4 – an accuracy % of 79.14.
The results have left me wondering as to why did the results not concur with the ‘wisdom of crowds’ theory. After all, the following elements of ‘wisdom of crowds’ were present in the experiment:
There was enough diversity among the participants. even though all the participants were software engineers, they came from different project teams, had varying levels of experience, roles etc.
Each person was making his/her own independent choice and was not influenced by any other member
There was means for us to collect and aggregate the responses.
The fourth element ‘Decentralization — people being able to specialize and draw on local knowledge’ can be debated to be missing from the experiment. How can we assume that there were people specializing in guessing the number of éclairs in a jar? How could they draw on local knowledge?
In Galton’s experiments, there were people who were butchers and farmers who one can assume to be specializing in ox/cattle.In ‘Guess the weight of the Cake’ experiment, people could feel the cake in their hands, there were people who were traders and hence one can assume that ‘knowing the weight of an object’ was something that they were familiar with.
The ‘guess the number of coins’ experiment was an online experiment and had no option for people to see, to feel the jar, hold it in their hands. Similar aspects were present in the experiment we conducted – we just showed people the jar filled with éclairs. We did not have people holding the jar, touching it, feeling it. Could such seemingly insignificant things allow people to make more informed choice? I don’t know.
BTW, ‘Guess the weight of the cake’ experiment was 99% successful even though it had just 120 participants whereas ‘guess the number of coins’ experiment was just 88% successful even though it had 1760 participants. This indicates that while the sample size could be a factor, but it does not seem so in the above examples.
I am wondering if aspects of ‘cognition, cooperation, coordination’ are present in such experiments?
What about the sample composition itself – all software/computer professionals? Do they bring diversity or are software professionals just not the right sample for any kind of experiment?
Having seen open source from close quarters and a long enough time, I am beginning to believe that monopolies [or near monopolies] do exist in the open source world also and the business complexities, rules, strategies similar to the ‘other world’ are prevalent & relevant here. In fact a lot of smart people, organizations, communities have realized this aspect of open source and are quietly moving ahead — making full use of open source to create monopolies while many people are still debating the moral, legal, aspects.
Open Source promotes competition and diversity.
Yes, it does promote and provide opportunity for diversity & competition. But only in some areas areas, products and not in all areas. The ‘fundamental’ building blocks for the success of an open source [or a proprietary one] remain similar if not same.
Let’s take the classic example of ‘http’ server — Apache. Is it a monopoly? How many other open source http servers are out there that are popular and adopted by the world? hardly any..
For an open source product, the community that it is able to create for itself and leverage gives it the muscle power to ‘consciously or unconsciously’ create a monopoly. The larger the community, the larger the adoption, and hence the larger is the barrier to entry for other open source solutions.
However; it is true that open source does cause disruption within open source monopolies itself. for example: STRUTS was the de-facto framework for java based web development and had a near monopoly. other frameworks never stood a chance. Then comes spring and creates a whole new paradigm. So now it is spring that is on the verge of creating a monopoly. Then we have jBoss app server as an example. It is the defacto monopoly in the java middleware market.. It’s amazing that how jBoss has used the power of the community to effectively build a monopoly. Then think of eclipse.. the whole ecosystem it has been able to create around eclipse is amazing..
I think that in areas that are fundamentally ‘protocol/standards based’, open source products, solutions, frameworks is a sure shot way to create a monopoly and in areas where the differentiator is based on features, implementation etc, there will always be several open source products competing in the marketplace — competing for adoption, competing for building a community etc.
I think the smart companies will soon realize this and use open source for their business advantage to create huge barriers of entry, and near monopolies. The challenge is that it the fundamental requirement in this equation is to create a vibrant, robust and engaged community around the open source product. While commercial organizations are expert in creating brands/marketing etc, creating communities is not something that comes naturally to them. The key to success would lie there in my opinion..Maybe time for a CCN [Chief Community Nurturer] role within organizations..
A Disclaimer: I am a huge believer in open source and have been involved in this world for more than 10 years.
Strange as it may sound, I believe that Wikipedia is one of the biggest ‘threat’ or issue when rolling out a wiki initiative in an organization.
I was at KAMP — a KM unconference and asked the partcipants on how many used Wikipedia as a refence, as an example for introducing Wiki to people within an organization. Almost all raised their hands and agreed.
What’s wrong with that.. you may think.. well what’s happening here is that you are sending a subtle message to people that it is a Wikipedia equivalent that we are trying to build within an organization and people seem confused on why would you want to do that.
KM professionals need to stress the ‘underlying principles’ of Wikipedia more that wikipedia itself when trying to start a wiki initiative and clearly mention that we will be using these principles to use the power of wiki in our organizational context.
So my advice to people is.. beware when you use Wikipedia as an example of wiki..
This is the presentation i used to illustrate some key ponts we need to be aware of while rolling out a wiki initiative
In any organization, the work gets done through teams — sales teams, project teams etc.. Is their work suited for Wiki? What information within their work would lend itself nicely to wiki?
For example — software projects. Is wiki relevant in execution of software projects? How? what are the challenges? How to overcome those challenges?
Starting with the bread-and-butter documents, documents that need to be maintained within a project anyway are a good means of starting to use wiki. Evolving these documents in a Wiki instead of a word document is a quick win and will show the team the power of Wiki….
Things like project overview, roles & responsibility, infrastructure details, release & build processes, tips & tricks, Faqs, what to when.. etc etc..
There is much talk on Wiki being the next killer app and how it can potentially solve the world hunger problem
I wonder if Wiki is all hype or is there some truth to it? Why would an organization use wiki? or more importantly in what contexts would wiki be useful for an organization? What kind of organizational information lends nicely to be on Wiki?
In my view it depends on what is it that you want there? Could be organizational policies? Maybe NOT May be YES. It depends on how bold the organization is. Theoratically you can have mechanisms that ONLY few people in the oragnizationcan edit and change these policy pages and rest can comment on those. However this is against the fundamental spirit of Wiki and people are smart enough to recognize that fact and may get turned off [Having said that, even this would be a welcome approach if followed by organizations of involving all their employees and such approaches can be implemented though either Wiki or other regular smart web applications/content management systems].
What else could be there from an organizational context?
Processes? Could be a candidate where processes keep evolving — for example in IT industry where processes have to be tailored continuously for various kind of engagements. For example development processes in mainframe or embedded systems have things in common but are yet different at ground level, even within that we could have tailoring of processes for large/small engagements etc… The most suitable people to do this are all the practioners in the organization and what better way of doing it than Wiki?
Yes this is a radical approach — but so is wikipedia! If an organization can’t go the whole hog with allowing ALL practitioners participate in the evolution/tailoring of processes through wiki, the first step can be to have the team that is responsible for processes use wiki and then place stuff from wiki into the actual procceses repository…
Prevalent assumption within the organizations/barriers to Wiki: Wiki asa concept is radically different and contrary to the traditional top down, command & control approach [Which in their belief is tried and tested]. Users want to get the credit for work — in Wiki how do you define credit taking? , users want to control things [with wiki not just one but everyone who participates would get also get credit..] [With wiki, you can't control thoughts/ideas from other people..]
Some examples: journalist/authors use it to do write collaborative papers/articles..
