Social entrepreneurship is basically to create a social impact on different communities, but how are these communities really reacting to entrepreneurial solutions, and especially new technology? For any social enterprise it is crucial to understand the audience and even more important to understand how they will react to exposure to a new technology. I talked to a friend about another thing, and he sent me a link to a manuscript of a speech “A Group Is Its Own Worst Enemy” that Clay Shirky held at Social Software at the O’Reilly Emerging Technology conference in Santa Clara on April 24, 2003.

As intended by pointed out creator of the world wide web, Tim Berners-Lee, the Internet supports lots of communications patterns. Social software may contain point-to-point and two-way, one-to-many outbound, and many-to-many two-way patterns, and thus the challenge to create the right structure of the software is huge. A lot of people, such as Dave Weinberger, Ross Mayfield, Tony Perkins, Estee Dyson, Dan Gillmor, Clay Shirky and even the functional web design guru Jacob Nielsen, have been addressing these issues at different angles of attack, but I will here focus on the mentioned speech made by Clay Shirky.

Shirky first start by looking and the psychological nature of individuals in a group, based on a book by W.R. Bion called “Experiences in Groups”, written in the middle of the last century. A group will strangely enough react to any external force in somewhat mysterious ways. To make a long story short, Shirky summarizes this behaviour:

“He [Bion] said that humans are fundamentally individual, and also fundamentally social. Every one of us has a kind of rational decision-making mind where we can assess what’s going on and make decisions and act on them. And we are all also able to enter viscerally into emotional bonds with other groups of people that transcend the intellectual aspects of the individual. “

The nature of any social software relative to the group is further explained by Shirky.

“Someone built the [social software] system, they assumed certain user behaviours. The users came on and exhibited different behaviours. And the people running the system discovered to their horror that the technological and social issues could not in fact be decoupled…. As a group commits to its existence as a group, and begins to think that the group is good or important, the chance that they will begin to call for additional structure, in order to defend themselves from themselves, gets very, very high.”

The group will self-destruct? Help! Can that really be true? Clay Shirky thinks:

“If these assumptions are right, one that a group is its own worst enemy, and two, we’re seeing this explosion of social software, what should we do? Is there anything we can say with any certainty about building social software, at least for large and long-lived groups?”

Should we just stop this doomed road of ours then? Of course not. The above posed questions are not that easily answered, yet there must be a way to solve this? Right? Of course again, but Clay Shirky summarizes the challenges in four basic design points. Before moving on to the design points, three relevant issues identified by Shirky have to be accepted whether we like it or not:

1. Technical and social issues can never be fully separated.
2. The “members” of a community are not all the same. As trivial as that might seem it is extremely important, as any attempt to define any social software will fail otherwise.
3. The core group is a group of people that are passionate about the goal of the community and has rights that trump individual rights in some situations.

Now it is time to just accept these facts. Done!

We then quickly move on to four crucial points of design of any social software according to Clay Shirky.

1. The user has to feel part of it, has an identity or handle. (Choose the word that feels right to you. The debate about identify has no immediate relevance here.)
2. You have to design a way for there to be members in good standing, that is a reputation or virtual recognition.
3. You need barriers to participation. To be part of the community you have to take action. A complete open community will quickly outscale itself, and destroy itself by the growth of it.
4. Closely connected to the previous point is therefore, that you have to find a way to spare the group from scale. This is crucial part of any social software. Conversations are killed by scale, as they require dense two-way conversations. The fact that the amount of two-way connections you have to support goes up with the square of the users means that the density of conversation falls off very fast as the system scales even a little bit. You have to have some way to let users hang onto the less is more pattern, in order to keep associated with one another.

The reader is referred to the manuscript of his speech for more details about these design points. (For the specific problem with scale, look at this article by him.)

What happens if you do not follow the will of the community that is more or less listen to it, so you might as well design the software this way from the beginning. Shirky says: “The people using your software, even if you own it and pay for it, have rights and will behave as if they have rights. And if you abrogate those rights, you’ll hear about it very quickly.” The good part is that the group will find a way to fulfil the needs of the group, but the bad thing is that they will do it in a way you did not intend them to.

Compare the solution in which the group is solving this process to strategic management of any new venture, which normally divides that process into four stages: conceptualisation (technology and need identification), pre-venture (technology and commercial pheasability), entrepreneurial and organizatorial. The group will go through the same kind of process to solve these issues. At first they will automatically find the problem (conceptualisation), and they quickly move on to identify the possible solutions within the existing social software (pre-venture). The entrepreneurial part of this is really the users imagination to create these structures with the available tools to find a solution inside the existing social software, and then the organizatorial is the self-assembling part of the group around this new “solution”. Misson accomplished by the community! Sounds fairly simple and neat…

If the group will solve this themselves, why is this bad? Simply because the group should not have to solve this by itself, and even more important, the group might be damaged in the process. In all social software, you have a real community and a virtual community. If the virtual community does not fulfil the needs of the real community, a tension will be created between the virtual and the real community. That tension (like every physical tension for that matter) can produce negative energy on the real community. If you on the other hand match up the needs of the real community with the right solution inside the virtual community you might create a positive energy and thus strengthen the real community by the virtual community. Great, hey? So just do it.

Conclusion
Listen to the users and define their needs, but also realise and bear in mind that exposing them to a solution might change the behaviour. The key here is to interrupt the real social fabric as little as possible, and the change of behaviour of the community will be minimized. By this you are at least increasing your possibilities to success.