The Economy App: from tech dev to community dev. Challenges and assumptions after the Mentoring Session at NESTA

[ilaria]

Back from London with [Matthias] and the other EU Social Innovation Prize winners and finalists. A 2 day full immersion in the pulsing heart of institutional Social Innovation at NESTA, an ongoing brainstorming tête-à-tête with Matthias and a double encounter with 2 mentors really worth the shot. Back to the ER platform to think things out and share with you thoughts on the next steps.

The Economy App has to go live, and the aim is to be “as big as email” in order to “change the face of the economy” (dixit Matthias). There is so much work behind this algorithm and this idea, we do not want to burn it or waste it during the reality check. It’s the Economy App that has to change the reality, and not the opposite. So what is needed to get as much as we can on our side and do this in an efficient way? What are the steps to build the community around the platform - from language issues, to time span, to the service-design, the communication, the alliances, ecc.

For those who want to follow the ongoing dicussion, here is the thread on the local commnuity development.

Geoff Mulgan’s speech was illuminating for a couple of questions he threw in:

• how do you design in scalability?
• different growth models: sclaing, spreading, growing, replicating, multiplying
• growth patterns and choices boil down to handling supply (push) and demand (pull) for innovation: in the case of the Economy App, I would say that the issue here is about matching the demand and the supply, so managing the supply would be a strategic priority.
• what is the impact of scaling on the cost strucutre?
• think about the organisational forms choices: once you scale, is it going to be about uncontrolled diffusion? directed diffusion (patent)? takeover or emulation?
• how far do you want to go on demonstrating your effectiveness before you scale through partnerships?
• what are you doing to be loved? why do people get attached to online communities (don't know if any of you have some proposals for a couple of good text references on emtional attachment and community engagement to online platforms)

* * * * * * * * * * *

The 2 days at NESTA dug out quite a few assumptions, and pointed out the challenges we will be facing.

1st mentoring session with Alice Casey (Nesta):

• confronted us to the urgent dimension of going live asap: if we manage to scale rapidly, the openness is ensured as nobody will want to pay for a service that they can have access to for free. Being rapid is required for social innovators: the risk of becoming obsolete is always close-by. Matthias shared with us a past experience which he had that went that way: we do not want to make The Economy App go through this again.
• asked us why we don't consider doing a partnership with already existing online barter communities which for the moment use the 1-to-1 exchange model. They already have a user-community, but do not scale; the Economy App can increase significantly the exchanges, infiltrating a user community it would have to build from scratch. Opens the issue of the development times of platform protocol.
• The need to do the social prototyping as a proof of the concept before going into partnerships didn't seem as mandatory as before, especially once we started thinking of the time issues. Also, the 2d mentoring session did make us understand how tough and long and complex social prototyping is (the guy has been developing his community for 7 years now!). I'll come back to this later.

2d mentoring session with Wingham Rowan (Sliver of Times):

• importance of 1st use cases: get the media coverage to the success stories (i.e. the wedding organized with network barter), manufacture the stories (100th transaction, 1st swap party)
• build in significance: you have to own the problem, the problem is more exciting than the solution
• where are the huge pools of need? Where could you go to get 1000 users (footballers, hospitals, schools, students, mother-baby clubs?): you need a multiplier
• start from 1 part of the community, build top-down: do not expect the community to grow organically, make it happen artificially (find the objects for the people)
• do not underestimate the service-design and the communication: logo? language? copywriting? get the logo on the city council website, mt2019 website; build on the EU Soc Inn Prize (winner!)
• develop a mobile application (responsive design)
• value of reporting: if data says EcoApp works for childcare, the next minute you're at the nurse school selling your service
• unlock the need: the first telephone problem
• focus on the regular users: who needs a flow of different stuff all the time and has some time to donate?

From here, where do we go?

The next post will give you some of the action lines we brainstormed on… stay tuned!

[alberto]

Abstraction => bad

Hmm. From what I hear, this is sound advice, but kind of vanilla – it could apply not just to Economy App but to a great many projects; and not just to [Matthias], but to a great many entrepreneur.

Bartering seems simple, but I suspect it might prove quite tricky to get right. David Graeber argued convincingly that the barter story we all hear (in a nutshell: barter was the primeval mean of exchange, then currency was invented to simplify the process) is simply false. This should ring an alarm bell: if our notion of bartering 101 is flawed, how can we be sure we are modeling it well enough to improve it via algorithm? And even if Matthias gets it right, how can EA work correctly if users hold flawed ideas about barter?

Here’s where I am going with this: my feeling is that it is time to focus on the product itself more than its business model. Mentors like to tell you about business models, because that kind of knowledge carries through more than technical or domain-specific knowledge; that’s all good and well, but it still leaves you with the need to prove your point. If I were Matt, I would feel the need for empirical data; watching barter happen “in the wild”, trying to figure out what drives it (the Ux? the right moment? the ethics of it?), tweaking the service to incorporate new data. Rinse, repeat. Am I getting it wrong?

[matthias]

And money is an abstraction.

Thanks for the reminder to keep the focus on the product! After much talking about community development and business models and other meta-level things, I appreciate that. At the end of the day, all the other things become only relevant once there’s a great product to offer …

Funny enough, “Abstraction => bad” has a second meaning for us, being a design principle in Economy App: we avoid money and any (resellable) debt because these are abstractions of value, and all such abstractions seem to open the door to gaming the system, including getting away with anti-social behavior. Or as Graeber puts it in his book: debt is a numerically expressed obligation. And only by being able to put an exact price tag on an obligation, it becomes possible to treat it purely objectively, ignoring the social relationship between debitor and creditor – for example by reselling the debt. (Graeber’s “Debt – The first 5000 years” book is superb for inspiring the design of our software. Will take me some time to get through I have started reading it after [AD_admin] gave me tips on this and several good accounting books and walked me to Foyles, the “best bookstore in London”.)

As for barter and its use in societies: we call the algorithm “network barter”, but that’s about it. The user experience has little to do with bartering (no negotiations, no “equivalence class” finding for objects etc. – waiting for matches seems to be the only common property). My co-developer even wants to avoid the word “barter” completely on the platform. The experience is designed to be more like a new payment system: “pay with your stuff and services”. If that holds true, it’s not really about “making barter work” but “designing a great trading mechanism”. More of a blank canvas than seems possible at first.

[ilaria]

Next step

Let’s put it this way: this is why the post-reflections on the NESTA experience were divided in 2 parts. This one is more about sharing insights from the NESTA guys with whoever is interested in social prototyping, general food for thought so whoever can hook on it and enrich it with personal experience.

Nevertheless, all this talk has had an impact on the ongoing brainstorming on the way to “watch barter happen in the wild”. Do you think we’re giving it too much thought and the Economy App should just be unleashed into the wild with no minimal design?

I’ve been doing a little research on social prototyping: I’m not a fan of models, but I guess it’s important (at least for me) to read a bit of stuff on other case studies, although I know that in the end each story is different and there is no already made recipe against complications - actually, this is what social prototyping is all about : the capacity to adapt to complications by integrating reality into its own service design.

So here’s a bit of further thought… considering the different paths that social prototyping can take, I have a gut feeling that a some proof of concept testing wouldn’t harm the Economy App before delivering the service de facto. I don’t know if this is what you meant by feeding on some “empirical data” but if this reality check is going to be done in Matera, then “asking members of the target audience to assess, rate and/or refine the product concept” means that target audience has to be addressed. Question is, which is the target audience? On this, I wouldn’t think about it too much and would preferably use social media to push the question out into the wild. Basically, ask bluntly “how could this work in Matera”?

There is already the portal for subscription to the beta testing of the Economy App. Today there are 35 subscriptions: this should happen before the “real-world test” (say, in October-November?) and be a first step towards creating the momentum for January? Does that work?

Finally, for the real-world test, I think that the Whole System Demonstration Pilot fits as what is trying to be tested here is the relationship between the barterers and how this network dimension builds into grouped exchange. Before getting there I would try to get some feedback from local community, starting from a post in the mt2019 community which explains the idea and expresses the desire to come and test it out in Matera, asking people: would this work? if so, how?

What do you think?

[james]

Get something small and simple into the wild as fast as you can

Alberto said “my feeling is that it is time to focus on the product itself more than its business model” and I completely agree! You need to work out what you’re selling in very, very concrete terms - not “a mechanism to facilitate exchange” rather “This app, from that store, which asks these questions and delivers those results.”

A whole bunch of business advice is based on a pre-Cambrian model - go to a bank to get finance, or go begging to VCs. Unless you’re planning on doing that, then drop a whole bunch of work about sales projections, distribution, R&D costs, development models and so on, and get something small and simple into the wild as fast as you can.

What will people pay for it? How will they pay? Will they REALLY pay? (Someone ALWAYS pays for activity. If it’s not the userbase, it’s a funder, or an interested third party. And if it’s not the user, a funder or an interested third party either, it’s you.)

My view is don’t “build in scalability” - instead, start scaling. You may need to shift gear, re-writing code, or reconceiving structures to step up to the next size category. the key is to get resource flowing. To do this, the App must work on a very small scale, with just 10-20 users. If it works at that scale, and delivers utility, then it will work at larger scales. If it won’t deliver utility at a small scale, and you need to start large, then you’re stuffed - forget it.

I’m interested in how an app, which facilitates distant exchange, can work with barter, which by its nature, works best in close physical proximity.

[alberto]

Ok, some agreement here

[James], are you @accessjames? I think you are, because the attitude is the same. Glad to see we agree on this one – though one must always remember that we have little skin in the game, and that our advice should be weighed accordingly. Essentially, [Ilaria], to answer your question: what I think is that we don’t understand barter the way we understand, say, auctions. Economists get auctions: we have a well developed theory. This made it possible, even conceptually simple (though implementation is never straightforward) to combine auctions and the Internet to get online auctions. Famous academics helped design eBay’s auction mechanism, as well as Google AdWords’s. But we don’t get barter. And the reason for that is that both currency and debt predate economics, and even philosophy. We have no written record of a society based mostly on barter. It’s not a return to the past; it’s an acceleration into the future. So you can’t build a model of it. At least, I can’t, and I can’t point you to anyone who can.

This should not stop you. We had no model for the sharing economy either; in fact, textbook economics teaches that any non-privately owned resource must be maintained by the state, or succumb to the tragedy of the commons. But it appears you can build things without having a model. When Torvalds, Jimmy Wales and the others created the great knowledge sharing projects of our time they did not start by deriving a model: they started by making something. Later, people like me (only smarter) tried to reverse engineer why the hell this stuff so working so well, and explain it analytically to themselves and to other economists.

[matthias]

How to design workability on small size?

“the key is to get resource flowing. To do this, the App must work on a very small scale, with just 10-20 users.”

Good advice! This is hard to make work with our mechanism, but we will try hard as well. With 10-20 resourceful users (say, hackerspace members) it will work no problem. With 10-20 consumerist users who do not have diverse offers each, it won’t work. The trick seems to be to have one “catalyst” entity who needs and offers a lot: one super-resourceful user can then trade with 10-20 normal users, also enabling their occasional trading amoing each other. The unMonastery would be such a super-resourceful user, I guess …

[james]

Barter, Debt etc.

Hi Alberto,

I, too, have read David Graeber - but I’m unsure that his absence of evidence for societies based on barter is indeed evidence of absence of such societies.

My current thinking is simple - barter can be clunky and transactional - just like money, but without its advantages. Even less formal means of value exchange exist - based on sharing and giving. This is UNACCOUNTED barter. Ouch! This is where economists really have a breakdown. People can’t just GIVE things - it’s irrational. And that doesn’t fit in with established theories.

Unaccounted barter (the gift economy) is based on relationships - not transactions. It’s almost completely friction free - requiring no visible accounting mechanisms whatever. However, does that mean that it’s highly vulnerable to gaming? In general, no - there are solid, informal and multi-channel mechanisms by which communities build up mutual trust and unlock the advantages of the gift economy. People who exploit the (lack of) system acquire poor reputation, which is hard to shake off without making visible and genuine contributions.

In Access Space we encourage the gift economy - and it has huge practical and psychological benefits. It acts as a kind of social insurance and builds networks of friendship and mutual support.

We find that some people (particularly people with mental health difficulties) can be tempted to “transactionalise” relationships to their own detriment. “Yes, I’ll make you a cup of tea if you help me to format this document”. WRONG! Be nice. Make the tea. Someone may, or may not help you. You have a good time, and you build relationships. People help you for the sake of helping you - not for payment. Your need to account for exchanges suggests lack of trust.

The trouble with the unaccounted, informal barter of the gift economy is that it’s most vulnerable to gaming by strangers, and by people with whom you’re unlikely to have ongoing contact with. The tax free, accounting free, capitalism free, gamining resistant, high speed, low friction gift econnomy does not easily scale.

Is barter a step towards the advantages of the gift economy? At this stage, I can only say “maybe”. It could be a brilliant hack - but it might also be that facilitation of barter, such that it transactionalises gifting, actually works to erode relationships and communities.

James

P.S. Yes I am @accessjames - tried to get that name on the Edgeryders platform, but something went wrong.

[matthias]

Accounting or not accounting …

James, thanks for sharing your insights on the gift economy! We don’t want to promote a bickering, penny-accounting mindset with our barter software, but indeed by including price tags we’re in danger to do so. We’ll have to think some more on designing for generosity …

As for the gift economy / unaccounted barter, I have a mixed experience. Here are some more challenges I found in practice:

1. Transaction volume. In unaccounted barter, people normally have a rough idea who owes whom what size a favor. Works nicely of transaction volume is small enough. But, for example, when bartering the equivalent of 300 hours of work, when not counting them and waiting half a year, there will be no clear idea of how big that effort has been. It may lead to a feeling of being disadvantaged in the deal on both sides. (On the plus side, I observe that such high investments can also lead to a rather strong bonding, including a more unconditional solidarity in difficult situations. If it's that what you mean by the relationship side of unaccounted barter: granted. It's a very valuable experience.)
2. Invisible work. Also an issue I experienced when providing IT work for friends, for free: they just don't see the long night hours you have to stare into the screen to rescue their data from a dead hard disk or whatever else. And because they don't see it, they can't value it accordingly.
3. The scarcity of trust. Unaccounted barter is to the detriment of people who get asked a lot for help and are too kind to turn down an initial application for help from anyone – only to discover that no mutual giving relationship results. After many "lost investments", even the nice guys learn to turn down applications of help from those who are too much a stranger still. Where the scarcity of money limits the turnover of trade in the formal economy, it is the scarcity of trust and relationships that limits trading in a gift economy. Basically, I can only gift-trade with a select few people whom I learned to trust over time, while I need to trade with many more than I even know ...
4. It works only locally. Given that a gift economy network takes several years to build (as observed here in rural Germany), relying on it binds a person quite tightly to staying at one place.

“but it might also be that facilitation of barter, such that it transactionalises gifting, actually works to erode relationships and communities.”

Yes. And the question for design is how to avoid that. In our experience, accounting does not necessarily erode relationships: in our startup, we use time tracking to account for efforts and distribute revenues, and it nicely serves to offload worrying about the money to the spreadsheet. We don’t have to discuss who gets what here, ever. In that sense, it improves relationships, as quarreling over shares can reportedly be a real danger for startup teams. Seems we were lucky to find the right mechanism then. And I want the Economy App mechanism to work similarly great for its own purpose …

[james]

Great Points - A Valuable Perspective

Hi Mattias,

Loads of great points! Transaction volume is tricky - and often so is invisible work. This is particularly the case with intellectual effort - whether it’s developing a program or writing a press release. After the product is created, others look at it and underestimate the intellectual effort that was applied. In many cases they think that the solution (subroutine, strapline, plan, whatever) is obvious - and often it is, after it’s been devised.

I suspect that this is the problem that many intensive but time-limited activities like hackathons address successfully. We won’t guarantee to solve your problem - we will devote 48 intensive hours to addressing it.

The “what are you going to do for me?” question is interesting. At Access Space we have some people who are, apparently, time-sinks. They constantly ask for help, and seem, sometimes, to give little in return. My view is to have faith, and to ration the tempo of giving to a level that’s sustainable and managable. “I can’t necessarily fix your computer, but I can spend 10 minutes pointing you in the right direction.”

This said, we’ve found that eventually, this help pays off. Sometimes it can be as simple as someone expressing the value of the support we’ve given in a public forum. Genuine gratitude may take years to manifest into returned value… But I find that eventually it almost always does. (Sorry, I am lapsing into philospohy here.)

Locality is an issue - but we’re finding that there’s a “virtual locality” in the global community of hackspaces and fablabs. Yesterday we had a guy walk in from a Bagdhad Hackspace - and he was completely relaxed about asking us for help and advice, chatting with us, and proposing all sorts of future interactions. This is cool, because all of these community spaces are really quite informationally close - even if we’re geographically distant.

Another issue to also address is valuation - sometimes people who have acquired a certain level of technical knowhow (I even include myself in this category) can underestimate the value of skills and approaches which are completely alien to them.

Creative and social insights can unlock ideas, insights, connections and relationships - both with individuals and with organisations. We never saw the expertise of one young man (with a low level of literacy, and a history of petty crime) until some troublesome teenagers came into Access Space. He wasn’t able to fix a computer, or program an app, or debug a spreadsheet - but he was able to communicate with a bunch of feral kids in the right way to recruit them as helpful participants, rather than criminal elements. Now, one of those kids he involved is a peer advocate, training to be a youth worker - and he’s a key advocate for Access Space - when previously he was just a problem. The ability to build that communication bridge was a key skill that none of the others of us had. It’s easy to underestimate the value of these things.

I guess another problem is you get what you’re given, which isn’t necessarily what you need. Unless you take the approach “Whatever you’re given is what you need”. This is deep philosophy. Enough already. And many apologies to the rest of Edgeryders for transforming this thread into a forum for my philosophical meanderings.

All the best,

James

[alberto]

Ok, I am featuring this

Apologies? Guys, this is great stuff. I am featuring this post and the related thread. Then I’ll be back to debate more.

[dante]

Build on existing experience & knowledge,Not Reinvent the Wheel?

In our networks , including in my own experience,

we are already several years ahead of the economy app,

in terms of its architecture thinking, in terms of networking people and developers who work on similar projects, in terms of studying barter networks and alternative currencies ( including from a legal point of view ) , etc

I suggest the economy app does not re-invent the wheel, and joins some of the existing FLOSS oriented communities of practice around the same sets of broad and overlapping visions.

For example, the economy app could benefit by using the existing backend, while create more specific front end applications of your own design.

////

I just wrote the following on fb, in response to M Bauwens person of the day :

some ungoing projects : the one that has imho the most developed backend ( though also the one I have been most involved with over the last years )http://netention.org - code :https://github.com/automenta/netentionjs2 ; 

Netention is developed mostly by Seth - is floss , and though it makes proof of concept through its current interface, the aim I see is to reduce thresholds by allowing graphic developers to create specific apps that can interface with the distributed network of netention backends , input / output data from/to its graphs.

examples of early prototypes : http://know.netention.org/ ;http://can.netention.org/ ( click on icon top left for more windows / options ) - 

Other softwares : there is also http://noosphere.com ;http://noomap.info/  ( I do not know much in detail about that project yet ) ; http://metamaps.cc ; 

and another one, which I find interesting and hope can be integrated into netention ( for example by importing the REA ontology http://c2.com/cgi/wiki?ResourceEventAgent , or creating specific apps using it )

see Bob’s : https://github.com/valnet/valuenetwork ,https://github.com/valnet/valuenetwork/wiki/Value-Streams ;

Also, some projects which are “planned” but still vapor’ at current , yet share the general philosophy , such ashttps://edgeryders.eu/economy-app …

///

Personally I look forward to develop a granular approach, facilitating the emergence of such Semantic Technologies that can also empower Business Intelligence 2.0 (http://en.wikipedia.org/wiki/Semantic_technology ;http://en.wikipedia.org/wiki/Business_Intelligence_2.0 )

It also enables the deconstruction of our political economies, and their tools, including the various architectures of what we currently call “Money” - understanding externalities and suggesting alternative economic networks and architectures

//

some earlier posts from that fb thread :

P2P Person of the Day, http://p2pfoundation.net/Joachim_Lohkamp

Dante : The Technology Evangelising around Jolocom sounds like a number of other projects out there  I hope they will all converge, using floss approaches. Some of them already have prototypes of back and front ends. IMHO, the more general paradigm being “Semantic Technologies” , with in some cases more specifically “Business Intelligence 2.0”.