“Jellyfish clusters” – Organzing without organization


(Today I’m pickung up one of the talks I submitted to the 28C3 and that got rejected)

Jellyfish clusters are a somewhat new concept. Well, not really, I guess structures like them have alway existed, but were only recently named as such. When the activist cluster Telecomix hit the news there was a dire need to explain what Telecomix is and how they work. In Germany the “datenschutzkritische Spackeria” whose work I illustrated here adopted the same modus operandi.

So how does a Jellyfish cluster work? What are advantages and what are the disadvantages of using that structure? What are common problems and how can they be fixed? I’ll try to answer these questions in the next paragraphs.

How they work

Jellyfish clusters work by not providing defined structures, organization or hierarchies. There are no explicit “roles” or “functions”. They are not completely structureless though. Both Jellyfish clusters I referenced in the introduction use a central IRC channel for realtime communication and a certain level of “we” feeling and awareness for each other. Those IRC channels provide a starting point for potential contributors even more than a website could do: Jellyfish clusters are about action, about doing so an immediate medium that allows direct and quick interaction is paramount.

Membership is fluent: Whoever is “there” (in the IRC or in the respective IM rosters of the people wanting to work) is part of the cluster. You become part of the group if you join a channel. While this lowers the barrier of entry to almost non-existence it does also devalue the whole membership idea: Being a member of a jellyfish cluster is itself absolutely nothing, it’s something every person on the planet could do in 2 minutes.

Apart from the IRC connecting (potentially) all cluster “members” everything else is optional and in fact mostly spawned on demand. Most clusters will have some sort of online publication system like a blog or a wiki, but those are often just created by someone on one of the diverse free hosters (wordpress.com for example). If something more complex is needed an individual steps up o the task: A certain program has to run every hour? Someone will take their server and just have it run there.

This leads to jellyfish clusters not really “owning” their infrastructure: Everything belongs to one of the active menbers and can go away if that member goes away and does not leave at least the login information with some of the remaining actives.

In spite of this Jellyfish clusters do create a sense of belonging together, of “community” but without the heavy burden of certain actives feeling less powerful than other actives. Due to its very weak formal cohesion jellyfish clusters rely on personal relationships, respect and reputation. People investing their time and creating good work will become the nucleus of the cluster that others dock onto on demand. This allows actives to drop out of the cluster quickly even though they’ve been central in the past: The cluster will probably be able to adapt or at least reform.

Jellyfish clusters tend to form around a certain topic or cluster of topics: The Spackeria formed around the discussion around the concept of privacy, Telecomix around the idea of creating and ensuring free and uncensored Internet access for everybody. A hot topic might spark a Jellyfish cluster in days and due to its lack of structure a cluster can dissolve in minutes when their “task” is resolved.


Jellyfish clusters can form quickly and have a very low barrier of entrance. They are not tied to slow hierarchies and formal methods of finding consensus.

Tasks just “get done” by whoever considers them important or whoever is competent and gets asked by the group to do them without having to go through a long and formal process. Forming around a topic Jellyfish clusters tend to be rather focused on their topic of interest.

A strong reliance on people and their relationships instead of structure helps people connect and stay motivated: The cluster stays a “we” and not some abstract structure the active is just a cog in a machine in.

New people can directly work and do meaningful things without having to go through a lengthy and strict membership process.


Many of Jellyfish cluster’s strengths can also turn into weaknesses: The low barrier of entry can in certain cases lead to the group being flooded with new people that might have very different ideas about how to go on. Due to lack of structure the cluster has few mechanisms to keep to its former self and might change dramatically.

For new people the lack of formal structure can be intimidating or even confusing. There are no formal guidelines on what they are “allowed” to do and what the “group opinion” is. It takes a while to learn how the group works.


The lack of structure and functions also is a big problem for outside communication: Media tends to rely on contacting the “speaker” of a group that communicates the group’s opinion as one. Jellyfish clusters therefore can’t provide media with the one single point of truth they like. This makes Jellyfish clusters somewhat hard to deal with from the outside. The lack of a definitive “group opinion” can have a similar effect.

In a certain sense, “churn rates” can affect Jellyfish clusters stronger than other groups since all the infrastructure is bound to people. If a cluster ties a lot of infrastructure and services to one person, that one person is now able to hold basically the whole cluster ransom to get it to do their bidding. While the cluster could try to replace that person and the services they provided this creates friction and wastes time, resources and – if the resource in case was for example the domain name – reputation.

Finally, the heavy reliance on people and their relationships makes Jellyfish clusters rather affected by personal problems or fights. Actives might work too much and burn out, pushing each other way too hard. The following personal breakdown can pull a whole lot of closely connected people with them (if just by forcing them to pick up the work and pushing themselves to hard as a consequence).


To deal with the lack of a speaker, Telecomix came up with a very smart idea: Cameron. Cameron is a virtual entity, not one person, but the voice of the collective. Everything that needs to be official is attributed to Cameron who can be “implemented” by different people every time. Not only does this provide the outside world with a “face” (even though Cameron has none), this construct also prevents problems like the ones Wikileaks has at the moment with the legal trouble of the spokesperson putting the whole project in a shady light. Cameron does not have that problem since its virtual.

To make sure that not all resources end up with one person, awareness is key. Not only does the cluster itself need to have an eye on the distribution of resources (which all also mean workload or payments). For every service there should be more than one person with admin access to make sure that the project could survive a plane crash.

The high dependence on people brings with it a high level of responsibility for each other. The whole “just deal with it” attitude we find a lot on the Internet is poison for Jellyfish clusters. In order to survive each cluster needs to take care of its actives which means that the actives have to look out for each other. Obviously outside friends and contacts can help as well to let of some steam and help actives vent about their work and the stress that might come with it.

Do I want one?

If you have a clear topic of interest, something that needs more work and input a Jellyfish cluster might work for you if:

  • your project is not about managing and providing reliable infrastructure (cause a cluster can’t own things)
  • your project does theoretical work
  • you are not focused on media coverage
  • you (or the people you want to start the cluster with) have a very positive working atmosphere and can deal with personal conflicts well
  • you are willing to let the project develop in any way, even one that might no longer be the project you started

If one or more of the above points is not true for your project or plans you might want to set up a more formal, more structured construct. Jellyfish clusters are extremely agile and can provide a great change of pace especially for people who are tired of the whole management aspect of traditional projects. But they are a tool with sharp edges and you need to realize the potential hazards before using them.



When it comes to code many of you will know Linus’ Law:

“given enough eyeballs, all bugs are shallow.”

It basically states that you just need enough people to look at something to have them find what’s wrong with it and we’ve used that principle in free software development for many years now with (as I’d say) a lot of success.

In the last few days I’ve thought a lot about this idea, the idea of transparency. Now we shouldn’t make the mistake of mixing privacy and transparency up: Privacy deals with individuals, transparency is for organizations. So while we do want organizations to make their own decisions just like people, organizations do behave and should be treated differently.

With the Internet having established itself as cheap and omnipresent way of transmitting information, of reaching many many people (given you reach the right multiplicators) we’ve also seen many organizations and groups of people step up to the task and fight for transparency: The EFF, the CCC or projects like the now famous Wikileaks (among others).

They fight governments and cooperations who hide the “truth” from the public, who make deals against the public interest or funnel away public money into their own pockets and we all should be thankful for those organizations and their work. The world needs whistleblowers and people who dig in the darkness till they find what’s what.

But recently we’ve also seen the other side: Wikileaks’s completely secret organization and actions have lead to one person becoming the face and the boss of the project with the power to kick everybody out who might stand up against him. But wikileaks is far from the only “good” project that lacks the transparency that it so fiercely wants others to display. The CCC has a track record of being far less than stellar when it comes to being transparent about what’s going on (especially with the way the handled ticket sales [there were no tickets, then there were just for people that knew people, then there finally were some, it was a mess] and speaker slot assignment in the last few Chaos Communication Congresses [one of the public faces of the CCC said while pointing at the CfP in a podcast lately that not all slots were taken yet ... well since the deadline has not run out yet, shouldn't all slots be free still?][the review process is also far from being what we can call a "peer review" process or otherwise open and transparent]).

I started this text with a law or quote from a programming background, so let me add another one of those:

Eating your own dog food

Eating your own dog food means that a producer of something uses the product him- or herself: Microsoft uses Windows and MS Office on its machines and the bosses of Volkswagen are not supposed to drive around in Mercedes-Benz cars.

I think it’s time to start eating our own dog food. And I don’t just mean the organizations that I pointed at (and many other similar organizations) but each one of us: Why do we cheer for Wikileaks with every big leak (and publicity stunt) when they themselves do nothing to be transparent? Why do I still propose talks each year to the Chaos Communication Congress knowing that they will be rejected without any comment whatsoever? Why don’t we hold us and the organizations we cheer for at our/their word?

Transparency is the only way to build strong organizations. And you want strong organizations and not just strong people. People are easy to discredit (some even easy to corrupt) and too much power has never done anyone any good. We need good organizations and structures that make sure that power is equally distributed and that a structure has ways to make sure that every member behaves within the limitations of what the structure establishes. And the only way to make sure that people can check that nothing filthy is going on is transparency.

If you want to fight for transparency start with yourself and your own project. We need transparency everywhere but why should I trust one organization fighting for transparency if that organization itself isn’t?

Why folksonomies?


I have called us all idiots before and today I want to touch on a related topic, the topic of so-called folksonomies and why we should use them more, replacing the taxonomies we have today.

We are used to this model of doing things: We have one or more experts who give us a set of categories to organize our stuff with (what kind of stuff isn”t really relevant here). We rely on those experts and we trust them because, well … they are experts and they know what”s right.

“Right”. I love that word, don”t you? It”s a word like concrete, as powerful as any god can ever aspire to be: If something is right you can no longer discuss it or argue because right is absolute. We all know what”s right most of the time. Others obviously don”t or there wouldn”t be so many arguments though, shame on the others, just accept what I deem right and we”re fine.

We see that while we still pretend that there is a concept we call “right” that is objective and absolute that whole idea fails already at the most basic examples: “Coke is better than Pepsi”. Is that right? Ask 100 people about it. But our belief in experts is still solid and this imbues them with the power to determine the “right” order of things.

Now that the categories are set up I can now put the things I wanna sort into them but from experience I gotta say: The categories never quite work. Sometimes they do “okay”, often they “kinda work” and sometimes they just plain fail. Look at flickr: Is that contact a “friend” or “family”? Well maybe both? Maybe none?

If we just assume for a second that traditional categories work it”s obvious that by defining them I have already ordered the world, I have already brought structure into the world that wasn”t there before and that structure represents the way I see the world, my mental model.

Let”s look at software design just to have an example. I give you a tool like UML to structure the items we are talking about: So we have classes and instances and relationships between them. Classes and instances contain methods that represent actions. “Now you can model anything in the world exactly like you see it.” is something I could say.

You start modelling stuff and after a while you want a function that is not bound into a class or an instance. Oh yes, and there are those “Constants of the universe” that don”t really belong into any class. But crap, UML can”t model that: By giving you a tool, I have already limited your options of modeling and ordering things. I might have done it with the best intentions but still it doesn”t work for you.

Folksonomies, that means order and structure that is generated socially through tagging, do not have those problems:

  1. They give hardly any limiting structure because you can tag anything with anything.
  2. They don”t claim to be “right”, your tags just represent your view which is neither right nor wrong, it just is.
  3. They don”t need experts and people relying on them.

In my perception we are long past the whole “experts define how we may see the world” while still kinda falling back on that model more often than not. Now”s a good time to make the leap: Drop the idea of creating “the right categories” or the “right order of things”. Embrace your individuality and order your world as you want it.

To <ol> or to <ul>


HTML has two different types of lists that allow you to organize items: The ordered (&lt;ol&gt;) and the unordered (&lt;ul&gt;) list. Both types of lists behave pretty much the same, they just use different symbols to mark items (I”m talking about the unstyled, unchanged defaults here). Where the unordered list just uses bullets by default the ordered list enumerates the items and marks each of them with a number.

Both semantics are quite obvious: The unordered list is just a container of items, the ordered list is like an unordered list just with a clearly defined order (Well that”s the semantics that is described by the names even though unordered lists do in fact have an order, it”s just not displayed).

Many people seem to prefer &lt;ol&gt;: It looks more structured and especially when talking about a top-ten-list (which pretty much sums up 50% of all blog entries ever) it makes sense to use it. But in my experience more often than not &lt;ul&gt; is the better choice.

The structure and order that the numbers imply is often not really what people tried expressing: In many cases it automatically implies some sort of difference in the level of importance of the items. There”s gotta be a reason that item number 1 is the first, right?

Ordered lists should be used carefully, they can hinder a productive discussion more that people think: If you number your items (and either consciously state or subconsciously imply differences in importance) you automatically make it harder for people that have issues or comments to one of the “less important” items. The order that things have (when order is based on the level of importance) is very personal, what matters a lot to person A is almost irrelevant to person B.

It”s one of those small things that we tend to overlook but that really make subtle differences. Looking at many people writing about why they oppose the censorship of the internet that was recently proposed in Germany I”ve come to think that the way we handle written communication, the way we don”t really think about those little details makes our communication and discussions a lot worse than they have to be.

So next time you write something, just spend a second to thing whether you really want to write numbers in front of your items, cause numbers can hurt (not just in math!).

Different approaches in modelling


There are a few steps that always happen when you create new software (though similar steps occur for other creative processes, too):

  1. You realize that there is a problem that needs solving (an “itch that needs scratching“) either cause you personally want it scratched, cause your employer wants you to scratch it, cause you see it as an opportunity to make some money for yourself or any of a million other reasons. This is when you start thinking about the project.
  2. Now you analyze what the problem is about. Sometimes you already know all the relevant pieces, sometimes you have to learn what entities you have to deal with. This is quite far away from programming, it”s about understanding the status quo, about nailing down the requirements.
  3. The next thing is that you think about solutions to the given problem, you start designing or modelling what will be your solution. The model might change a lot over time cause you find better solutions for problems or try to integrate new requirements or features. This is the phase I”ll be talking about later.
  4. Finally you can implement your chosen solution.

Now I don”t wanna claim that those steps can always be separated clearly or that you always go through them in a straight line, often it makes sense to iterate through the steps more than once and use what you learned in one step to refine your work in the next step. But the activities themselves have to happen (or you end up with a crappy product if any product at all).

So you have understood the problem, you know what you are talking about, and you want to design a solution. How does that work?

Let”s take a step back and look at a story a friend told me recently. Where he works there”s a group that works on developing an artificial intelligence that behaves like a driver. The goal is to have an AI to test systems to support drivers of cars while driving. But having people test it is not always efficient, an AI might be more useful. But the approach of that group is, well, let”s not judge them beforehand: They got themselves a few books on Psychology and Neuroscience, read them and decided that whatever they learned from those books was “how the brain works”. The books modelled the human brain based on neurons so they tried to map that directly to their software design. They built neurons, they added latencies as the neuroscientists had described them. Basically they tried to virtually clone the structure of the brain. Guess what? It didn”t work. While their software couldn”t really get a lot done another group just used simpler neuronal networks, trained their AI against TORCS, and got a lot better results.

What can we learn from this example? (Yes this is the part of this post where I”m actually going to talk about the topic!) Well there are two approaches to designing software (and in fact other things, too):

The first approach is the base your design on the internal structure of what you want to model. You analyze the parts in the system and model each one of them just as they are in the real world. When you want to design a robot hand you could for example copy the bone and muscle structure of the human hand completely. I”ll call this design structurally focussed.

The second approach is to kinda forget how the system you analyzed works and design something that behaves like the system you want to model. When building a robot to answer the phone you could copy the human way to speak by building a throat and vocal cords and whatnot (which would be structurally focussed but you can also write software that can just create the waves that form words through a loudspeaker. You don”t clone the system, you build something that does what the system does (in this case: answering the phone with words).

There are uses for both approaches but the story about the AI that I told you before shows that the structurally focussed approach often fails: The human brain is a very complex beast and while we might know quite a lot about it we don”t understand it completely. The neuroscientists whose theories were used to build the model actually build a model of the brain themselves based on a simple concept (the neuron) that might be modelled after what we think is how neurons work but that”s absolutely not complete. So people tried to clone the structure of something while using different building blocks than were used in the original. This might work sometimes but with more complex systems it often fails.

The approach that is often taught nowadays is the object-oriented approach. You get taught that you use UML to analyze and also to design your model. And while in that microcosm it makes sense: You analyze in UML and you design in UML and you can actually implement it exactly like that in JAVA! This comes as no surprise considering that UML is basically a subset of what JAVA can do. You use a very limited set of constructs to design and end up with a design perfect for the language that the simple constructs were taken from.

Now I don”t wanna speak all too bad about UML, I actually use it quite a lot: When analyzing some problem I don”t know a lot about the limitations UML brings actually help understanding the whole system. Simplicity makes your analysis clearer and easier to grok. But I don”t write formal designs in UML anymore. Why? Let”s look at an example.

I want to design an ATM so I start analyzing what entities I got: There”s different types of bills, there”s bank accounts that the money is taken from, there”s cards and PINs and people interacting with the system.

If I wanted to structurally model the whole thing I could create a bunch of classes to model the entities, an abstract class EuroBill (yes I live in Europe) with the subclasses 5EuroBill, 10EuroBill &ct. When I fill the ATM with bills I create an instance of the corresponding class for every bill, ties to each other based on the serial number of the bill. Whenever I hand out bills to customers I destroy exactly the right instances (in case the account had enough money left of course). This would be the structurally focussed way. And yes, it is retarded for this.

It is the wrong approach cause in fact I don”t care about the identity of the bills and some instance, I just need to know what amount of each type of bills I got. So I model things differently, my ATM just has a bunch of integer variables: 5_euro_bills, 10_euro_bills &ct. When I give out 2 10 Euro bills I decrement the 10_euro_bills variable by two.

The second approach is simpler and still acts the same. It just didn”t care about “how things really are”, it cared about how the system should work. Given Occam”s Razor the second approach therefore clearly wins in this case.

Sometimes you actually want to mimic the structure of the system you”re modelling: If you want to write a simulator for something you might sometimes care about completely mirroring the structure but more often than not you don”t.

It seems sometimes so natural to clone something we perceive in the real world when we write software but there is a big error in that idea: The real world and the virtual world of computers have very different sets of rules and structures. A structure in one world might not work as well in another.

Cloning is dangerous, be careful whether you really want that (this is not just true in biotech wink Different approaches in modelling ).