Thruflo d.o.o

The shift to post-purchase manufacture

Wed, 09 Apr 2014 14:51:02 +0100

The fundamental thing about digital fabrication is the shift to post purchase manufacture.

The moment when a product is fabricated is a moment of crystalisation. An abstract design becomes a concrete product. A world of possibilities is reduced – irreversibly – to a single form.

Delaying that moment of execution until after purchase allows the world of possibilities to overlap with information about the purchaser and their context. The reduction of a product to its concrete form can be informed by this information: be it ergonomic, environmental, personal, social.

Companies who design products that adapt to contextual information will have a competitive advantage. Phones that just fit your hand. Furniture that just fits your space. Gadgets that just fit your lifestyle.

To do so, practically, they need to master their designs as parameterised applications: to publish the underlying logic of their models, not just static vector exports. At this point, the consumer experience can shift from radio buttons to sliders, as we can see in the first generation interfaces of Digital Forming and Matter Machine.

The next generation – the point where a wider consumer market is unlocked – is the implicit application of contextual data. Data generated by an app on your mobile is fed into the design-as-application and the implicitly personalised form emerges.

Inside the Distributed Manufacturing REPL

Wed, 24 Jul 2013 14:17:00 +0100

Alastair Pavan from WikiHouse often quotes John Maynard Keynes as saying:

> “It is easier to ship recipes than cakes and biscuits”

I want to argue that the interpretation of these recipes (the “eval” part of the read-eval-print loop) is – far more than the usual hype – what’s really interesting about distributed manufacturing.

I was fortunate to be at the Design Museum’s Future is Here exhibition launch in London last night. The exhibition itself is exceptionally well curated by Alex Newson: putting the new developments in a whole range of manufacturing sectors in context, both relatively and historically.

The “Future is Here” sign at the Design Museum.

What connects all these future manufacturing technologies is their ability to be digitally driven and to manufacture at the edge of the graph, rather than the centre. The real nugget of promise at the heart of the universal replicator idea is the ability to fabricate consistently on location. To ship the recipe like a fire-and-forget AJAX request.

That this promise is a myth is well known and widely debunked; whether it’s the “dirty secrets” defined by the UK Technology Strategy Board in their recent Additive Manufacturing competition, or the fact that all the major 3D printing companies (Shapeways, Ponoko, iMaterialise, etc.) centralise and obsessively quality assure output – just to be able to produce passable necklaces and lampshades.

Genuinely distributed manufacturing, in truth, still requires a craftsman at the edge of the network. No matter whether they’re operating a numerically controlled drill bit or a sewing machine. This is something I know well from my work building OpenDesk.

Community Wall on the OpenDesk website.

OpenDesk is a small, deliberately constrained range of simple furniture that can be made using a CNC machine. The designs are released open source for free (under a creative commons non-commercial license) and available to buy through a distributed network of professional CNC makers.

One of the unexpected moments of serendipity developing OpenDesk was when we found out that the Spoke Creator team in New Zealand had taken the open source designs and parameterised them. Parameterisation is where a design is modelled using logical rules so that it can adapt to changing dimensions, e.g.: “make the legs 90% of the height of the table” or “if the table needs to support 100kg, then double the thickness of the legs”.

Parametised OpenDesk design on Spoke Creator.

Now, whilst many designs are mastered in this way within design studios (on expensive proprietary software), very few are exposed in this way to consumers or the fulfillment chain. There’s good reason for this. Every option presented to a consumer is a barrier to sales. The idea of presenting complex logical network wiring to a consumer is crazy. They don’t want choice: they want what they want and they certainly don’t want to have to engage with complexity.

Which is where apps come in.

There’s an analogy here with web video. In 2005, web video sucked. It came in small rectangles (we’re talking pre vp6, let alone h.264), buffered, crashed and, when compared with TV, was barely watchable. Yet fast forward to today.

Fundamentally, right now, distributed manufacturing is expensive and hard to quality assure. It may provide jobs, lower carbon and increase transparency (in what is one murky global supply chain). However, these are soft incidental benefits divorced from the consumer decision. What distributed manufacturing really offers is programmability. Just as the benefits of web video being interactive and on-demand outweighed its pixelation, the hackability of designs mastered as applications for distributed digital manufacturing outweigh cost and complexity.

The first step is to move manufacture post-purchase. Much as with many existing lean manufacturing processes, products do not sit pre-made on shelves. The next step is to master a design as an interpretable recipe. If you like it medium-hot, add a red chilli with the seeds removed. Then apply contextual and personal data. Ergonomics, environmental shape, previous preferences, personal profiling, social data.

Providing external data to parameterisation is something even we can do, already. Once you have digital designs and post-purchase manufacture, this is “just work”. However, in this age, it isn’t about the designer encoding the variety into their application. It’s about the ecosystem.

Instagram filters… applied to the real world.

Apply filters and effects, Instagram style. Open source your surface texture library. Run your application through a middleware pipeline. Think WSGI and Yahoo Pipes. These are not new architecture concepts. In web development, obviously an application can be themed. Obviously a data structure can be transformed.

If these structures are open, then obviously there is huge scope for innovation, serendipity and network effects. Like a shit-hot hacker team in New Zealand taking your open source designs and parameterising them.

This is the phase-change. By keeping manufacture in the digital space for as long as possible and by mastering designs as applications, distributed manufacturing – if we can keep it open – will unlock a radical new app and api eco-system of programmability that’ll transform what it means to design, manufacture and buy products.

Intelligence & Life: two sides of the same coin

Sat, 20 Apr 2013 10:30:00 +0100

New research builds directly on the Schrödinger, Stuart Kauffman canon to derive not just life but intelligence from entropy. In What is Life?, Schrödinger defines life in thermodynamic terms, i.e.: entropy (or disorder). In At Home in the Universe Kauffman shows how order spontaneously emerges to create life. Now, Alexander Wissner-Gross (aka @alexwg), “a physicist at Harvard University and the Massachusetts Institute of Technology”, has published research showing how intelligence emerges from the goal of maximising entropy.

The researchers developed a software engine, called Entropica … In one test, the researchers presented Entropica with a situation where it could … move a cart to balance a rod standing straight up in the air. Governed by simple principles of thermodynamics, the software responded by displaying behavior similar to what people or animals might do, all without being given a specific goal for any scenario.

Entropica’s intelligent behavior emerges from the “physical process of trying to capture as many future histories as possible,” said Wissner-Gross. Future histories represent the complete set of possible future outcomes available to a system at any given moment.

Wissner-Gross calls the concept at the center of the research “causal entropic forces.” These forces are the motivation for intelligent behavior. They encourage a system to preserve as many future histories as possible. For example, in the cart-and-rod exercise, Entropica controls the cart to keep the rod upright. Allowing the rod to fall would drastically reduce the number of remaining future histories, or, in other words, lower the entropy of the cart-and-rod system. Keeping the rod upright maximizes the entropy.

“The universe exists in the present state that it has right now. It can go off in lots of different directions. My proposal is that intelligence is a process that attempts to capture future histories,” said Wissner-Gross.

If this is right, then the same force that creates life – the intentionality of physical systems to minimise order within the body – also leads to intelligence – the intentionality to maximise order outside the body. Every action has an equal and opposite reaction.

Intelligence and life are two sides of the same coin.

WebSockets with Varnish and Nginx

Thu, 17 May 2012 13:57:00 +0100

Nginx is the obvious front-end web server for non-blocking web applications. However, Nginx doesn’t currently support WebSockets (at the time of writing the feature is on their roadmap with “No date set”).

You can compile Nginx with the tcp module to proxy WebSocket and HTTP traffic to different backends. However, as well as introducing the manual compilation step, this also requires running multiple web applications (for example, your main app on one port and your WebSocket handlers on another).

A more elegant solution is to put Nginx in front of your backend web application and Varnish in front of Nginx. Varnish can then be configured to pass WebSocket traffic directly to your backend whilst sending the rest of the traffic to Nginx. This allows you to run a single backend server that handles WebSockets and HTTP traffic on the same port without patching Nginx.

Here are the essential configuration directives for a setup where I’m running a Gunicorn server as my backend web application. You could just as well be running Node.js, Tornado – whatever.

Run Varnish on port 80 with this in your default.vcl:

backend nginx {
    .host = "127.0.0.1";
    .port = "8080";
}
backend gunicorn {
    .host = "127.0.0.1";
    .port = "6543";
}
sub vcl_pipe {
    if (req.http.upgrade) {
        set bereq.http.upgrade = req.http.upgrade;
    }
}
sub vcl_recv {
    if (req.http.Upgrade ~ "(?i)websocket") {
        set req.backend = gunicorn;
        return (pipe);
    }
    else {
        set req.backend = nginx;
    }
}

Run Nginx with this in your nginx.conf (these are just the key directives – see the Gunicorn docs for a more complete configuration examples):

upstream gunicorn {
    server 127.0.0.1:6543;
}
server {
    listen 8080 default;
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://gunicorn;
    }
}

An implementation detail of this particular example is to then use a WebSocket aware worker class in your Gunicorn configuration. For example:

worker_class = 'pyramid_socketio.gunicorn.workers.GeventSocketIOWorker'

However that’s more a matter for your specific backend implementation. The point of the Varnish and Nginx configuration above is to deploy any backend so that WebSockets just work.

The Conventional Wisdom on Business Plan Numbers in a Lean Startup is Wrong

Sun, 06 May 2012 15:41:00 +0100

There’s about as much point producing a finance plan for a lean startup as there is writing a post-graduation CV for a toddler. Pretty obvious, right? Except it’s completely wrong: lazy, convenient thinking that misunderstands the relation between numbers and visibility.

We all know that a startup is a search for a business model and that in a startup, visibility is often extremely limited. How can you possibly make financial predications when you don’t even know what your value proposition is? Well, the answer is that you can, you should and that it’s actually very simple once you understand the role different numbers play and how they fit together.

Let’s take an example. You’re looking for seed funding for your new web service. Your angel (or perhaps your boss) has asked to see numbers up-to a five year horizon. Now, you’re asking for money in the first place because you need to resource a team to build your product and operate your business. That means you have a burn rate (or perhaps you have multiple candidate burn rates depending on how well / badly the business goes).

For each burn, the rate tells you what you need to earn: either to break even or to make the return you or your investor wants. If you’re going to spend an average of $250k per year over five years, you need to earn, on average (let me help you out with the figures here) $250k per year over those five years to break even. Maybe that revenue isn’t going to start arriving until year three. Maybe your business is going to take off like a hockey stick. You can shape the graph any way you like but there’s no escaping the fact that the total area underneath the line needs to at least match your burn.

Now, let the penny drop. These numbers — let’s call them your targets — are derived from necessity. They’re nothing to do with your actual or likely performance. Which means they have precisely nothing to do with your visibility, limited or otherwise.

All the other numbers (which are more or less visibility dependent, like your total addressable market and predicted revenue per user) are in your plan to shed light on the likelihood of hitting your targets. Their role is to make your targets (which you must hit) look hittable: not just for your investor but for you.

Let’s just recap for a second. You need X amount of money to build your company. That means you need to make X amount of money back. Identifying the size of the market you’re planning to enter (or create) and the likely market share of the handful of leading companies (which you plan to be one of, right?) is not a pointless exercise. It’s a basic sanity check. If the market’s big enough then perhaps hitting those targets isn’t so unlikely after all.

Equally, if your graph tells you you need to earn $40k per month in Y3 and you have a set of candidate revenue streams that allow you to guesstimate revenue per user, you can derive a target for the number of users you need by then. Plug that into some key metric spreadsheets (maybe measuring user acquisition and engagement over time) and, voila, you have a set of evaluation metrics you can discuss in your SCRUM meetings.

Metrics that are entirely consistent with the murkiest visibility and the leanest of startups.

You're Building Cultural Survival Vehicles

Sun, 18 Mar 2012 20:39:19 +0000

Here’s a powerful new way of looking at the world – and one that’s exceptionally relevant for people building communities or designing social interactions. I quote from the introduction to Wired for Culture by Mark Pavel, head of the Evolution Lab at Reading University:

I want to call these tribal groups cultural survival vehicles. … Richard Dawkins in The Extended Phenotype coined the term vehicles to describe structures that carry replicators. … Putting these two ideas together, we can see that replicators (think of genes) exert their effects on the external world, and thereby influence the likelihood that they will survive, through the vehicles (think of your body) they build. The distinction between replicators and vehicles is important because it reminds us that an animal’s body is merely a temporary structure built by its genes to promote their survival and reproduction. …

When I use the term cultural survival vehicles, it is to capture the idea that our species evolved to build, in the form of their societies, tribes, or cultures, a second body or vehicle to go along with the vehicle that is their physical body. Like our physical bodies, this cultural body wraps us in a protective layer, not of muscles and skin but of knowledge and technologies, and … gives us our language, cooperation, and a shared identity. We are the actors that produce this vehicle, behaving almost like individual genes clamouring inside it to exert our effects on the outside world, and influencing our likelihood of surviving. Our nature is wrapped up in the strategies we evolved and now deploy to make the cultural survival vehicle work for us. …

The essential balancing act of human societies is that they will normally work best when everyone pulls together, but at any given moment what is best for you might differ from that which is best for your group. Our psychology is the outcome of this balancing act. It is the set of temperaments geared towards using our cultural vehicles to promote our individual survival in a world full of others like ourselves.

Culture is a phenomenal evolutionary advantage. Because of this, we’ve adapted to be exceptionally receptive to it. Our rich social and cultural landscape is made of interwoven vehicles we’re programmed to create, join, pilot and abandon. A theory which maps precisely to the real world, as far as I understand it.

Knight News Challenge: BeLive.at

Sat, 17 Mar 2012 09:02:50 +0000

Knight News Challenge: BeLive.at:

newschallenge:

1. What do you propose to do? [20 words]

Build a citizen journalism platform where the crowd direct the news.

2. Is anyone doing something like this now and how is your project different? [30 words]

OpenIDEO is a structured platform where the crowd can solve social problems.

Twitter is a…

"Whoever takes the decisions bears the risk."

Wed, 29 Feb 2012 09:49:18 +0000

“Whoever takes the decisions bears the risk.”

- A simple principle for pricing risk into development projects. Whoever makes feature decisions and signs off on implementation should carry the risk of scope creep or non delivery.

As an agency or a developer, you can provide fixed cost development budgets but only when you decide what’s in or out and what done looks like. (More accurately, you decide on done, done done and done done done). Where it’s not appropriate for you to own the delivery decisions, it’s not constructive for you to bear the risk.

After all, as the great command line in the sky says, with power comes responsibility…

The Silent Future

Sat, 28 Jan 2012 15:05:00 +0000

jQuery is the de-facto library for the web, installed on 85% of websites. There are calls for the last few major release versions to be shipped in all major browsers. However, look what just came along. Two way data binding in the form of <angular />, Ember.js and friends. Suddenly the very thing that jQuery is so good at, DOM manipulation, is abstracted out of the picture.

The lesson, which we all know, is that change comes not from beating the incumbent at their own game but from focusing on what’s going to make their strength redundant. The interesting thing I’ve just realised is that the Internet makes communication redundant.

So far, the main impact of the Internet has been to change the way we communicate. However, the real shift is towards a pervasive web where information is implicit. Just as <angular /> abstracts out DOM manipulation, implicit information abstracts out whole tranches of activity. Communication, for so long the core skill of successful brands, people and organisations becomes entirely irrelevant.

It may be tempting to view a future of no communication as a land of the blind where the one eyed man is king. In a world with no marketing, surely the business that buys ads will thrive? However, this misses the pivotal cultural shift. As HG Wells illustrated so well, people’s behaviour is governed by the culture they operate in.

Ours has already changed, forever.

Getting Things Done with Google Apps and Do.com

Mon, 23 Jan 2012 16:49:53 +0000

I was chatting with @h4rrydog a couple of days ago about the best tools to collaborate “internally”, i.e.: between ourselves and with ad hoc teams of other people. Every man and his dog has their preferred workflow but I just setup one that’s so delightful I can’t help but share it.

The setup is to use a Google Apps email address (n.b.: #) with Do.com. The workflow is to use the little gadget Do.com installs into your gmail interface to turn emails into tasks. The task title is autocompleted with the email subject. There’s a small link to populate the task description with the email body and autocomplete widgets to assign the task to a person, a project and a due date.

It’s zen. Try it a couple of times. Headspace zero.

Released pyramid_assetgen package.

Mon, 16 Jan 2012 19:21:00 +0000

I’ve released a Python package called pyramid_assetgen that helps integrate Tav’s Assetgen static build tool with the Pyramid web application development framework. As the docs say:

Using it allows you to code in languages (like CoffeeScript and SASS) that compile to JavaScript and CSS, swapping between a refresh-the-page-to-see-changes development environment and an optimal HTTP caching production setup – without ever having to change any of the code in your Pyramid application.

The Dominatrix and the Case of the Missing Tools

Sat, 07 Jan 2012 16:30:00 +0000

When I first heard about the BBC’s Sherlock, my heart sank. Talk about flogging a dead horse.

Sherlock Holmes and Dr Watson’s adventures in 21st Century London. A thrilling, funny, fast-paced contemporary remake of the Arthur Conan Doyle classic.

Last night, I watched it for the first time. It was exceptionally good. Bursting with character and rapier dialogue. The problem was that no matter how engrossing the drama, I kept being jolted out of my suspension of disbelief by the tenuous clips dropped in to reiterate the plot.

There is a scene where Sherlock cracks the code to a particularly alluring dominatrix’s safe. The code we see him entering immediately explains how he does it (spoiler alert: it’s her vital measurements). However, just to make sure that every viewer gets it, the dialogue has to lapse from rapier into journeyman so the dominatrix can laboriously explain this to Dr Watson. Later on, they parachute in a remarkably artificial clip where Sherlock summarises the entire plot, for no reason whatsoever, to two henchmen driving him to the airport.

I mention this because it illustrates the difference between mass media and the web. (As with most years) it’s widely predicted that in 2012, TV and the Internet will really converge. We’ll have Dropbox logos on our flat screens and our iPad alongside the remote. TV that puts the user in control of what they watch and how they watch it. The joy of which is that viewers who get the plot first time round needn’t suffer the tedium of its reiteration.

What’s interesting is that, whilst this is the inevitable consequence of convergence, content production companies are almost entirely untooled for the future that’s rearing up in front of them. Consider a standard production workflow. You have footage captured to disk, an edit and a mastered file. When delivered over IP, this file is streaming using something like rtmp://.

Now, if we want to personalise the stream of content, this is perfectly doable. Something like FMS or Wowza can serve content dynamically based on information provided. However, as the documentation testifies, the techniques to do this are incredibly low level. There are no simple libraries like Popcorn.js.

For user centred content to become ubiquitous, we need some building blocks, like:

a standard “uccp://” prototcol for responsive, user centred content streaming
modules for web servers that implement the prototcol
libraries for application developers
plugins for content authoring software to master and publish responsive content

I’m sure there is a lot of relevant technology out there. However, can it be cohered around by both producers and developers in the way they can cohere around web frameworks like Drupal and Wordpress? It looks to me that the networks and the data are there but that the tools are missing.

Interesting stuff over Xmas

Wed, 04 Jan 2012 10:37:40 +0000

Back this morning after a break in Croatia and Prague. While I deliberately left my computer at home, my information addiction was strong enough to have me peeking regularly at my phone.

The best post I read was Everything is a Service, on the shift to a service oriented economy. I also enjoyed this clearly written reminder on the different ways to go viral.

Cory Doctorow’s keynote on The Coming War on General Computation, in tandem with the whole SOPA drama, seems to have re-energised the fight for freedom on the Internet. I don’t know about you but I did enjoy witnessing GoDaddy’s karmic reward for the appalling UX they’ve inflicted on us for all these years.

Now we’re officially in the year of the Dropbox clone, Insync landed with Google Docs integration. Gitdocs kicked off the open source alternative beauty parade. Sit back and enjoy.

Other open source projects I liked the look of were TouchDB and this Node.js JavaScript sandbox. Schedulables seemed like a good idea and Quicksand looked like a company worth keeping an eye on.

Beyond that I mainly got myself irrevocably confused by reading The Time-traveller’s Guide to Medieval England whilst exploring Prague with a Lonely Planet guide. Czech culture and that of fourteenth century England will now, for me, be forever hazily intertwined.

Filter by Proximity, Sort by Most Recent

Fri, 09 Dec 2011 20:14:00 +0000

This post is about a user interface pattern, a common use case for it and an example implementation. The pattern is adding an extra dimension to a timeline. The use case is showing results that are both recent and nearby. The example implementation uses a slider widget and an adequate-result-volume algorithm.

When you have 1000 messages and you want to prioritise the best 50 to display, sort is the most common pattern. If the user is interested in the latest messages, sort by most recent. If they want to see the messages other users found interesting, sort by a metric like views or rating. However, the web is increasingly about real time data. Developers are processing streams and modelling tubes instead of tables. It rarely makes sense to display real time data in any order apart from most recent. So, what do you do when you want to prioritise by another dimension, like proximity or rating?

You apply a filter. In the case of a discrete filter like a keyword or tag, this is relatively simple. The user types #architecture into the search input and Twitter obliges. However, in the case of a range filter like rating or proximity it’s not quite so simple. The user types near:london and Twitter, once again obliges. The subtle difference is that, in this case, Twitter makes an assumption for the user. It applies a default radius (aka default range). "Near" actually means "within 15 miles".

Compare the result volume of near:london with the result volume of near:abergavenny. In the first case (London) the result volume is so high, I may well prefer “near” to be more focused; perhaps meaning a radius of 5 miles. In the second, the result volume is so low I may prefer to widen the search to yield more recent results. Had I chosen somewhere really remote, would there have been any recent tweets at all?

Guessing a default radius introduces the risk of a bad user experience, whether through noisy results or a dead end. This can be avoided with an algorithm that prescribes the desired result volume and varies the radius or range. Let’s walk through a concrete example, written in Python and CoffeeScript using SQLAlchemy and a spatially enabled SQL database.

(Before I do, let me note that this implementation was inspired by Tav’s work on the original Placestation website, where he designed, implemented and introduced me to the algorithm. I am just the messenger.)

The following gist provides example code showing how to store and query geolocated Messages. Note that the location is stored as a Geography Type. This allows us to use a latlng projection (SRID 4326) whilst still accurately querying for results within a distance provided in metres. (If you’re not familiar with map projections, it’s worth getting your head around them before you bite off any geolocated data modelling).

If you have the dependencies installed (easy_install sqlalchemy and geoalchemy) and a spatially enabled SQL database running, you can download the script, edit the DB_SETTINGS on line 20 and run using:

python test_geography.py

With that under our belt, let’s look at how we query our Messages. To work out the radius that will yield the desired result volume we can follow this pattern:

* start with a default radius (one we just make up, e.g.: 15km)
* perform a query with that radius as a filter
* evaluate the number of results:
    - if we got too many, repeat with a tighter radius
    - else if we got too few, repeat with a wider radius
    - else we have an adequate result volume =D

This next gist abstracts out the relevant parts of the previous test_geography.py script into a LocationMixin class that can be mixed into any SQLModel class. The get_distance class method on line 113 implements the pattern above using a left-node-right algorithm.

This allows us to write query code that looks like this:

With this code exposed in a request handler, all we need now is a user interface. I’ve collated a few files into a small example app on GitHub here. You can clone the repo, edit the db config as before and bootstrap and then run the example using:

python model.py
python app.py

If you goto localhost:8080 you should see something like this:

As the page has loaded, we’ve initialised a LocationBar widget and an IndexPage view which both share access to a distance object.

When the page loads, the IndexPage view makes a request to /query, with the user’s current geolocation. The request is handled with our query code from before. Because no distance parameter has been provided, the app uses our get_distance method to calculate a filter radius that will return a good volume of results.

When you bootstrapped the app, you generated 500 messages with random locations. If you now play with the location slider, you’ll see the message numbers change as your query now supplies a specific distance parameter. The more you increase the distance, the more recent messages you will get, as more messages are within the filter radius. At lower distances, we start getting all the messages within that radius (down to no messages at all), rather than just the most recent.

If you refresh the page (to get the initial result again) I hope you can see the value of the algorithm in showing you an adequate volume of results that are both recent and nearby. I’d also love to know if this post has proved useful to you or if there are bits that aren’t clear, so do post any comments below.

Togethr as Earthquake Smoothing System

Sat, 22 Oct 2011 13:53:00 +0100

Togethr is an app platform and social marketplace with aspirations to become a social economy. Why, you might ask, do we need a new social economy? Because to treat an illness you go to the cause.

Ever since Keynes, governments have borrowed money to stimulate growth in order to protect jobs. The cause of the economic crisis is not debt but instead the need for job security. Job changes are like earthquakes, they can shatter a life. If job losses were not so shattering, we would not need to borrow to ensure they don’t happen. (Nor would we need to be so nervous about the day of reckoning when the credit runs out).

We smooth quakes by inducing small shifts. When vocational shifts are on the scale of project or task there is no need for job security. Togethr provides a means to earn a crust without having to have a job, a contract or, for that matter, permission. Social security without the tax burden or disincentive to work.

From WikiHouse to #Manyfacturing

Tue, 20 Sep 2011 15:30:00 +0100

I’ve been part of the team behind WikiHouse. It’s a fascinating project that points to a future where the Internet disrupts manufacturing.

WikiHouse is an open source construction set. A standard for designing houses that can be made using CNC milling technology. On one level you can download, print and assemble ready-designed houses. On the other you can tweak, share and combine componentised designs.

Micro-processing technology moved computing from the university to the pocket. CNC milling and 3D printing are digital fabrication technologies moving manufacturing from the factory to the garage.

As access to the hardware opens up, the number of people experimenting will increase. We’ve seen in software that, with the right infrastructure, open source will rapidly outstrip proprietary design. Architecture and product design is currently done in silos, without the serendipity of the pull request.

Those sectors will inevitably be disrupted. As The Guardian said about WikiHouse:

> “Such open platforms, using the creative commons, are one of the major forces that will change our conception of design in the near future.”

If you’re interested in getting involved, 00:/ are organising a series of community events.

View from the Hub Westminster

Thu, 15 Sep 2011 17:04:00 +0100

Absolutely knocked for six at the view from the Hub Westminster boardroom.

Talk about the Format

Mon, 11 Jul 2011 09:57:59 +0100

A few weeks ago, I hosted a lunch at the Sheffield Doc Fest. It was billed as being about how documentary makers can make effective use of the web. The vast majority of documentary makers were asking the wrong question:

how can I use the web to fund and distribute my documentary?

Let’s pretend for a moment that the web for documentary makers is YouTube. YouTube provides publishing, not distribution. You can get your content up and out there but you don’t get a ready made audience for it.

For distribution (an audience) on the web, you need pull. You need to be a content publisher that people seek out, subscribe to, share and respond to. As Seth Godin has been saying for a long time, it’s about tribes, about leading a movement.

The opportunity the web affords documentary makers is to build pull through the format. As we seen everywhere from the Camp Nou to the X-Factor, fans love to feel that they’ve co-created the narrative. The activity and sense of co-creation breeds advocates.

Providing opportunities for profound co-creation, be it through trans-media, non-linear or interactive documentary making, builds pull. Documentary makers and digital thinkers need to talk together about the format, not how to distribute it.

Safety in Numbers

Thu, 07 Jul 2011 10:22:10 +0100

Yes, the media need the book thrown at them (and, as HUGE says it’s not just one tabloid but all of them). But how on earth were the voicemails accessed in the first place?

The phone companies left the back door open, effectively issuing everyone with a default password of 1234. If I did that as a web developer, I’d be hung out to dry. There’s no question that it was calculated incompetence: the sales team shouted down the head of security.

If we learn one thing from phone hacking it’s that it’s no use being a dumb user: you can’t rely on the invisible hand to keep your data safe. It’s too busy making money.

It's called a Pull Strategy

Fri, 01 Jul 2011 10:37:00 +0100

What should leaders think about? What’s the strategic conversation that cuts to the heart of the matter?

If you look at my last post, it’s all about web strategy and content strategy. We know that the web has disrupted and continues to disrupt everything, so it’s clear that organisations need a strategic approach to it. However, one of the fascinating things to learn from Jonathan Kahn was how he uses content strategy as a trojan horse: a conversation starter leading to something more fundamental.

Yesterday was my first board meeting as a Trustee of London Creative Labs. The two founders, Mamading and Sophia are setting out on a journey to demonstrate and refine how jobs can be created through local enterprise: skills camps to build confidence and capacity, labs to stimulate social enterprise startups and incubation to help those startups grow.

The conversation, largely steered by Gloria Charles, ranged across topics, including outreach and communication. Part of the challenge is to engage people on the ground and part is to show the world there is a better way to create work. To deliver on the second part, Mamading and Sophia need to develop pull.

They need to build a profile and following to benefit from the acceleration and serendipity provided by people, organisations, clients and funders seeking them out and - here’s the real point - so does everybody else. London Creative Labs is a great illustration of a general truth.

Web, content, communication and even business strategy are secondary to pull strategy. The web is a channel to build pull. Content is a means of building pull. You communicate to build pull. Business is a matter of pull.

Discussing pull is the most fundamental strategic conversation.