Pricing an online service
This in one of a series of posts that are a sort of “marketing diary” of our (attempt at) launching two new online services. The posts are put into context here.
In this post I articulate the reasoning that led us to define a pricing policy for our new online services. In order not to repeat mistakes made by others, I tried to become familiar with experiences, mistakes and successes from many sources – I give a short selection of references at the end. During this search, I have come to the conclusion that there is a simple and single principle, the “nobody cares about features” one, that every developer/marketer that comes to pricing software should keep clear in mind: this is probably the single original point of this post.
We got to define a pricing policy having already three years of experience and alternate success in selling software online; but this was a downloadable product, not an online service, and things are different. One point I got while thinking and researching about pricing is that “no price is an island”: the price of your online service is one aspect of a more general “pricing policy” that includes demo conditions, free licenses, refunds, segmentation (eventually), and other aspects.
I had got to some principles:
Transparency. Your prices and entire pricing policy should be public, clear and completely defined from the very beginning, from the very first moment your beta goes public. This because you must not keep any of your users and potential customers in a state of uncertainty. This way you may reduced the time it will take to make the first sales, which is a critical factor for your success.
Simplicity. Your price must be simple. Nobody wants to make complex reasonings when trying to understand costs. We’ll get back to this after stating the “nobody cares about features” principle, because its related to that.
Give refunds. Your worst enemy in sales is user’s fear, and anything that can lower that, should be welcome. A clear refund policy reassures evaluators, and do you want to keep unhappy users around? It’s not a good idea for an open, blogged about service.
Have only paid accounts. And then a choice we made is to have only paid accounts; a free online service, say ad-based, is a very complex undertaking, whose difficulty and implications for the users are easily underestimated. The mass audience that you must reach to make such choice profitable is rarely found. Another option that rarely works is the donation model. No, we want to give a refined, quality service, for real money.
Fixed these principles, we are still in the dark about how much we should price an account, say per month. You may start looking for a formula, well, there are two values that can be sort of determined:
Costs: you can determine how much development and maintenance costs, and what is the marginal cost, that is, the cost of activating and maintaning a new account.
Real worth: you can probably determine how much worth your service will be for your average customer, how many days of work and confusion it will save them, etc.
Well, now comes a fundamental realization: these two values are entirely, completely irrelevant for determining your service price; because you are looking at things from the wrong direction and/or with the wrong user model in mind. Consider the theme of my previous post about finding a pitch for your product (Get visitors to read and remember your home page):
The day you realize that nobody is interested in reading your product or service homepage because you love it, may be a bit depressing, but may also be the start of a re-design that will lead to more returning visitors.
Well, something similar holds for your pricing: in a competitive market, you simply can’t base yourself on what you believe your service is worth, or how much is costs, or the features you know it has, because nobody, absolutely nobody cares about that. Sad, but true. You have to set the price for the most direct and simple advantage the user can evidently and quickly see she /he will get.
You should never overestimate the will of an evaluator to carefully review your application: so you should surely put no limitation whatsoever in the service you are providing in the demo or free phase of the service; but then, this also influences your pricing, because if you are attempting what is called “segmentation”, based on limiting the features offered by different levels of pricing, you are sort of preparing a “nasty surprise” for those that want to turn from the full, complete demo to paying accounts: so I think this is a very bad idea. Developers love their products and their features, and (wrongly) assume that visitors to the presentation web site have the same drive; no, visitors drive has to be conquered, with the full power of your service, and also through simple and convenient pricing policies.
If you look at the typical policies of expanding software houses, these are often based on a flat, aggressive pricing policy; look today at how much more appeal has Apple’ OS simple pricing policy compared to the academic segmented prices of Microsoft’s OSs (and when Microsoft wanted to become a leader, it had the same policy as that of today’s Apple).
So the policy I support is to let the evaluators use the service in full, and give a single, simple price if they want to turn to a pay account. This is not what the marketing litterature suggests, but… things change, markets evolve, become more competitive, and also certain costs, like bandwidth, decrease.
Anyway, you may have noticed that we are still in the dark for fixing the price, as simple as it may be! Well, at least we’ve set the background principles, we can now look at similar successful software and services in similar fields; I’m not saying same fields as your service is a new, revolutionary idea, right? This also means that you won’t find many references to compare. At least you can be happy that with online services, all the piracy problems are over.
Another way to get an idea on price is to ask for opinions to your followers, or on The Business of Software, answers.onstartups.com, or Startuptodo. But only those who have a complete and clear picture of the entire pricing policy can take a decision; and I hope that will include you, in the end 
For our two new services, we actually fixed the price through a session where the entire software house took part, and voted. So we fixed a price (39$/month) for both our services, with only a limitation for really huge customers.
We’ll see whether it works…
References
Don’t just roll the dice – A usefully short guide to software pricing – by Neil Davidson
Camels and Rubber Duckies – by Joel Spolsky
The Web Startup Success Guide – by Bob Walsh
Subscription based models, how to determine pricing ?
Our new web services: Patapage “More options for your website users” – BugsVoice “Turn bugs into opportunities”
Productivity by delegation vs. productivity by outsourcing
Teamwork's Q&A's new site
In Open Lab we just adopted a StackExchange instance as support for Q&A’s for our Teamwork product (here), and another one for generic jQuery support (here). Now, the speed with which you put up one of the highest quality services available on the web is such that it ridicules any attempt to build such a service in-house – a mistake that we actually pursued. This has led me to the following thoughts.
Many developers and managers live in a omnipotence dream. The apparent power of a Turing-complete tool, that in principle can perform any kind of computation, feeds the illusion that having developers in-house means that any software task can be solved by simply developing the application from scratch. If this seems obviously false to you, just take a look around and you’ll find more examples that you’d ever imagine.
So, we need a support forum for our product? Let’s just develop one. We need a bug tracking system? Let’s just develop one. We need to build a web site with database? Lets develop it internally.
Taking the opposite attitude, that is, developing from scratch only what is strictly related to your core business, can be a way to becoming more productive. I’ll call this the software delegation principle.
Ok, assuming this principle looks easy enough; but… there are several mistakes that can be taken in sweeping generalizations of the principle above. The worst one is confusing delegation of secondary services with outsourcing the core productivity of your company. There is a semantic difference between “delegating” and “outsourcing”, and it is connected to where you put your company’s worth.
If you put it in designers, developers and their skills, you can delegate everything but their activity, you will have to struggle to keep their focus on our main development, without making them develop say a support forum when it has nothing to do with their core issues.
If you are a software house, renting a coder is probably a bad idea – see Jeff Atwood’s Can You Really Rent a Coder? . For similar reasons, though many developers and bloggers don’t get it, it is just as well a bad idea to rent a designer. Your people’s skills are the core of your value. Like, our core competencies are development, design and marketing our web applications. Anything that distracts us from our goal, should be removed if possible.
Another in some sense opposite mistake is delegating problem solving which touches your core competencies: like using tools that give you simplistic solutions that hide you the real complexities involved and that will lead you to great troubles when going in production. A classical example is like trying to set up a web site using visual tools, without understanding HTML, JavaScript, and eventually the server-side part that goes with that: maintenance, cross browser compatibility etc. will soon become a nightmare. But delegating non core issues will actually help you going in-depth about your core issues. This is the mistake of outsourcing the core productivity of your company.
If you are a traditional custom-development based software house, what I am saying here applies in a different interpretation, simply because the value of the company is in the customers, not in production (in the case of a software house, this means the developers). Quality is concentrated in making deals with the managers, not in providing good solutions. That is why often such companies really outsource everything but marketing.(I personally don’t like much such business model, but that is another matter).
Made the necessary distinctions, if you overcome the temptation to build everything in-house, here are some examples of services that you can delegate if you are developing online services:
Development:
- writing code -> get the best IDEs, working stations, monitors, keyboards, that money can buy (see CodingHorror for many advices)
- integrating third-party technologies in your software: -> rely on available APIs
- designing mock ups ->use Balsamiq Mockups
Testing and support:
- testing your application – use http://www.usertesting.com or similar services
- collect feedback from your users – use an online service like UserVoice or GetSatisfaction
- support questions and FAQ – use StackExchange
Marketing:
- statistics of your site – use Google’s analytics
- following marketing progress – use StartupTodo
These are just some examples that I am using or exploring.
Using the best tools for development, like using the best IDEs (see The Joel Test: 12 Steps to Better Code), goes in the same direction: you delegate syntactic work to your development environment, and you focus on solving the business model problems and, most importantly, on usability.
Productivity by delegation can also be a great source of new products and services ideas; we in Open Lab are just now developing two new products exactly for this end, one for delegating collection errors and user feedback online (BugsVoice), the other for making your web sites dynamic without using a CMS (Patapage). Time will show whether I’m right…
Get visitors to read and remember your home page – applications
This is the second part of the “Get visitors to read and remember your home page” theme, the first is here. These marketing posts are put into context here.
Now that we have the design principles perfectly clear in mind, let’s apply them to Open Lab’s two new online service home pages, Patapage and BugsVoice (public betas will soon be available).
Patapage
So the first version of the Patapage web site home, after brainstorming, was this one:
Now what is basically missing is any reason for the visitor to get interested in the service: the pitch is not good because it refers to itself, it does not talk to the user. So the version got after reading “Made to Stick” is this one:
The pitch is six words, and talks directly of benefits, not just of features. Furthermore, a mysterious link to a short story has been added: the story begins like this
To read the rest, you’ll need to access Patapage’s beta 
Actually, the page we have now is even nicer:
So lets fill the scorecard for the obtained home page:
Not bad.
BugsVoice
So this was the page we first got to after brainstorming:
The pitch is invisible and badly worded.
After revision:
The pitch here is just 4 words! So lets fill the scorecard for the obtained home page:
Now… its your turn.
P.S. We finally changed “turn bugs in opportunities” to “turn bugs into opportunities”, after discussions and enquiries: though it doesn’t sound as nice, it is semantically correct.
Get visitors to read and remember your home page – the principles
This blog post is in two parts, this is the first, the second is here. These marketing posts are put into context here. The process here described has also become a step-by-step project on startuptodo.com.
The day you realize that nobody is interested in reading your product or service homepage because you love it, may be a bit depressing, but may also be the start of a re-design that will lead to more returning visitors. Nobody is going to link, talk, or blog about your product without a good reason to do so. There must be something surprisingly interesting, beautiful, disruptive, horrible, rarely thought of about your home page contents to get people to look at it.
Here I will consider some redesign principles that you may use once you got this “satori”.
So, you understood that your web site needs to convince people: you need a home page that will capture visitor’s attention. Taking the user’s perspective is non trivial, say Dan & Chip Heath, because you are under the “Curse of Knowledge”: it is very hard for you and your team to look at your product from the perspective of someone who knows nothing about it, if you don’t dedicate some time to this. This project is heavily inspired by the principles which can be found in the book Made to Stick by Dan & Chip Heath. The aims of this blog post can be summarized as:
(1) get visitors to read your home page
(2) get visitors to remember your home page
Home page effectiveness analysis
As an example, consider this analysis done on the startuptodo.com home page:
The crucial part of the home page is the pitch or lead, in this case “be successful faster”.
The transparent 1,2,3 are a likely order of attention of the first time visitor: she will first read the lead, then the text below, then eventually go more in detail. In a following step we’ll get back to this structure.
Now focus on another part of the home page:
If you can talk about your product / service features using a story, instead of a set of features, you will be much more effective: people tend to remember stories.
Let’s finally focus on a third part of the page, where the site is asserting its credibility:
By Sinatra effect it is meant that a single great testimonial can raise your credibility considerably (“If I can make it there I’ll make it anywhere…”). This example can be summarized using a scorecard:
The pitch and page scan flow
There is a sort of “page scan order” assumed in designing such pages:
The 1,2,3 numbers in the first screenshot of the site above are a sort of reading order, which you should follow in writing contents. The web site gives different levels of information to the visitor, trying to lead her to the evaluation part.
A perfect sample application of “the pitch” principle and of the page scan order is on the UserVoice site:
Notice that the pitch “Your customers have great ideas. Are you ready to listen?” talks about advantages for the users, not directly about features of the service. Below one gets more information, in two further levels. The pitch is even inserted in the service name!
Now go and (re)design your home page
Some steps that you may follow in designing your own home pages.
Describe your product / service
Describe your product / service and its advantages, the problems it solves, the pain it takes away, in short sentences, using a simple language.
It is often done in a group “brainstorming” session.
Find the pitch
This step will be crucial for making visitors actually read your home page, together with the following step “Break a pattern”. This is the hardest part, probably best done in isolation by the most “creative” writer of the group. You have to find the pitch searching in the second and third level descriptions found in the first step. It has to be a short sentence that presents the product advantages to its users. What it is often used as pitch is a sentence which summarizes the descriptive sentences found in the previous step. Mistake! What you should find as pitch is what the user will gain from your system, not a resume of what the system does. It is a subtle but essential difference.
Write a story about some humans using it
Find a storyboard for a video, or write a short story, with characters, people, talking about your product / service. This is the step which will solve point (2), making visitors remember your home page.
Break a pattern!
Something in your home page must break a pattern. Never do the mistake of cloning a successful site layout and that’s it. People just don’t look at known stuff. Either the graphic layout, the text, add a joke, something must be unexpected. The unexpected should be in a context very friendly and predictable: don’t take this as a hint to start surprising the user in general with developers tricks on the interface. Just “going wild” is a commonplace too, and won’t work.
Consider also this case: a bored PR man is taking a look to a set of sites, all with their plain obvious marketing hypes and strong words. Then it comes to your site and… finds something different, interesting…
Design page and publish it
Once designed and published, ask for reviews, test page speed and wide compatibility with the various tools which can be found online. The home page speed in loading and browser type and screen resolution compatibility is important. Put a beta of your page online, with Google analytics on it, and analyze how many people in % get to your “enroll” or “download”. Try variations. Buy a test at http://www.usertesting.com or similar services. Remember to get someone to read this blog and then evaluate the scorecard against your draft. Good luck!
End of part 1 – what is in part 2
In order not to make this blog post uncomfortably long, the following part, concerning how we in Open Lab applied the principles above, is published here, in a second blog post.
A note on how to give titles blog posts: the first title of this post was “Writing an effective product homepage”; but for the very reasons explained in this same blog post, this wasn’t a good title. A candidate title was “Turn homepages from feature reports to ’short novels’ “, but that is a bit cryptic, so the one I choose is the one above, “Get visitors to read and remember your home page”, which talks directly about what you gain from this post, instead of indirect advantages through features.
A review of “The Web Startup Success Guide”
This is a review of the book The Web Startup Success Guide by Bob Walsh, who is also the author of Micro-ISV: From Vision to Reality, published previously. Mr. Walsh is also the creator of the The Startup Success Podcast, and a moderator of the notorious The Business of Software (BOS) discussion forum. This book is aimed at developers who intend to create a new product and are ready to do all that is needed for getting to sell the product, so not only development, but also marketing, selling and collecting feedback.
I am writing a review of this book because I believe it fills a need which has been there for a while; I fantasized writing something similar myself, but luckily Mr. Walsh has come out with this, which spares me of the effort, which was unlikely to succeed anyway as writing something of this kind requires a total commitment. Before this book, to collect something similar to the information reported in it, you had to painfully go through the discussions in the BOS discussion forum, find links to other blogs and books from there, parse what was outdated, what is wrong and so on (this is particularly painful also because for unfathomable reasons those discussing the business of software are not provided with the quality of service that developers get with Stackoverflow and all that family – though it is from more or less the same source, and of course we should be grateful anyway for the service as it is all free). But the book is not a mere anthology of old and new information, it gives you a structured path to follow (a guide), divided in 10 chapters. The advice and references is further supplemented by interviews with about 50 guys from startups who have already gone through (sometimes several times) what the reader is about to start; the interviews are a great way to get informally in contact with what happens once you are “out there”.
Roman mask at Teutoburg.
This book is not “invaluable”, but actually concretely valuable for startups, as it can save hours of search and months of wrong paths taken; you will avoid several common blunders right from the start. Something I believe is a key to success is to choose a product idea with which you will find yourself in what may be called a good strategic position – GSP – my company is developing two new online services ideas which we evaluated along these criteria. When you are in the idea selection process (frequently referred to with the not-so-beautiful term “brainstorming”) considerations such as those of chapter 3 (“So many platforms, so many options”) will give you first criteria for selection, which won’t be sufficient, but are a good starting point: on top of that, what real user need your application solves will be crucial. Starting in a GSP will not make success certain, but at least possible. It is particularly important to start by asking you such questions before being fascinated by development in itself, which is a mistake to which we developers are prone. If you start in a bad strategic position, no amount of effort and quality of product is going to take you out of there – you’ll be the Romans in the Teutoburg forest. Solving marketing problems by sheer effort is a bad habit that many developers acquire in custom development, where they are rented by the hour – more hours, more pay. That does not apply neither in product marketing nor in product development. Unfortunately I still see product proposals on BOS which are in a really bad strategic position, like a client app for URL collecting (!), the painful proposal of a “new” Twitter client, and similar ideas; read this book!
I would like also to point out that much of the advice from the book is good also for the evolution of an existing software house, and for the launch of every single new product, not just for startups. My own software is just an example of the latter. But much is implied about how the software house should be organized for the production and launch to work if you want to follow the book’s implicit philosophy, and its assumption about company “transparency”; you can get further information starting from reading the long early articles of http://www.joelonsoftware.com.
Reviewing a book that gives advices on how to operate in a productive activity could hardly be done without experience in the field; and my review of this book is positive also because many of the findings to which we unfortunately got by trial-and-error are here reported as advices. And proceeding by trial-and-error in such time-consuming activities as software development often is not a viable solution.
Criticisms
The title part “success guide” seems to suggest that closely following the book, success is inevitable, which is false, and actually this is clearly explained in the book; I know that authors sometimes do not have the last word in picking a book’s title, and that marketing considerations get in the way, anyway I would have preferred a more cautious title. Better though unlikely would have been a simple English translation of “Some sparse ideas for web startups valid in 2009-2010″. But as said before, the startup scope too is too restrictive, so a revised title would be “Some sparse ideas for product-launching software houses valid in 2009-2010″. Ok, its horrible
In this (positive) review the title is further criticized again for being too restrictive, for the “web” word. Ok, maybe, anyway enough bantering on the title.
The part concerning Venture Capitals (VCs) and “angel” founding (chapter 5) is almost useless for European startuppers, as money lending is handed mainly by banks and European Union (EU) programs, and not by private founders; also American VCs are interested only in European software houses that already sell at least one million dollar/year (I know that for direct experience, as when my software house won a Jolt award we started to receive calls from American VCs), and so may be out of the scope of the readers of this book. So my personal advice to Europeans startups is for example to check your local universities engineering departments for joint applications to EU founding, instead of running after American VCs.
The worst sin I can find in the book is reprinting the word “dollarize”, which may be the ugliest expression ever selected in the (countably) infinite spectrum of possible English words.
Counter-criticism
I’ve read in other reviews that a weak point of the book is the lack of a “chapter about marketing”; this makes me wonder whether the other reviewers have read the book cover to cover, because one of the main points of the book (and one I found most interesting) is that traditional marketing is getting replaced by activity on social media: chapter 6, page 211: “social media replaces traditional advertising”. And the most interesting chapter 6 details the point further, just read it (I read it twice to be sure I got the points). Of course one may disagree, believe that it is a wrong idea, but an idea of marketing is indeed in the book, and quite articulate.
Mr. Walsh implicitly takes the position that effective marketing of software product and services is one that should appeal to a conscious, reflecting and informed user, quite differently from the unreflected stimuli on which traditional marketing relies. This thesis can hardly be held in general, in particular if one is considering business-to-consumer low cost products; but for other categories, direct and selective access to information from users has increased in time. I know that even one of the comparatively slowly evolving industry, the automotive one, is paying a lot of attention to what bloggers and other social agitators say about new car models released, so maybe its time that you too pay attention to them.
Then chapter 7 gives detailed criteria for the composition of a unique selling proposition (USP), which I believe can be useful even at the very beginning of your start-up. Try this: when you are “brainstorming” on a candidate product idea, try putting together a USP for it. Is this feasible? If not, this may show you that what you are considering maybe is not such a good idea: probably you are not solving some really felt need of the users.
Getting Things Done
Chapter 7 is about personal productivity: personally I’m a bit allergic to this topic, as it evokes images of “self-punishing solipsistic puritan bigotism”; but actually in the book it is not at all treated in this perspective. If one bears in mind that spending too much time and concentration on priority lists and things of the sort can actually damage your meeting the main problems of your startup, the advice given in this book can reduce time wasted. If you simply get to concentrate your “social marketing” activity in definite periods in the day, instead of getting and searching continuous distractions, you’ll surely get more and better work done (I’m actually doing that for my “social” online activity). Still in my experience the key for getting things done is not as much lowering distractions, but is not working alone: write your code in pairs, discuss your specifics in general meetings, select your USP and brand images by showing them to as many people as possible, test your application with as many people you can (also with low cost testing like http://www.usertesting.com), and so on. Anyone’s energy levels change in time: the day you are feeling tired by coding, you can be a good pair partner; and you’ll probably need more energy than you can imagine you have to get your startup to succeed. Not to speak of the countable but non computable number of advantages that a mixed-gender and mixed-skill pair and group of developers / designers has by default. You can’t do it alone!
Other reviews
http://bzkicks.posterous.com/the-web-startup-success-guide-review-0
http://blog.businessofsoftware.org/2009/08/the-web-startup-success-guide—a-book-review.html
http://www.amazon.com/Web-Startup-Success-Guide/dp/1430219858
Final considerations
Putting together what written above, I strongly suggest any startup and company that wants to launch new software products and services to get this book and then read it twice We are applying many of the ideas from the book for both an established product (Teamwork) and for developing and launching our two new online services. I’ll post here updates on our progress.
An “office exchange” opportunity in Florence – Italy
Open Lab's office
Many people use “home exchange” services, such as HomeExchange or HomeForExchange, in order to travel abroad comfortably and somehow “introduced” in the local community. Many of Open Lab have decided to generalize this to an “office exchange” initiative: we are willing to coordinate a temporary exchange of several apartments and part of a working place in Florence, Italy, with a modality similar to that of home exchanges. You will get houses with WI-FI, cars, bicycles, computers, usually also filled with books, some in Florence center town, others in the suburbs.
Our software house is presented here:
Three of the available houses:
http://pupunzi.wordpress.com/where-i-live/
http://homeexchange.com/show.php?id=111560
In total currently there are 8 apartments available of various sizes.
For the office part, here are some pictures:
http://jblooming.blogspot.com/search/label/office%20space%20pictures
We would extend insurance to cover your stay there, and we expect the same from your company.
The period would be in 2010, when is to be determined (not the first half of June), and the length – we were thinking from one to two months. For the location we are open to offers, would prefer to exchange in an English speaking country, but it is not necessary.
We will supply all the details to candidates – just write to ppolsinelli at gmail dot com.
Zeppelins (English version)
This is a short story for which I got the idea seeing the Loris Cecchini work which is in the picture below. For me it is clear that the opera is a sort of challenge for the observer; my answer follows. This short story was first published in Italian here, thanks to Alex Gillan for the translation.
Work by Loris Cecchini - Monologue Patterns (illegal), 2003 Giulio di Gropello Collection. Picture by Carlo Fei, Firenze
The stretch of road was a bridge amongst the rocks that tumbled down to the sea. On the crown of the road, the Citroën DS pointing the wrong way, and an open trapdoor in the tarmac.
The commissioner had arrived alone. He brought the motorbike to a standstill before the bridge, and concealed it amongst the rocks. Keeping his gloves on, circled the vehicle, inside the DS there were no keys. The car was in the middle of the road, he pushed it to one side of the bridge in neutral, sweating. Night-time, the sea could be heard panting.
The report had reached him that morning from the services, “from the honourable correspondent”, anonymous. By now he was a police commissioner, but was still registered as a passive agent. First a parachutist, Algeria, now the police. Never overly convinced, a mediocre professional. Only secondary information or suspicions passed through his hands.
He had to enter, and close the trapdoor; he thrust the torch inside, armed with a pistol. An iron ladder descends, down a few rungs, close the trapdoor behind you, go down as far as a platform, open, with a low parapet. It was the upper part of an inhabitable structure hanging below the bridge.
He looked at the sea; then leaned over the parapet to see underneath, the walls of the three cylindrical rooms hanging there seemed to be of glass, a feeble glow coming from inside. He drew closer to the entrance below, a perfume, new. Need to go down. Yet more metallic stairs, panting at every step, inside the first zeppelin. A table, with labelled glass containers, some small bottles, pipette stands, the rest of the space occupied by glistening green plants in a transparent vase. Nobody.
He could see through semi-opacity the contents of the second and third habitable cylinders, these two also occupied by plants. Proceed inside the second room.
Here, a body on the ground. He noticed it all of a sudden, from the hair sticking out from behind a plant, it was the last thing he’d expected; he hunkered down, it would have been easy to hit him from outside; gripped the pistol. Rose to his feet, they could already have shot him as many times as they wanted; by now, he was back to being an amateur. This wasn’t some silly affair, it had come to his notice by an error of judgement, some mistake…
Moved round the body, which was a copse: they’d shot him, little blood around. He’d been turned onto his back, pockets already emptied by others; one arm between two vases. Paused: he was there for the services, not as a policeman; so whatever had happened was unimportant, nor did it matter exactly who had killed him. What was important was to discover what they were looking for.
To and fro amongst the plants, without the foggiest; outside only the wind. The signal from the honourable correspondent didn’t indicate what to look for.
Where was the treasure? There had to be a treasure. Josef’s service didn’t kill in France, they must have missed something, and had wound up the game using extreme measures. A game played so badly, just had to have a treasure.
What was the bottom line. He passed amongst the plants; the soil perhaps? The plant pots, in thin plastic, transparent. As soft as rubber. That maybe? Goodness knows.
On one of the equipment-strewn tables was a magazine, an Humanité from some months earlier. The rule was to always leave the surroundings as if he’d never been there; he opened the magazine out on the floor, took the base of the first plant, laid it in the centre, extracted it gently from the pot. Crumbled the earth, isolating the roots. In this one, nothing; he was going to have to pull them all out.
Manoeuvring the plant to put it back in the pot, the leaves; it was a plant with roots, a stalk, normal, alive, he didn’t know its name. Yet the leaves had a peculiar consistency. Shiny and thick like those of a cheese plant, but the texture pliable; he tried denting the surface with his nails, couldn’t, it wouldn’t tear. He tried tearing the side of the leaf, managed; now the perfume which already filled the cylinder could be smelt more intensely from the leaf. Intense. A little giddy, the plants and the corpse, wheezing.
He looked for a way out leading to the sea, underneath, he didn’t want to come out onto the road again, to avoid reopening the trapdoor. The third room had a lower opening, without any stairs apparent, giving onto some metres of emptiness down to the rocks underneath. He unblocked it, there was a rope ladder tied below, loosened it, climbed down to the rocks. Tripped over a gas mask. Left it there. Walked to the sea, sitting down on a rock bordering the restless waters. A sudden sleepiness, not even the chilly sea air rousing him, the circumference of his head felt soft, ready for rest. Lay down on his side, to sleep.
Dream: struggling, slithering, he had gone back into one of the zeppelins, which was however made entirely from a rubbery/plastic material, white, like latex. The plants had been absorbed by the walls, swathed in the latex, the tips of the leaves were jutting out, then nothing. His body too began to be absorbed by the walls, he began to sink; by degrees his feet became immersed, his legs, torso, only the head remained; there he began to flounder, he couldn’t breathe. Stretching himself, he managed to return to the surface, but even so, more slowly, he was sinking… .
By sheer dint of will he woke up, whimpering, shaken by the nightmare. He rose to a sitting position, tailor-fashion, slowing his gasping. He turned, the glow from the zeppelins was still there. He felt cold, difficulty standing up. Not normal; he crouched, the plants. The plants, it had to be those plants, the consistency, the perfume. The gas mask. Must have been dazed before. He returned beneath the trapdoor, a deep breath, more than once. He climbed back up, entered the third room.
He looked at them, touched them, hurriedly: the plants were living, living with an intermediate life, between vegetal and plastic. That was the treasure, the others hadn’t understood. A different skin; the human one is so inefficient, so much so that the clothing that covers it is an important part of identity, a way to stay alive. A man stripped weakens, he’s ready to lose himself; at the end of the day, he can but cry. Images from Algeria, blurred by time.
Without warning, he was overcome by torpor, found himself on all fours, returned to the third room, collapsing, dragging himself along the floor, pushed his head and shoulders out of the lower exit, taking breaths, better. Again he dropped down the rope ladder, and then taking the long way round the outside, clinging to the rocks, hurting his hands, his legs, returned to the bridge, where he had arrived. Pushed the DS next to the trapdoor, which he reopened. Disconnected the petrol pipe from the engine, began to let it trickle out. Then a ribbon of petrol, moving some metres away. He lit it, the fire took hold slowly, then suddenly blazed, the various kinds of plastic, from the rooms and the vegetal seeds burned swiftly, a lethal smoke. Mounted the motorbike, took off in the glare, chuckling to himself, silently.
The silent you within Shintaido
Video introducing Shintaido on Vimeo
In this short and informative video you can glimpse at Shintaido, a beautiful body movement practice which is hard to define in words. I have been practicing it for more than 10 years, and got more help, inspiration and energy from it than I can express in a short blog post.
Anybody can practice it, and I also believe that everybody can find something unexpressed in their “mind life” that can get to the surface, get articulated simply through the stimuli of Shintaido movements. Trying it out with a teacher is the best way: you may find a teacher near you through the Shintaido web sites, start here:
Italian translation – versione italiana: in questo breve video potete dare un primo sguardo a Shintaido, una pratica di movimento. In Italia c’è una associazione nazionale Shintaido, che ne promuove l’insegnamento, sotto la guida di Gianni Rossi; dettagli su
Tre rotori per la Regia Marina
Un racconto breve. A short story in Italian.
L’improvviso attacco albionico cielacqueo rimbombava la nave. Ricciocannonuta, aveva scacciato al primo giro le zanzare idrovolanti, ma sotto la morbida pancia era esposta, e puntuale un idrotorpedo la trafisse; gli italiani iniziarono a morire.
***
La sera prima Merolle aveva avuto l’onore di cenare con il capitano dell’incrociatore pesante. Era addetto marconista e alla codificazione dei messaggi. Il capitano l’aveva invitato perché incuriosito dalla macchina codificatrice. Cena in cabina, segretezza e non incitare gelosie gerarchiche: Merolle era solo tenente dell’esercito, imbarcato per questa missione. Aveva spiegato che la macchina Enigma C38 Hagelin generava messaggi che solo Supermarina poteva decifrare, possedendo la stessa macchina e stessa disposizione iniziale dei rotori. Un’intera vita umana non sarebbe bastata a decifrare un singolo messaggio: gli mostrò come calcolare il numero indicibile di combinazioni possibili, l’elettromeccanica cambiava chiave a ogni pressione di lettera, vanificando la ricerca di ripetizioni; usava metafore per illustrare la varietà combinatoria, che in realtà il capitano capiva nei dettagli. Merolle lasciò esaltato la cena e la cabina, immaginando il momento in cui avrebbero sorpreso i lenti mercantili inglesi.
Al risveglio del capitano l’ufficiale in seconda chiese di essere ricevuto; comunicò di aver sorpreso il tenente Merolle nella notte in sala marconisti fuori turno, questi si era giustificato sostenendo di essere in gara di velocità di decrittazione con il ricevitore di Supermarina, l’ufficiale aveva rimandato Merolle in cabina. Il capitano ordinò al vice di non procedere né con punizioni né con indagini, il tenente era semplicemente un appassionato.
***
Ora altri aerei li mitragliavano in coperta, e si intravedevano navi inglesi.
La nave era ben corazzata, in violazione italo-tedesca del patto di Washington, ma i pesanti cannoni erano inutili per la contraerea, lenti. Urlava il panico tra quelli che erano soldati e non più; rimanevano degni i pochi nell’intorno del capitano, che osservava torcendosi binocoluto, senza impartire più ordini; il nemico doveva sapere per tempo dove erano diretti. Collegò i fatti.
Merolle aveva escluso dal possibile quel che accadeva ogni minuto: il grande orecchio inglese leggeva facilmente i messaggi italiani, codificati da soli tre rotori; tutti decrittografati in pochi minuti da matematici umani e combinatori elettromossi, segretamente riuniti nella campagna a nord di Londra. I comandanti italiani non erano neanche capaci di immaginarlo.
Impassibile, scese in sala marconisti, c’era Merolle seduto, inutile, spaventato.
Il capitano parlava basso, tra i denti: “Come hanno saputo la nostra destinazione? L’ordine l’abbiamo letto solo noi due. Solo tu hai accesso alla radio e alla codifica. E come mi hai spiegato, nessuno può intercettare e leggere i messaggi, tra noi e Supermarina”. Impugnava già la Glisenti, lo inquadrò nel cerchio dei nove millimetri. Sparò all’innocente, poi alla radio. Merolle morì lacrimando.
Il capitano prese i codici e i tre rotori della macchina codificatrice, li portò in coperta, li buttò in mare uno alla volta, rendere impossibile il recupero nemico. I marinai superstiti si affannavano alle scialuppe, una parte della nave bruciava; il biplano ricognitore a prora era uscito dalle guide per un’esplosione, stava sbieco e ignorato, simbolo della peggiore sconfitta.
Il capitano non si guardava intorno, nessuno si avvicinava. Appoggiato al parapetto, fumando, affogò borbottando maledizioni in genovese, il dialetto che aveva perso entrando in marina. I marinai sulle scialuppe furono salvati dal perfido nemico.
-
Note
Il racconto è fantastico ma intessuto di dettagli reali. L’ambientazione è la “battaglia” di Capo Matapan, dove gli inglesi fecero libero tiro a segno sulle mal comandate navi italiane; i pochi marinai superstiti furono quasi tutti salvati dagli inglesi stessi, la marina italiana ritardò persino nei soccorsi.
La macchina codificatrice era usata realmente dalla Regia Marina Italiana, e realmente intercettata e decrittata dagli inglesi (Alan Turing & co.) di Bletchley Park.
La Glisenti era la pistola d’ordinanza degli ufficiali di tutto l’esercito. Supermarina era il comando superiore della Regia Marina durante la seconda guerra mondiale.
E’ noto che almeno un comandante delle navi affondate a Capo Matapan decise volontariamente di rimanere sulla sua nave che affondava.
