Multi-Level Marketing

About two month ago I wrote about Network Effects. What fascinates my in Network Effects is their exponential nature. Our human brain is used to think about linear phenomena. It is very hard for us to deeply understand and predict exponential phenomena.
Another exponential economic phenomena is the phenomena of MLM (Multi-Level Marketing). This is a way to build a marketing organization by compensating an affiliate marketer for bringing more affiliate marketers to market the company's product or service.
A powerful combination is to combine MLM and the web to create Online MLM. This is a powerful economic activity which harness the power of the online world to do marketing in a wide scale.
There are many who think MLM is just a scam. You can find a good criticism of MLM in the following link: http://www.vandruff.com/mlm.html. Even though the criticism can have merits in some MLM plans, I don't think it proves that MLM plans can't produce a good, healthy and stable organization.
In a later post I plan on showing why Vandruff's arguments does not rule out all possible MLM's programs. But in the meantime you can try a some Online MLM yourself. Choose a program in the Internet MLM page and join it using my sponsorship link.

Khen

Technology Network Effect

Network effect is a fascinating phenomena. The name relates to an economic effect. According to wikipedia "a network effect is the effect that one user of a good or service has on the value of that product to other people".
The power of Network Effect comes from Metcalfe's Law which "states that the value of a telecommunications network is proportional to the square of the number of connected users of the system".
There are many examples of things that succeeded because of Network Effect and of things that failed because they didn't have enough Network Effect.
In the age of the Internet the competition for using the Network Effect is fiercer then ever. There are many factors which influence the power of the Network Effect.
One of the main factors is how open the technology is. The Internet itself (i.e. TCP/IP protocol) was established mainly due to the openness of its underlying technology.
As you can see above, the Network Effect is defined as the effect of one user. This implies that every user counts and every user should be aware of the effect he creates in the network.
With this awareness comes responsibility to do the right thing. It is like voting in a democratic process. Unfortunately not all users take this into account when doing their decisions. For example, whenever a user chooses to use MS-WORD file format and not ODF format he creates further Network Effects in favour of the monopoly in office formats and against an open alternative.
The latest issue of Network Effect on the Internet is now the H.264 video format. You can read Christopher Blizzard's blog post about this issue. I think we should all help make the Internet open by supporting Mozilla's decision to not support H.264 video format and demand from the sites we use to support open formats such as Theora.
We can further discuss Network Effect examples in the comments section.

Khen Ofek

Aspects of Paradigm Shift

My friend Daniel recently posted regarding Paradigm Shift.
This made me thinking about the different aspects of a paradigm shift.
First there is the technical aspect. If it is a system then the technical aspect will be apparent in its architecture. If it is a science then the technical aspect will be apparent in the current theories.
But, there are more aspects. The most important aspect is the people. Both the system architecture and the theories of a science can't change their paradigm if the state of mind of the people working on them is not changed. Even if there are objectively compelling reasons for the paradigm shift, if the people have not changed their mind it won't happen.

Since it is very hard to prove the need for a paradigm shift, we are left with politics. Whoever is more politically strong will decide if we need a paradigm shift and to which direction.

Khen Ofek

Engaging communities against Linux and OpenOffice.org

I like paradoxes. Paradoxes of all kinds always facinate me. They enforce you to think and often reveal deep understanding on how things work. You can read my analysis of the Paradox of the Cloud in an earlier post.
This is why I was amused to read Glyn Moody's blog post about a Microsoft's job description.
Microsoft wanted to recruit somebody to fill the “Linux and Open Office Compete Lead, US Subsidiary (CSI Lead)”. Glyn was concentrating on what CSI job description meant for OpenOffice.org. But, I want to stress here the paradox that is apparently inherent in how Microsoft treats the Open Source community.
According to Moody's blog post the job ad contains the following words: "The core mission of CSI is to win share against Linux and OpenOffice.org by designing and driving marketing programs, changing perceptions, engaging with Open Source communities and organizations, and drive internal readiness on how to compete with Commercial Linux and participate with Open Source Communities."
What caught my eye is the paradox of "win share against Linux and OpenOffice.org by ... engaging with Open Source communities and participate in Open Source Communities". Linux and OpenOffice.org are Open Source communities, among other things. So, how can Microsoft engage and participate with Open Source communities and act against them?
I think this paradox is not coincidental. Microsoft's engagement with Open Source communities is not aimed for the better of Open Source, but for the better of Microsoft against Open Source. It doesn't have to be like that, just look at the engagement of RedHat and IBM in Open Source communities and you can see that a good engagement is not against something but for something.
The only one that can solve this paradox is Micrsoft itself, and until that happens, Open Source communities should not trust Microsoft.

Khen Ofek

Subscription By Email

I added the option to subscribe my blog by Email (using FeedBurner).
Please subscribe your mail so you can get an Email notification when I post

Khen Ofek

Structure and unStructure

At the end of the first day of IGT2009 conference, a meeting called CloudCamp was organized.
The meeting was organized by Reuven Cohen who is the founder and CTO of Enomaly.
CloudCamp is actually an unconference on Cloud issues. Reuven told us that it was first came into being when a group of people tried to answer the question of "What is Cloud Computing?".
The idea of an unconference is not new. There are many unconferences around the world on various subjects. Unconference is an informal meeting which lacks a rigid predefined agenda and schedule. Only the topic is defined and the discussion can go wherever the audience wants to take it.
I didn't stay for the whole meeting, But I stayed enough to enjoy the idea of an unconference, even though it was the first unconference I participated.
The meeting began with 3 lightning talks from the three funding companies. A lightning talk is a five minutes talk which is not supposed to be the company pitch, but often it is.
Then there was an unpanel. The idea was to choose five people from the crowed who will be the panelists. The remaining crowed is asking the questions and the unpanelists should answer them to the best of their ability. To my surprise this was a very interesting panel discussion. The idea of giving a small amount of structure to the crowed was very helpful. When you compare it to a regular talk you realize that the structure of a panel really helps the discussion even if the panelists are just members of the crowed.
I think the whole idea of CloudCamp and unconference can be compared to the idea of Cloud Computing itself. In the CloudCamp the droplets are people, while in Cloud Computing the droplets are computing nodes. The idea is putting enough structure to make it interesting, but not too much structure. This idea of going on the boundary of Structure is shared between CloudCamp and Cloud Computing. The surprisingly good things that come out of unStructure elements are also shared between CloudCamp and Cloud Computing.
This tension between Structure and unStructure is a recurring theme in other ideas which became popular in recent years. Such ideas include the agile development methodology, Free Software bazaar, the Dynamic Infrastructure pushed by IBM and NOSQL.
As an architect, this is one of the most interesting tensions, if an architect solves this tension he can do wonders to the system. Since this tension involves a lot of non-linear phenomena, it is very hard for the human mind to understand all implications of this tension. We need to develop better conceptual tools in order to analyze and control the tension between Structure and unStructure. These tools will enable us to architect robust and long lasting systems of many kinds.

Khen Ofek

The joy of collaboration

I went to the IGT2009 conference. This was an international Cloud Computing conference. The conference went very well. It lasted for two full days with a lot of interesting speakers and a lot of things to think about.
I am planning a series of posts which will tell you about the things that were going on there and try to analyze them.

The first thing I would like to talk about is Yossi Vardi's keynote which was titled "The joy of collaboration".
I think it was very insightful talk. He actually didn't talk about Cloud Computing. He said he is talking about a deep reason we are all in the conference, and I think he was right in not only one plane, but in three different planes.

The first plane was explicit in his talk. The killer-apps of SaaS are collaboration applications such as Email, Social Networking and IM. We are social animals, and we get joy from collaborations. This was the main theme of the talk. Vardi showed some very nice videos showing collaborations in action. The nicest video I remember showed the patterns formed by a flock of starlings, see for example this video. At the end of his talk he tried to show us and talk about the beauty of collaboration. I think he somewhat missed the point with the videos at the end since they showed only few individuals collaborating, and the whole idea of the Cloud revolves around massive scale.

The second plane is the structure of Cloud Computing. Here we are talking about computing nodes that are collaborating. To an architect like myself this collaboration has its own inner beauty. The formations and patterns in the Computing Cloud can also be regarded as elegant and joyful like the formations of the starlings.

The third plane is the conference itself. Here again, we are talking about people's collaboration and it were two joyful days indeed.

Khen Ofek

Paradox of the Cloud

The question which everybody seem busy trying to answer is "What is Cloud Computing?"
There are many answers and opinions about it. The answers are influenced by a lot of forces and my intention is to analyze this question in some future posts.

But, as good philosophers, before we go into the exact definition of Cloud Computing, we should ask ourselves "Is Cloud possible?"
Now, this seems like a provocative question, but I am really serious about the question. The problem comes from a famous paradox that is sometimes called "Paradox of the heap" and the Greeks called it "sorites paradox". I really like paradoxes since they force me to think and often reveal deep things about the fundamental structure of theories.
The paradox is described in Wikipedia as follows:
"One might construct the argument, using premises, as follows:
1,000,000 grains of sand is a heap of sand (Premise 1)
A heap of sand minus one grain is still a heap. (Premise 2)
Repeated applications of Premise 2 (each time starting with one less grain), eventually forces one to accept the conclusion that a heap may be composed of just one grain of sand (and consequently, if one grain of sand is still a heap, then removing that one grain of sand to leave no grains at all still leaves a heap of sand)."

Obviously, if you replace heap with Cloud and grain of sands with droplets you will get the "Paradox of the Cloud". I don't think we will regard one droplet as a cloud or one computing node as a Computing Cloud. Note that the paradox is described going down to show that the problem is not a problem of induction. One can also describe the paradox going up from one droplet.

This paradox is an instance of a class of logical paradoxes which deal with vagueness. It is not a coincidence we have such a paradox for the Computing Cloud. The Computing Cloud is also a vague concept and everyone dealing with it is using this vagueness to pull the concept in the direction that suits himself. For example, Amazon is taking the Cloud to the Infrastructure as a Service, while Google is taking the Cloud to the Platform as a Service. There are some companies today that are thinking about Industrial Cloud and there is the famous Private Cloud where the borderlines between cluster and Cloud are really getting foggier.

All this pulling and pushing is very nice from the marketing point of view, but "The paradox of the Cloud" is of a logical kind and marketing have a small chance of answering logical questions. If anything, marketing and business are better in raising logical questions not answering them.

There are many proposed resolutions to the Sorites Paradox. Most of them involve all kinds of fancy logics. These logics are very interesting from logical and philosophical point of view, but I don't think they are interesting for the practice of Cloud Computing.

There is one proposed resolution that can be interesting to the practicing of Cloud Computing. The resolution is labeled "Group Consensus". This proposed resolution claims that a collection of droplets is as much a Cloud as the proportion of people who believe it to be so. That is very interesting since it actually brings the Community as a resolution to the paradox, and not just any Community, but one that reaches decisions through consensus.

The conclusion is very important, to solve the Paradox of the Cloud we need a strong community which defines its concept through consensus. This brings the importance of Open APIs and open field to all players. As bigger and as open the Cloud community will be the Paradox of the Cloud will be solved in a better way.

Khen Ofek