Endesha - Where Leaders Meet

I’ve recently discovered the rhizome metaphor which is the notion of:

an acentered, nonhierarchical, nonsignifying system without a General and without an organizing memory or central automation, defined solely by a circulation of states.

A rhizome is characterized by six properties which all play together:

1. Connectivity: the capacity to aggregate by making connections at will.
2. Heterogeneity: the capacity to link anything with anything, the linking of unlike elements.
3. Multiplicity: the capacity to form a system in the absence of unity.
4. Asignifying rupture: the capacity of a system to function and even thrive despite local breakdowns.
5. Cartography: the capacity to navigate a system regardless of one’s point of entry.
6. Decalcomania: the capacity to continuously adapt through experimentation, to build an unpredictable always-on resistance to rigidity and restrictions.

I see strong connections between community as practiced by the human species and the rhizome. All six properties can be linked to more familiar human concepts:

These analogies are not perfect. Disruption is not so much connectivity as the chance to connect, or the realization of the chance to connect. Creativity is more than heterogeneity, it is making unique connections that have value. Multiplicity is more than emergence, it is the totality of what has emerged, all that is emergent.

Redundancy is a way to realize asignifying rupture in networks, together with routing. Routing is a way to navigate a network rather than having the option to navigate. Consistent innovation without permission leads to decalcomania.

These imperfect analogies mean that human community is rhizomorphic rather than rhizomatic. This means human community has rhizomatic tendencies yet has a tree-like structure at the same time.

A typical tree-like structure is the cluster which would not occur in a pure rhizomatic structure. Clusters are typically present in social networks which hints to the rhizomorphic nature of human community. A cluster is a node with connections to more than three other nodes. This means that in order to navigate between two random nodes that are not proximate to each other in a social network one has to navigate through cluster nodes.

What does the absence of a pure rhizomatic nature mean for human community? Here a list could follow, but it can’t. Reflecting on the rhizomorphic nature of human community swiftly leads to the conclusion that we don’t know enough. It’s one thing to reason about the consequences of the rhizomorphic nature of the Internet – which’s history we’re familiar with. It’s another thing altogether to reason about the consequence of the rhizomorphic nature of human community.

I mean, until we can demystify sights like Gobekli Tepe there is no chance we can ever understand why human communities are rhizomorphic and not rhizomatic. The only other avenue is to compare human community to the community capabilities of other social species but that won’t lead to much. It would be a stretch to claim primates are creative beings, let alone considering any of the other concepts.

We’ll just have to accept for now that our community is rhizomorphic, not rhizomatic without being able to explain why.

{ 0 comments }

Continued from part 6: social network platform.

Unlike e-mail Google Wave allows for third-party tools to be integrated into the architecture. Gadgets and robots are first-class citizens.

This will create an abundance of third-party additions, both gadgets and robots. Especially current enterprise software vendors will seize the opportunity and build gadgets and robots to integrate the processes they offer into waves. In fact, Wave could prove the ideal platform for the execution of business processes.

Today designing business processes is a tedious endeavor. You don’t only need to design the processes, you also need to deploy them and slap the user interfaces on top of them. The combination of participants, wavelets, gadgets and robots enables anybody who cares to do so to build business processes that are based on crowd sourcing more than anything else.

Here’s a short example:

To all participating realtors, Mr. and Ms. Hazelwood are looking to buy a holiday home in our region. They want a rustic house in good condition with two bedrooms. View on the beach is not required but house has to be in walking distance of the beach. Their budget is $100,000. They want us to propose three properties.

The most obvious thing to do at this point is to add a robot to the wave which adds a gadget where participants can add houses for sale from an external database that match the criteria.

Once a consensus is reached among the participants they can create new wave addressed to the Hazelwoods with an overview of the three proposed properties. In that wave the Hazelwoods can then discuss with a representative when to visit the properties.

In the original wave a deadline can be set – by adding another robot – by which all three properties have to be visited by the Hazelwoods or the lead is automatically closed.

This kind of automation – where waves generate metadata through crowd sourcing that drives other systems – is going to be big. It removes the need to build complex user interfaces which typically delay small changes to IT systems with many months. Instead small gadgets and robots are needed which interface with back-end business process systems that keep track of the actual processes.

Most of the time people are familiar enough with processes, and when things go awry or aren’t moving the business process system through its robot can intervene and alert participants of the detected issues.

The potential for productivity gains is enormous. Third-party extensions and integrations with Google Wave are going to be a big market. Where nobody can keep track of e-mail threads it’s much easier to – automatically – keep track of waves.

This is the last part of this series of posts on Google Wave. I hope you’ve enjoyed them. The traffic for these articles has been huge. I enjoy writing about Google Wave but I’m not sure if anything remains to be said before the actual release of Wave.

Anyway, I’m looking forward to working with Google Wave and building extensions.

{ 0 comments }

Continued from part 5: version control.

A social network platform has to be able to evolve with its users and with the communities it hosts. Twitter is for now the best example of how the platform – when it is malleable – evolves with its users. More complex platforms like Facebook and Ning are notoriously hard to change according to the preferences of their users.

Google Wave may have struck the right balance to make its entire platform customizable to a large extend. Google Wave offers free-text collaboration as Twitter does. Facebook and Ning have a more versatile data model that offer different kinds of functionality but at the same time creates content jails.

Google Wave offers one content model: the Wavelet. This again is very similar to Twitter which offers the 140 character message as its content model. The big difference between Google Wave and all other social network platforms is Wave’s distributed nature. It is this distributed nature that requires its associative memory architecture and it is this architecture which enables its extensibility.

Wave’s architecture gives organizations across the world the option to safely  integrate their own users and systems in a global social network platform. This reality is comparable to how many organizations across the world today host their own e-mail servers and as such integrate in the global social network called e-mail.

This architecture gives anybody who cares to do so the option to integrate other systems with Google Wave and as such extend the platform for the benefit of her communities of people. In retrospect, it’s not obvious how to build a social platform that users can set to their own hand that is not based on an associative memory architecture. In other words, modern social platforms that users can customize may need to be based on an architecture similar to Google Wave.

Complicated and dedicated data models like Facebook and Ning will probably not be the future of social platforms. Google Wave’s P2P architecture emphasizes the Twitter anomaly: instant messaging through a central server architecture is probably not the future.

Google Wave’s architecture and capabilities as a social platform point to two important new developments: the importance of open standards (see the Wave protocol) and the importance of open-source software. Compare this to MySpace, Twitter, Facebook and Ning which are not only central server architectures but also closed to innovation.

The next and last post of this Google Wave series will be about the marketplace for third-party extensions that Wave will create.

{ 2 comments }

Continued from part 4: collaboration.

Version control is again not the most accessible topic yet it’s inclusion in Google Wave is significant. The version control community has seen quite a lot of upheaval in recent years. We’ve entered the new millennium with one dominant open-source version control tool: CVS.

Then Subversion emerged as a new open-source version control system that tried to address the design issues in CVS. Subversion is an easier to use version control system because it removed many arcane and idiosyncratic CVS headaches.

2005 saw a revolt in version control land with the backing by Linus Torvald of Git, an open-source distributed version control system which is radically different from both CVS and Subversion. With Git developers work on their local repositories instead of a central one as CVS and Subversion demand. Then when it becomes time to upload local changes to a bigger repository two repositories are merged instead of a local copy and a repository.

Google Wave follows the Git approach. Not many details have been revealed yet about Wave’s version control system but this is what is known.  A wave is stored in associative memory and this information includes the complete version history. Hence, a wave is itself a version control repository.

Version control systems provide functionalities like forking, merging, tagging and many others. It’s not clear which features Google Wave provides although during the video members of the Wave team have hinted at elaborate version control features.

Version control is a necessity for any collaborative system, be it software development or any other form of collaboration. Google Wave offers powerful version control features. The most accessible of those features is the playback function but we can expect many more version control features. We can also expect that these features will not get in the way for those who are not inclined to use them. People will easily find their way to the playback button but it will be teams of collaborators who benefit most from Wave’s version control features.

If nothing else Google Wave is the ideal word processor where content can later be pushed into a collaborative context. Version control – present in the background – makes this transition as smooth as possible.

The next post will look at Google Wave as a social network platform.

{ 2 comments }

Continued from part 3: extensibility.

Google Wave in many respects is the ultimate collaboration tool. It can be best compared to Wikipedia but instead of striving for encyclopedic accuracy people can work together to strive for their own outcomes. In doing so they can add all kinds of content, including gadgets and robots that can give a helping hand.

For one thing, Google Wave blurs the line between instructions machines can understand (programming) and human language like conventions, expressions, forms of organizing and so on. Since robots are first-class citizens in wave collaborations they are free to participate and modify content as they see fit. This is quite a ground-breaking development, one we’re not very used to. We’re used to spellcheckers, but we’re not used to a robot intervening to alert us of that fact that there’s no point planning for a picnic since it will rain all day next Saturday.

Robots can for example take the current location of different participants in a wave into account, as far as that information is available. But the key point about collaboration is not so much smart robots, but instant collaboration between strangers which robots can facilitate in.

A wave is only accessible to its addressees and originator. Among those addressees there can be robots who receive every update as do human participants. Imagine every street in the world – or in your city – has a wave where planned road works and other obstructions are announced. If a given robot is a participant in all those waves it can index the scheduled closings of each street.

That same robot can keep track of street names that are mentioned in other waves where it is invited to participate. As soon as the robot can determine from the context of the conversation that a street name is mentioned during a certain period it can then add a message saying this street will be closed.

Things can obviously be taken further. Robots could index where somebody is scheduled to be in the future and draw a calendar automatically. This kind of extrapolation turns waves into harvesting fields for metadata which can again be used elsewhere, thereby enhancing collaboration incrementally.

Robots will be able to be this intelligent because of the structure of waves. Waves actually consist of wavelets which itself consist of blips (also called documents). A wavelet is a part of a wave which can be best compared to a e-mail in a e-mail thread or a message is a discussion forum.

Blips are interventions inside a wavelet, as is demonstrated in the video where participants can comment inside the messages of others. Documents form a tree structure inside a wavelet. Wavelets have a list of participants and a list of documents. From the documentation, it seems as if wavelets can’t be organized in a tree structure but form a list inside the wave instead.

This structure allows robots to walk through the structure of the wave to construct context, assuming that people will add content at that position in the wave where their interventions are most meaningful. This creates a new paradigm in the online experience: our conversations will become easier to understand for robots.

In conclusion, there will be a lot of opportunity to experiment with robots of many kinds. One issue that already arises from this overview is the question: when I add a robot to this discussion, can that robot be trusted? Is it appropriate if my discussion would be leaked to the outside world through the inclusion of an unfamiliar robot? Organizations will be able to deploy third-party robots to their own Wave providers thereby hosting them under their domain (<robotname>@<domain>).

In the next post I’ll look at version control in Google Wave.

{ 4 comments }

Continued from part 2: unified messaging.

Google Wave provides two ways to add new features to Wave: robots and gadgets.

A robot resides on a Wave provider and receives all updates for those waves it participates in. Robots can also update wave content, for example by automatically replacing www.google.com with http://www.google.com. Other examples of robots in the demo video is the spell checker and the translation feature.

A gadget resides on the Wave client (in the browser) and changes the look and feel of the wave. A Sudoku game could for example be a gadget.

Robots are ideal for heavy computations, and when access to external data is required – like a CRM database or a web service – which cannot be accessed by a browser.

Third-party additions to Waves will typically consist of both robots and gadgets. Because organizations will likely host their own Wave providers it will be possible to deploy third-party robots in the safety of their own private networks.

Robots and gadgets can interact and there are probably many opportunities to do so. While robots have a unique username (<username>@<domain>) gadgets are loaded from a URL. It’s therefore plausible that we’ll see some generic gadgets appear like spreadsheets which are independent from robots. That means that developers can build robots that add the spreadsheet gadget and fill it with their own data.

Each gadget has what is called a state. Here information can be stored that the gadget needs to be properly configured, or to display data like in the case of a spreadsheet gadget. Robots can access and modify the state of a gadget. Each time the state of a gadget changes all robots are immediately alerted, and when a robot changes the state of a gadget that gadget is also immediately alerted. Courtesy of Wave’s associative memory architecture.

Hence, it’s most likely not possible to write a gadget which cannot possibly be modified and controlled by other robots than your own. State values could be encrypted, but encryption and decryption in Javascript is no small feat. We’ll most likely see gadgets emerge – like the Google Maps gadget – which can be added and controlled by any controller who chooses to do so.

Third-party gadgets and robots will offer important contributions to how people collaborate which is the subject of the next post.

{ 2 comments }

Continued from part 1: architecture.

Theories and implementations of unified messaging are probably as old as the Internet itself. The basic problem that unified messaging is trying to solve is this: send any type of content to any user regardless of which software they run or what platform they are on.

How Google Wave approaches unified messaging actually both clarifies and complicates unified messaging. The Google Wave team has correctly identified two crucial properties of unified messaging:

1. Certain types of content impose certain kinds of interactions and communication. The P2P communication paradigm for example is inherently part of instant messaging content.
2. Content types are characterized by our shared internal articulations rather than its technical characteristics. Content is a social object.

The Google Wave team has started from these two assumptions and has selected a federated P2P architecture as the default communication paradigm for all content. As mentioned in the architecture post, content is instantly distributed across the shared memory space which a wave represents.

Whether you’re writing an article, a traditional e-mail message, a report, or are just chatting away to coordinate your activities with others it’s ultimately up to the participants in the wave to determine how the content will evolve. Will it end up in discussion, chatting, link sharing, video or picture sharing, instant messaging? It doesn’t matter and it can be all of the above.

In Google Wave the wave encapsulates unified messaging. Every addressee can instantly – and without requiring permission – become a co-author. The wave actually allows us to discover and explore the social objects we have inside us and play with wave content in collaboration with others to enrich the exploration. This is the default mode of communication within Google Wave.

We will constantly be tuning in and out of wave collaboration and discover and share social objects as they emerge. Waves can go on for months or years. Content can be endlessly rewritten and re-organized. Participants can join and leave. And all of that happens in real-time with updates appearing as they happen, potentially originating on the other side of the world.

Collaborative editing on top of an associative memory architecture is relatively new. There exist online word processing tools today which already offer this but most of us aren’t using them. There will be a big uptake in this kind of content creation when Google Wave launches and we can only guess what will happen next. What’s certain is that Google Wave will cause a lot of disruption and emergence.

A critical characteristic of Google Wave’s unified messaging feature is that it will soon be possible to add any kind of content – discussions, chatting, picture and videos, links, data, … – to any kind of information. Do you have an incoming invoice which you can’t make sense of? Just push it into a new wave, add addressees and engage in any kind of collaboration using any kind of content until the answer is found. And do all of that on the record.

It will ultimately be possible to add any kind of information to waves, including existing records in databases coming from sales or procurement processes or any other process. We will be able to slap any kind of content and collaboration on to these records in the form of a wave. For each important record a wave could be created automatically, just like each Wikipedia article automatically has a discussion page. We could even choose to update these records from inside a wave after a consensus in reached. The limits of what we can or are allowed to do will be determined by how flexible our old ways of organizing are. What would happen if every incoming customer complaint would be transformed into a wave?

In this perspective I think Google Wave has really nailed unified messaging to a degree that we haven’t seen before. In fact, we’ll soon all get very busy trying to integrate our existing systems into Google Wave in order to increase our productivity. Google Wave will likely start an arms race in many industries to integrate as much existing information and processes as possible into Wave’s unified messaging, simply because we’ll all realize that not doing so will be a loosing strategy.

This line of thought screams for a roundup of how Google Wave can be extended which is the topic of the next post.

{ 3 comments }

If you haven’t done so already, watch the 1:20 min announcement and demo of Google Wave. Wave is Google’s attempt at world domination and I welcome it.

I’ll write down my thoughts on the unique features of Google Wave in a few blog posts. I haven’t used Google Wave, in fact I’m basing myself on what’s available online today.

In this post I’ll talk about Wave’s underlying architecture based on what is known today. Architecture is probably the least accessible topic I intent to discuss yet Wave’s architecture is probably its most compelling feature. For me Wave’s architecture definitely deserves some closer inspection.

Wave has an associative memory architecture which is characterized by two important features:

1. Content residing in the memory is seen by all nodes in the architecture that have to see it as if that content is local.
2. Any modifications to memory content by any node is guaranteed to be seen correctly by all other nodes, also in the case of concurrent updates.

Associative memory is actually distributed memory, meaning that nodes connected to each other by a network can access the distributed memory as if it was local memory. In other words: associative memory is memory in the cloud.

The best illustration of this associative memory can be seen in the demo: as soon as an e-mail is being written it can already be seen by its addressees, before the author has decided that e-mail is ready to be sent. In fact, in Wave there is no notion of sending a message. The message exists and is seen by all addressees as soon as it is created.

Addressees can see live updates as the authors are typing. This is another illustration of associative memory: what addressees are seeing is their local memory being updated as the incremental update messages arrive. Messages do not have to be sent because they already reside where they have to be: in the local memories of the addressees’ browsers.

Associative memories have been around for many years. The best known implementation is probably the open-source Terracotta (Java). There have been Javascript implementations around as well, in particular Google Web Toolkit implementations.

However, what the Google Wave team has done is remarkable. They have taken the XMPP protocol and have extended it with their own associative memory protocol. You may not have heard of XMPP before, but you’ve probably heard of Jabber or Google Talk. That’s right, XMPP is an instant messaging protocol!

Google Wave’s associative memory implementation actually consists of two integrated architectures: a client-server architecture and a server-server architecture. The difference between the two architectures is that in the server-server architecture updates are sent between servers on behalf of users. The official name for a Wave server is a Wave provider.

It’s not entirely clear from the Wave protocol documentation whether XMPP is used between client and server although it’s probably the case. Regardless, each Wave provider holds one copy of each wave which includes the wave’s history. Each addressee also holds a local copy of the wave.

This is a walk-through of what happens when a client updates a wave in the case where all addressees are hosted on the same Wave provider:

1. The client sends an update message to its Wave provider which holds the operation that has happened on the client. For example, if one letter was removed at position 10 the client would send this message: “Remove the character at position 10 in wave id X”.
2. The Wave provider queues this message for later processing. The client doesn’t send any further updates until it receives an acknowledgement from the Wave provider for this message.
3. The Wave provider processes the message as it pops out of the queue. The provider’s copy of the wave is updated. The Wave provider also broadcasts the same operation to all other clients and Wave providers which have to see updates to the affected wave (the clients of the addressees of the wave).
4. The Wave provider sends an acknowledgement to the client where the change originated. That client can now continue to send updates.

When the Wave provider processes update messages the affected wave is locked. This means that on the Wave provider updates do not happen concurrently. On top of that, broadcast messages are immediately processed by clients. This means that clients may process other updates while its own updates are pending acknowledgment by the Wave provider.

Critically, each Wave provider holds its own copy of a wave. That means that Wave provider have to process broadcast messages originating from other Wave providers. Broadcast messages from other Wave providers are handled in almost the same way as updates originating from clients:

1. A broadcast message arrives from another Wave provider and is stored in a queue for later processing.
2. The Wave provider processes the broadcast message as it pops out of the queue. The provider’s copy of the wave is updated. The provider also broadcasts the same operation to clients it hosts which have to see updates to the affected wave.

Through this architecture, updates between addressees on the same Wave provider never leave that server. This is critical for organizations that want to prevent sensitive content from leaving their private networks. There organizations can host their own Wave provider for their own users so that sensitive content never leaves their private networks. On top of that, messages between servers are encrypted to ensure the authenticity of update messages.

Each user is hosted on one Wave provider. This means that the user connects to the user interface of that server and depends on that server to propagate updates across the Wave space and receive updates from the Wave space. User names are like e-mail addresses: <username>@<domain>.

Google has announced that the Wave provider software as well as client software will be open-sourced. This means that organizations can run their own Wave providers as they now run their own mail servers.

The Google Wave architecture providers a powerful federation protocol that together with the other Google Wave features will prove to be highly valuable for its users. Interestingly, Google has not abandoned the old e-mail architecture where anybody can choose to run their own e-mail server. This makes the federation principle even more powerful since organizations and users can now choose to protect their sensitive content in the security of their own networks.

Google Wave solved an old Google Apps headache where users and organizations didn’t want to store their own content on Google servers. Since Google Wave will eventually also offer spreadsheet and probably also database functionality Google now has a very powerful, federated productivity suite offering.

In the next post on Google Wave I’ll look at Wave’s unified messaging features.

{ 8 comments }

I’m writing on this blog for everybody, anywhere yet this is a post on the region where I live. Flanders is the biggest region of Belgium, located in the North of the country. Flanders is one of the wealthiest regions in Europe with a purchasing power of 23% above the European average.

We can all learn a valuable lesson on how not to invest in innovation from the Flemish example which is why I share this post with you. Since at least the early 1990’s – that is since I can remember – the Flemish government has focused on two innovation strategies:

1. Change the economy into a ‘knowledge economy’.
2. Stress the need for more engineers.

Turns out these two strategies are absolutely worthless for generating growth which is the point of innovation. The core problem that has hijacked government policy for at least two decades – two very crucial decades – is the mistaken view on growth.

The Flemish economy entered the last decade of the previous century as a export-oriented economy with as major export products half-finished products (steel, iron, chemicals, plastics, petroleum derivatives, …), food, cars and textile. The plan of the Flemish government has always been to expand these sectors and encourage innovation to reach this growth. Also, the Flemish government believes innovation requires engineers, period.

It’s easy to see what has happened. The obvious choice has always been to keep and expand the industries that are already there, especially when they are booming. There’s nothing really wrong with that, except that it’s always been assumed that these industries will remain strong forever and that everything should be done to contribute to that.

There are two views on innovation:

1. The 20th century view on innovation, which in Flanders has always been understood by the government and the industry as means to increase efficiency.
2. The 21th century view on innovation which is radical, subversive innovation; and which is feared very much in Flanders.

Core to the distinction between both views are two radically different views on growth:

1. 20th century growth which is articulated in terms of impersonal national currencies.
2. 21th century growth which is articulated in terms of outcomes for people as they are prioritized and experienced by people.

20the century growth is very simple, very easy to aggregate. It’s the kind of growth accountants can calculate and managers can aim for. 21th century growth is chaotic, very confused, very dialectic and at this time cannot be aggregated.

It’s not hard to understand why the Flemish region has gone for 20th century innovation, but it’s not obvious why 21th century innovation has been ignored. Countries like Finland realize that innovation in their existing industries alone will never create sufficient growth to address the challenges of the future. Instead entrepreneurism is required to subvert the dominance of the status quo.

Becoming an entrepreneur in Flanders and in Belgium is actively discouraged by the state bureaucracies, but that’s another discussion. More importantly, the Flemish government believes that future growth lies in its existing industries and that other industries can arise as long as they do not undo the existing ones. Radical change – hence – is not allowed.

This means that new industries are welcome to integrate with the existing economic networks but are not allowed to help destroy them. Players in new industries – especially young ones – are then left with only one option: become suppliers to the existing industry giants in Flanders and not subvert the status quo.

Radical 21th century innovation feasts on turbulence. This turbulence is a reality, only the Flemish government does not want to recognize this. They want pathways that let the status quo grow, and they’re not interested to hear voices that say this may not be an option.

The Flemish Innovation Mistake assures a shrinking economy while other European countries are working on innovation strategies that ride the waves of turbulence. The status quo is held so dear that the Flemish government has closed the door for innovation without permission.

The key insight the Flemish government will have to come to terms with in order to restore innovation and growth is that of the learning economy: that learning – doing things you’ve never done before – itself is growth. That learning is not a pathway to growth, but that learning is growth.

We’ll have to start realizing that learning, innovation and growth are actually synonyms, literally. There’s no objective difference between learning, innovation and growth. There’s not a single European country or region that’s basing its assumptions on this key insight or that is rearranging its infrastructure and resources accordingly. That – my friends – is an opportunity.

It’s not too late for the Flemish government to change its course and take action. The Flemish people have to accept that the status quo cannot be saved, under no circumstances. The unfolding closing of the Opel factory in Antwerp is a timely reminder of this reality. When the news of the closing will roll in many of us will feel defeated. It is in this moment of despair that the Flemish people will get the opportunity to think about how we’re all related to each other and what we can do better together.

That seemingly unreachable innovation and growth lies hidden in learning how to come together. Discovering that we’re all sharing the same frustration is doing something we haven’t done before. Coming together out of this frustration is doing something we haven’t done before. Taking these uncertain steps is learning, is innovative and creates growth.

We can invent thousands of reasons for not doing anything but since we’ve been doing this all along we’re not learning, not innovating, and not growing. We’ve been frustrated by how innovation has been practiced and handled so far and remaining frustrated without alternative action is not learning, not innovative, and doesn’t create growth. I could go on.

The point is that the Flemish government doesn’t get any of this and maybe they will in one year or ten years from now. We’ve all been depending on the government for such a long time that there’s nothing to learn there either. We have to come together. It’s the only option simply because this is the one thing we haven’t done before.

By coming together I mean actually meeting each other, listening to each other and getting to know each other without agenda. It’s completely uncertain and because we’ve been avoiding it all along it’s learning, it’s innovative and it will create growth.

The people in Flanders that care about radical innovation have been coming together for a while now, that problem has been solved. The people that need to come together are those that don’t see a way out. Networked frustration is the fuel of change.

Let’s network the frustrated people who are out there in Flanders.

{ 0 comments }