thruflo

Contiguous Persistence

2009-08-19T00:00:00-07:00

Contiguous Persistence

19 Aug 2009 – London, UK

I lent a book not so long ago to a friend who, for the duration of this post, shall remain nameless. It was Founders at Work, a collection of interviews with the founders of tech startups.

If there’s one line of wisdom threaded through the book, it’s summed up at the end by Michael Dell when asked what the most important quality in an entrepreneur is. “Persistence” was his one word reply. (I prefer the phrase “fucking a terrier” as in “he’s a fucking terrier”).

It’s a quality that I hugely admire in my nameless friend. He has, more than anyone else I know, dedicated his life to the pursuit of a singular, ambition dream. He also displays great persistence as a system architect, as many tempoary advocates of a hack can testify, having suffered the contempt of his withering look.

However, the thing about persistence is it has to be contiguous. You can’t have gaps in the thread. So while he’s fucking a terrier at the micro problem level and obsessively persistent at the macro calling level, he’s still unfulfilled because he lacks persistence at the middle project level.

If he had persistence through and through, he’d be in the book, rather than borrowing it. Until then it’s a case of while True: return None.

The Birth of Networked Representation

2009-08-04T00:00:00-07:00

The Birth of Networked Representation

4th Aug 2009 – London, UK

Very occasionally, on an evening, cooking, talking to your wife in the kitchen, you have an idea that, when you walk around it, over it and under it, when you look at it from all 360 * 360 degrees, strikes you again and again with its potential to change the world.

A simple practical idea that resonates with the threads and memes you’re consuming. That’s interwoven with the trends of your time and solves the problems of your time.

This post is about one such idea.

In the kitchen, chopping mushrooms, after a hard day’s work and a thankfully slurped beer, discussing the UK citizenship test, explaining the difference between first-past-the-post and proportional representation. In the middle of explaining that there’s a chamber. A big room with seats and that those seats are sat on by the people who then get to make the law.

That under PR, if you get 15% of the vote, you get 15% of the seats. But that under the existing system, in the UK and the US, you can come second in every constituency with 40% of the vote and end up with no seats at all. And that’s kind of as it’s meant to be. Certainly how it’s evolved. Because those MPs represent their constituency and their constituency is therefore represented.

Then the flash of light. Because mid way through the words, “MPs represent the people from their location” the thought occurs. The major trend of the second half of the 20th century is the transition from a geographically grounded society to a networked one. That we’ve atomised and that society isn’t about place. It’s about tribes.

And the dawning. That’s why people are disenfranchised. That’s why they don’t vote. They’re not represented. Because the representation system is out of date.

So design the new system. What would it be? Networked representation. A chamber, full of seats, where each bum on each seat is the leader of a tribe. Where hip-hop sends their representative and so do the geeks and so do the bean counters and practitioners in advertising and so, were the room big enough, would the Ukrainian folk dancers and men in white hats.

Keep going. How do you pick the tribes? Well this is what we do nowadays isn’t it? Track memes. Monitor the web trends. Equally we self organise. Take the crudest way: pick the top 600 tags on wefollow. Offer people the chance to choose one of those tags and vote for the representative for that tag. Hell, skip that, just pick the most followed. The top of the list.

What chamber would we get? Well we know. We have those results now. Here it is. How does it compare as a government of all the talents? A room full of old goats?

And then you think. I’ve got to write this down. This is one hell of a blog post. Baby, do you mind if I write down an idea? And she does, because she wanted to go for a walk whilst it was still light. But you do it anyway because you’ve got the buzz. The catharsis that comes like a proustian rush when you stumble upon symbiotic gold.

So you fire up the macbook and you try not to lose your thread when you’re waiting for ever for it to start. And you hit TextMate as soon as it’s loaded and practice your opening lines while the thinking wheel spins. Then it’s there and you type and you try to follow the thread you followed, so you can communicate your little psychological journey.

But then you pause and—and this always happens to me—I catch myself in floats of fancy thinking about how this could be big. Dreaming about how to approach Seth Godin. What to write in the email that’ll never be read. Until realism bites and you think, OK that’s never going to happen but some people will read this and if only they’d share the idea it could happen.

If they just took the 15 seconds it would take to copy and paste and personally recommend the idea to their followers and if they in turn read it and they got to this point right at the end of the article and they thought yes, I’m going to make this a movement. This idea is too important. I’m going to share it.

Taxing Resources

2009-08-04T00:00:00-07:00

Taxing Resources

4th Aug 2009 – London, UK

The 30%+ Apple takes on every purchase in the app store is a significant disincentive to sell through their platform. Because it’s a new service, a new deal, it’s one that we’re all too aware off and scrutinise before grudgingly making our cocoa devil’s pact.

But it’s worth remembering that we operate within just such a system every day of our lives. Taxation is an equivalent disincentive and operates at a similar margin. Imagine what would happen if Apple announced they were no longer going to take their cut. All sorts of in-app micro-purchase revenue models would be unlocked and developers would flock to the iPhone in even larger numbers.

Now imagine what would happen if the UK announced it was suspending taxes on profit to become a 0% tax zone. But why waste my time with that thought, you might ask. Surely it’s a pipe dream. Who’s going to pay for the dustmen? Well there is another way to generate revenue for the state. You can tax resource consumption instead of taxing profits.

Let’s make it a dichotomy. Taxing profits and not resources provides a disincentive to create value (because you get penalised for it) and doesn’t provide any disincentive to using and abusing resources like, say, people’s lives and the environment. Whereas spin that on its head and tax resources and what do you get? You remove the disincentive to create value and create a disincentive to raping the planet. The young Turks eyeing the dragon’s den will be directly financially motivated to devise schemes that make the absolute most of the world’s resources.

As the system stands, the dog eat dog individualism of the market tends to short term-ism. To get from there to a world of constructive capitalism, we need to change the rules of the game and tax is our game changing weapon. Yes, with this approach, we lose the self-policing simplicity of taxing profits. But look around you. Utilities are metered and charged. Bin bags are counted. Carbon credits are traded.

We already measure consumption exhaustively. So let’s tax it.

Self-optimised Criticality

2009-07-19T00:00:00-07:00

Self-optimised Criticality

17th Jul 2009 – London, UK

I was talking to Mamading Ceesay recently about the Gallup World Poll, which tells us that what people really want is a good job. He pointed out that it was interesting people equate fulfilling work with a decent job: are there not other ways to be satisfied?

The next night, a Friday on the sofa nursing a cold, I watched this talk by Umair Haque. I had been reading his response to the comments on his Generation M Manifesto and spotted a link purporting to explain what “doing meaningful stuff that matters” means in detail.

Constructive capitalism

In his talk, Haque contrasts two types of capitalism. The first, bad, 20th century type, he equates with conflict. Companies focused so hard on winning that they forget to compete. The second type, the poster children of the 21st century, are companies that have stopped waging war on each other and, instead, focus their energies on innovating and creating new markets. Competing in the pure sense of trying to make better products, as opposed to competing by selling more mediocre ones.

I’m not an economist and there’s a lot of depth in Haque’s analysis. However, both his talk and my discussion with Mamading sparked the same thought about competition that I thought worth sharing. Haque wants to spark a discussion, pointing out that, of all the responses, “none offered any substantive criticism of the essential ideas in the Manifesto”. So, caveat emptor, here goes.

Self-optimised criticality

Self-optimised criticality is a concept introduced to me by Stuart Kauffman in his books At Home in the Universe and Investigations. For him, it’s the natural state of living systems and an aspect of a new way of understanding evolution. What it means is that species tend towards what he calls the “edge of chaos”. This is where they are as close to going pop as they can be whilst still hanging on in there.

He’s talking genetically. The edge of chaos is where species are as open as they can be to accommodate genetic change whilst still maintaining the genetic stability to reap the gains of an advantageous mutation. Kauffman suggests this trait, the tendency to self-optimise to the critical state on the edge of chaos, is ubiquitous. It is, he believes, a law.

Now, there’s an obvious parallel between organisms in an ecosystem and companies in a market. However, it’s important to be careful applying concepts by analogy. Yet regardless of the care with which the concept could be applied a priori, I see it every day as a clear empirical fact.

The edge of profitability

At Large Blue, we pitch for work against other agencies. We do our best to differentiate and value our services and build our reputation but if we price too high, we don’t win the work. The terms on which we do business are largely out of our hands. We know what we have to do to be competitive and that’s the level at which we pitch.

If this is, and I suggest it is, competition as practiced by the majority of (certainly b2b) companies, what’s the aggregate result? The invisible hand does its job of driving down prices and, as a consequence, we self-optimise to the edge of profitability: as close to bankruptcy as we can operate whilst still servicing the payroll each month.

External events

In the biological world, optimisation leads to vulnerability to external events. For example, species that evolve specialisms for a specific environment are vulnerable to that environment changing. This is equally true for companies. Optimised to the edge of bankruptcy, they’re vulnerable to a change in the financial environment, as clearly shown by the current financial crisis.

This crisis is one of the main themes of Haque’s manifesto. In the talk I watched, he blamed the bad, old type of capitalism for the complex credit derivatives and sub prime investments that caused the crisis. He also strongly defends the need for competition, explaining his critique of these bad old ways largely in terms of stifling competition. However, if competition tends to make companies self-optimise to the edge of chaos, how will a change of focus back to competing by creating meaningful, authentic value affect the likelihood of another crisis?

I can understand that companies that adopt a constructive mindset are likely to out compete their more jurassic competitors. However fast forward to a new orthodoxy, when all companies are focused on creating real value. What then? They’ll be just as vulnerable to external events as they are now.

Mitigating the effects

So, if companies will always be vulnerable to external events, how do we stop this ruining people’s lives? People who, Gallup tell us, just want to be used effectively and do satisfying work.

I know this is a question Mamading’s been considering and I wonder, are you?

Solving the Wrong Problems

2009-06-30T00:00:00-07:00

Solving the Wrong Problems

30 June 2009 – London, UK

It’s amazing how often I find myself solving the wrong problem. As you may see from my last post, over the last few days, I’ve been trying to wrestle trust metric calculations onto App Engine. However it turns out that for one reason after another that it just isn’t practical (the solution I outlined in the post, Tav points out, is trivially game-able).

So the penny drops and it’s back to the drawing board. All the time I’ve invested figuring out which model entities can go in which entity group and how we can maitnain db consistency and so on is simply a waste.

In the same conversation, both Tav and I were wrestling with the same conundrum on a more generic level. If we can’t calculate real metrics should we be creating the architecture to be able to do so? Or should we just work within the restrictions? What should we be trying to achieve?

Self starting productivity is a constant battle to stay in the narrative and solve the right problems. When do you pivot and when do you stay the course?

Some days I wish I knew.

Scalable Trust Metrics in the Google Appengine Data Store

2009-06-28T00:00:00-07:00

Scalable Trust Metrics in the Google Appengine Data Store

28th June 2009 – London, UK

This is a dump of my thoughts on how to use Google App Engine for the back end of Trustmap. I’m no expert on data and this may not make much sense if you’re not me.

From a data store perspective, a user’s immediate trustmap looks like:

class Trustmap(db.Model):
    user = db.KeyProperty()
    context = db.StringProperty()
    users = db.ListProperty(db.Key)

This allows a query that shows who user trusts in context:

>>> tm = Trustmap.all().filter('user =', user).filter('context =', context).get()
>>> tm.users
[... list of users...]

This allows people to tag other people, much like you can use delicious to tag URLs. However, as with delicious, this query simply returns the information put into the system. There’s no added value.

Our aim with @trustmap is to provide that added value by calculating trust metrics for each supplied context. The idea being that if I trust user for context then I also implicitly trust who user trusts for context, albeit less than I trust user himself.

Take the following network:

       G       H      
         \   /        
           A          
         /   \        
       B       C      
     /   \   /   \    
   D       E       F

A trusts B in a specific context and B trusts D and E. So according to the trust metric approach above, A can be said to implicitly trust D and E because A trusts B.

Now, our challenge is to store this information on Google Appengine, following the appengine paradigm of super fast reads. What are the issues?

Appengine Restrictions

Appengine is great because it’s real, live and functioning and provides a scalable data store that doesn’t slow down when it gets full of rows. It also provides memcache, a great little webapp framework and automated deployment.

However, it comes with a whole bunch of caveats and restrictions. Notably:

requests need to be completed within a specific time (atm 30 secs)
requests need to, on average, not consume anything like 30 seconds worth of CPU
max of 1MB data in any one db.put operation
transactions have to be within entity groups
limited background processing
limited remote API
pure python only

Also, when appengine apps scale towards relatively high usage, db operations error more frequently (or so I’m told here).

The Naive Approach

The naive approach is to simply iterate through trustmaps when querying. Silly pseudocode being:

zero_degrees = []
one_degree = []
two_degrees = []
...
zero_degrees = trustmap
for user in zero_degrees:
    one_degree += user.trustmap
for user in one_degree:
    two_degrees += user.trustmap
...
return zero_degrees + one_degree + two_degrees

This has the benefit of being simple and working with just the Trustmap model class from above. However, it’s very quickly preclusively expensive and slow to calculate. If a user has, on average 1000 people in their trustmap for a context and we calculate 2 degrees of separation, we get 1,000 * 1,000 * 1,000 = 1,000,000,000 calculations.

Keeping a Lid on the Calculations

There are two factors that influence the number of calculations: the number of people in a trustmap for a context and the degrees of separation. One way of keeping the numbers down (tx to David Pinto for the advice) is to prescribe a small maximum for the former, say max 5 people per context. This would make the max calcs for 2 degrees of separation to 5 * 5 * 5 = 125.

However, whilst an intriguing ‘creative constraint’ I have the feeling people might want to trust more people than that for important tags. Say you’re a casting manager keeping track of a lot of dancers, you might want to trust more than 5 people for #chorus. Or a marketeer might want to trust a long list for distribution. Conclusion: setting a max per context is a good limiter but needs to be unobtrusively higher than 5. Say 30 or 100 or 500.

The second weapon is limiting the degrees of separation. We want to add value but we need to avoid calculations. How would just one degree of separation work out? Say with a maximum of 99 users per context? That’s a maximum of 10,000 trustmaps affected by one change. Can we handle that?

Computed Trustmap

Let’s assume that, instead of building the results on query, we’re going to build them when data is written. One approach is to flag up which trustmaps need to be recalculated in response to an add (i.e.: when a user trusts) or remove (when a user untrusts) event.

Let’s imagine we have a new class::

class ComputedTrustmap(db.Model):
    user = db.KeyProperty()
    context = db.StringProperty()
    users = db.ListProperty(db.Key)

Imagine that the left hand side of the network diagramme above doesn’t exist and that we’re at the point when A decides to trust B for a specific context. What changes?

A’s trustmap
A’s computed trustmap
G & H’s computed trustmaps

A’s trustmap changes because A has added a user to it. A’s computed trustmap has changed because A now trusts B’s users for context and G and H’s change because they trust A and thus should have A’s trustmap in their computed trustmaps.

Calculate What?

Having worked out which trustmaps / computed trustmaps are affected, we have two routes. The first would be to recalculate the affected trustmaps, along the lines of the ‘naive’ logic above. However, this seems like overkill because, after all, the majority of those trustmaps is going to be just the same.

The second approach is to make the specific changes to the trustmaps required by the event. Let’s look at what those would be in this case:

we need to add B to A’s trustmap
we need to add B’s trustmap to A’s computed trustmap
we need to add B to G & H’s computed trustmaps

How would this work in practice? Say we have an initial request handler (or a synchronous function called by the request handler). The first operation, adding B to A’s trustmap is trivial. How about the second operation, adding B’s trustmap to A’s computer trustmap?

The complexity of the second operation comes from the need to sort a computed trustmap. The logic is as follows. If you query a users’ trustmap for a context, the first results should be the people that user trusts directly (from their direct trustmap), followed by the people that user trusts indirectly (from the computed trustmap). However the people from the computed trustmap should also be ordered so that someone trusted indirectly twice (i.e.: by two people in the direct trustmap) should come before someone trusted once, and so on.

Now, we’re going to sort the computed trustmap by key_name, as this allows for efficient batching. So one solution might be to have multiple ComputedTrustmap entities for a user and a context that have different priorities. That way, when adding (or removing) a user from the computed trustmap, the pseudocode logic would be:

>>> query = ComputedTrustmap.all().filter('user =', user).filter('context =', context)
>>> ctm = query.filter('users =', trusted_user).get()
>>> if ctm: # move trusted_user from this entity to the entity with the next highest priority
>>> else: # add trusted_user to the entity with the lowest priority

(The key [ahem] to efficient batched querying would then be to put the priority in the entity key, after the user and context ala:

keyname = u'%s/%s/%s' % (user, context, priority)

A query like:

ComputedTrustmap.all().filter('user =', user).filter('context =', context).order('__key__')

Would then return a list of matching entities, in order of priority, each with a list of indirectly trusted users.)

Now, the routine, set out in four lines of pseudocode above, for adding (or removing) a user from the computed trustmap adds a bit of faff but is still limited by the maximum number of people per context. In contrast, the issue with the third operation, adding B to G & H’s computed trustmaps, is that whilst we can limit the maximum number of people a user can trust for a context, we can’t limit the number of people who trust a user.

For example, how many users would trust Seth Godin for a relevant context? So when Seth occasionally makes a change, thousands or more people may require their computed trustmaps to be updated. This means that whilst the second operation could perhaps have been done within the scope of an initial request handler, the third operator has to have the capacity to be iterated through by a background process.

We’ll need to store a snapshot of the users who need to have B added to their computed trustmaps. So we get a class like:

class DirtyUsers(dm.model):
    users = db.ListProperty(db.Key)
    context = db.StringProperty()
    action = db.StringProperty() # 'add' | 'remove'
    user = db.KeyProperty()
    ...

We then iterate in a worker to:

action(user) to computed trustmap (following the logic outlined above)
updated / delete the DirtyUsers entity to keep track of the computed trustmaps remaining to update

Ok, so far so good, we’ve got a mechanism of making just the relevant changes in response to an event. However, this approach introduces a further problem: the possibility of the trustmaps getting out of sync.

Sync

The problem is that, because we only ever change what needs to be changed, if, for some reason, a change isn’t made, the trustmap and thus all future calculations based upon it will be erroneous.

Let’s look at the specifics. We have two sets of ‘puts’. The first:

add B to A’s trustmap
add B’s trustmap to A’s computed trustmap
store DirtyUsers entity for context, action and user

The second as outlined above:

action(user) to computed trustmap (following the logic outlined above)
updated / delete the DirtyUsers entity to keep track of the computed trustmaps remaining to update

Now we can, if we want, use a transaction for the first set. The DirtyUsers entity, and A’s Computed Trustmap can all have A’s Trustmap entity as parent and thus belong to the same entity group. However, whether we do that or not, we can’t update the DirtyUsers entity in the same transaction as the ComputedTrustmap entities in the worker iterations.

However, we do have a ‘get out of jail’ mechanism for these computations: if it goes wrong, re-calculate everything. If we store the original action (A trusts B for context) on the DirtyUsers entity we can then have an occasional background process that scans for very old unprocessed DirtyUsers and, if they seem suspicious, delete them and file all the affected trustmaps for re-calculation.

Thoughts?

The Missing Business Model for Content Producers

2009-06-22T00:00:00-07:00

The Missing Business Model for Content Producers

22nd Jun 2009 – London, UK

I went to a Social Media Forum today, where Justin Judd, the CEO of i-Rights spelled out that there are just three business models for online content:

1. “I Pay”: where content is given away for free (like, say, green.tv).

2. “You Pay”: where content is sold by subscription or transaction.

3. “Someone Else Pays”: where content is swathed in advertising.

But the truth of the matter is that there is another option, squeezed in between the second and the third way.

Six Questions to Ask When Evaluating a New Business Idea

2009-06-21T00:00:00-07:00

Six Questions to Ask When Evaluating a New Business Idea

21st June 2009 – London, UK

1. Is it innovative?

Is it novel? Does it create real value? Where does that value come from? #

2. Is it as simple as it can be?

Have you isolated the very core of the idea? Can you make it simpler to build? Simpler to use?

3. Is it backwards compatible?

Does it import existing data? Integrate with existing services? Leverage existing habits? #

4. Is it extensible?

Is it a platform? Can others build on it? Will it become woven into the fabric of the future? #

5. Is it defensible?

Have you left room for a competitor? Can you defend your space against a team that’s ten times as big?

6. Is it sustainable?

Will you still create value once you’ve scaled, moved on, retired?

Narrative & Time Management

2009-06-12T00:00:00-07:00

Narrative & Time Management

12 June 2009 – Oxford, UK

Effective time management is about setting priorities and meeting deadlines? It’s about organising your day and minimising the time you waste?

Wrong. These are tiny marginal factors that barely affect it.

When you look back on a life, or part of it, you convert it to a linear narrative. The same with history. We invented the wheel and writing and the printing press and then the Internet and …

However, when you live a life, it’s not linear. Neither is history. The world went from the printing press to the Internet via slavery and two world wars.

Effective time management is about staying in the narrative. It’s about making sure that you’re investing your time in the centre of the future story. Not into a footnote.

Tav Describes Pecus

2009-06-09T00:00:00-07:00

Tav Describes Pecus

9th June 2009 – London, UK

Following some recent discussions on the esp Google Group, Tav emailed in this clairification of Pecus. I thought I’d reproduce the email here as it relates to my previous post It’s about Actualisation and Plexnet Trustmap, and means there’s a permalink to the documentation.

Over to Tav…

In the long long ago (late 1999), Pecus came into being as an internal currency to manage resources/rewarding within ESP. It was an actually an acronym for “Plex Economic Currency Units” and was meant to be a 21st century reflection of the Latin pecu — the origin of the Latin word for money/wealth, pecunia.

This was tied into a trust-based organisational structure — which would soon after go onto become what is today referred to as “Trust Maps”. And, quite separate from all of this were our efforts in the field of gift economies.

We were creating a media client called “Espra” which intended to have an “aggregated micropayments” service. The idea being that you would listen/watch/read using Espra and every couple of weeks it’d go “Hey dude, it seems that you’ve been enjoying all this great shit — would you like to give something back?” and you’d give it say £30 and it’d split that up according to what you’ve been reading/watching/listening/etc.

Now, several iterations later, we get to 2007 — the 24weeks Iteration. By this time the concept of Pecus had gone through various iterations and the overall economic model had become a tad bit more complex: http://wiki.espians.com/Image:Toman_ecology.png

As a firm believer in the existence of “simplicity beyond complexity”, I wasn’t too happy with this. And one of the main things I did —during the second half of 2007 and early 2008 — was work on simplifying this model.

And, as a result we have the current redefinition of Pecus — Personal EConomic Units — which has nothing at all to do with currencies! Pecus are:

Personally branded. That is, we’d have @nslater pecus, @evangineer pecus, @saul pecus, etc.
Public (for reasons of transparency) units of accounting relative to an individual’s brand.

That’s it!! It’s so simple that a 16 year old could implement it in less than a day. Quite ironic, since that’s exactly what Tim Jenks (then 16) did back in 1999 — the very first bit of code that was written in Espian history — with the difference being that back then it wasn’t personally branded and was global instead.

So what’s so great about Pecus? The idea is simply that as people go through their lives, they give away their branded pecus to the individuals who’ve provided something that’s been beneficial to them.

This can be explicit. For example, some of you will find yourself in the tav-branded Pecu allocations I made earlier this year: http://tav.espians.com/pecu-allocations-by-tav.html

Or, it can be implicit. For example, you may want to give one of your Pecus every time you watch a YouTube video — perhaps you have it set to automatically give out 3 Pecus if you watch a YouTube right to the end! Same for anything you might read, watch, listen to, etc.

A pseudo-structure of a Pecu allocation might look something like:

Pecu {
  from, # who is doing the allocation?
  to,     # who is it being allocated to?
  for,    # what the allocation for?
  comment, # optional field providing a comment
  amount,    # the amount of pecus being given
  valid_until # can be set to 'lifetime' or a future date
}

In short, Pecus simply provide a public accounting of the people (and the things they’ve provided) that you’ve found beneficial in your life.

Together with Trust Maps — this can be pretty damn useful already! For example, one could look at all the YouTube videos that people in a given Trust Map of yours have given Pecus to. The possibilities are endless.

But the real brilliance of Pecus comes with the notion of Pecu Payouts. This is a bit like dividend payouts in a company: http://en.wikipedia.org/wiki/Dividend — a bit like having non-voting shares in a person!

Like Pecus, Pecu Payouts will also be completely public and transparent. The idea is that people can choose to do “payouts” across their Pecu allocations whenever they please.

For example, let’s say that I’ve made the following Pecu allocations:

James Arthur: 4,000 pecus
Sean B. Palmer: 4,000 pecus
Danny Bruder: 2,000 pecus

So, in total, I’ve allocated 10,000 tav-branded Pecus.

Now, if I decide to do a payout of say £800, this would be split according to the portion/share the individuals have been allocated, i.e.

James Arthur: £320
Sean B. Palmer: £320
Danny Bruder: £160

So, not only would I have publicly acknowledged the way I’ve benefited from those 3 individuals, but I’d have rewarded them with a payout too!

As to why people might be motivated to actually do payouts — I’m sure Jim Carrico will have lots of references in favour of Gift Economies — and the article by James that was referenced earlier makes a fairly decent argument: http://www.thruflo.com/2009/04/29/its-about-actualisation.html

The way that I tend to pitch it is that people care more about social status than money (lots of research out there to back this up). And those who’re “successful” and doing Pecu Payouts will find themselves invited to the cool parties whilst those that don’t won’t…

Myself, once the Plexnet is up and running, will be making Pecu Payouts of 50% of everything I make.

The beauty of the system is that it’s totally voluntary — that is, there is no enforced costs. And the fact that there are no micropayments gets around the obstacles like the mental transaction costs that Shirky is talking about. If anything, it’s aggregated micropayments.

I’ve also come up with ways in which we can do Pecus without having to be subject to regulation by the Financial Services Authority — but I’ll save that for a later post.

Now, let’s look at 3 simple scenarios:

1. Bruder has thousands upon thousands of fans who love his music — but besides concerts, he doesn’t get any reward for giving away his work for free on the internet. With Pecus and Pecu Payouts, it’s not inconceivable that he gets on average £0.50 from say 8,000 of his fans on average every month — enough to live comfortably. It won’t be the same fans every month — and there’ll be varying amounts every month. But the point is, he can focus on creating great work instead of doing shit deals with labels to just do what he loves! A form of micro patronage for the 21st century! It’s not inconceivable for any of us to find a few thousand people who are willing to support what we’re doing.

2. Gloria goes to Gambia and helps build a school for the kids in a village there. Usually this would be considered a philanthropic act. Besides the experience of doing it, she’d get no direct financial benefit from doing this. Now imagine a scenario with Pecus. Say those kids, thankful for having a decent school, give her 1000 Pecus each. Besides as a sign of kudos, those Pecus will initially be worthless — but how about in 15 years time? Those kids would’ve grown up — especially thanks to having had an education — and some of them would be in a position to do Pecu Payouts. Now, all of a sudden, Gloria is getting rewarded for her act!

3. A bunch of kids start playing a game every morning that as a side effect gets the local streets cleaned! In places like London this would normally be paid for by Council Taxes. Instead, the kids just get given Pecus by the locals — some of whom do Pecu Payouts. The kids get to have some fun, do something beneficial for the local community and the usual bureaucracies of local government gets completely bypassed!

In short, Pecus can totally transform the nature of our global economy. Turn it from one focused on extraction into one which benefits us all and enables everyone to be doing what they love!

But the real beauty is how Pecus — being so simple — compose really nicely with all of the other Plex ideas.

For example, combining Pecus with Trust Maps and Plex Democracy, we get Plex Challenges. This brings the beauty of capitalism — competition — into the Plex Economy in a healthy way. Plex Challenges are basically context-specific and time-limited competitions (e.g. 24weeks). Everyone can put forward Pecu allocations towards those that “best” fulfill certain Conditions, e.g. “A Logo for the Plexnet”.

With “best” being decided using the mechanisms of Plex Democracy — explained here: http://www.openideaproject.org/irclogs/browse/esp/2009/06/07#20-26-56

There’s only one winner — which is the stark reality of capitalism, even if we do our best to mask it — and the only stipulation of the Plex Challenges is that the produced work goes into the Public Domain (the Commons). The nice thing about this is that it limits competition to specific elements and thus promotes innovation whilst constantly improving the Commons.

The whole Plex Economic model is structured to create win-win-win scenarios as opposed to the current mode of win-lose. Anyways, I am starting to ramble — I hope I’ve explained Pecus enough… it’s
really quite simple…