On 14 March I took a lightning-talk slot at Engineer Cafe, at an event called “OSS Drink Up — the reality of contributing to OSS and earning from it”. An advertisement for it had come past me on X the weekend before; the theme of OSS drew me in, and I thought I might be able to offer a perspective the other participants would not have, so I signed up.
Looking at OSS by layer, low and high
The deck I spoke from is here: How to get around high-layer OSS (lightning-talk deck, “OSS Drink Up”, April 2024)
The talk came down to two things:
- OSS comes in low-layer kinds, close to the infrastructure, and high-layer kinds, close to the business
- The two differ in what they focus on and in how they are monetised
Those were the points I wanted to make.
What I say here about high-layer OSS comes, naturally enough, out of my own years with Odoo. Talking about Odoo in an OSS context, I had felt a sizeable gap between the way most engineers seem to engage with OSS and the way we engage with Odoo, so the talk was also my own attempt at closing a little of it.
How low-layer and high-layer OSS differ
Introduce Odoo as “open source” ERP software and people are often taken aback. “Really — an ERP? And it's open source?”
What most people picture when they hear OSS is probably the Linux kernel, PostgreSQL, Nginx, OpenSSL, Git or Prettier — infrastructure, or a tool specialised in one particular function. That is low-layer OSS, and what it focuses on is mainly technical problems.
Odoo, by contrast, is a suite of business applications for dealing with every kind of business problem, and it belongs to high-layer OSS. Those problems run from “let stock be reserved per customer” or “round tax down rather than up” to “put 様 after the addressee on a report”. OSS work on Odoo takes in technical problems too, but since solving business problems is always the larger goal, what matters is whether a change creates business value and whether it holds together as business logic.
The way money is made changes with the layer as well. In the low layer, companies and industry bodies whose own business depends on a particular piece of OSS sponsor a few outstanding engineers; in the high layer, it is almost always the specific users of a feature who bear the cost, through a service provider such as ourselves.
To paint it rather crudely: in the low layer you have to be technically exceptional and lucky besides before any income arrives, whereas in the high layer someone who is no great engineer but has solid domain knowledge and a knack for sound business answers can earn from it with fair reliability.
What high-layer OSS could become
Something like seven in ten of the people there were in their twenties or thirties, I think, and when I asked whether high-layer OSS of the Odoo sort interested them, that group did not look very interested; it went down rather better with the over-forties. The theme of the event and the general make-up of the OSS world had probably drawn a low-layer-minded crowd, but to those of us working on high-layer OSS the skew still looked considerable.
Years in working life must account for some of it. It is not easy, obviously, for someone short on business experience to take on a business problem and produce a result. Keeping up with technical trends, on the other hand, favours the young. That younger engineers drift towards the low layer may in a sense be inevitable.
Look instead at software engineers a little further into their careers and most of them, surely, understand business but have no feel for OSS. I have no exact figures, but thinking back twenty years or so, hardly anyone around me was doing OSS work either.
Which is exactly why high-layer OSS feels to me like a large opportunity, and why I think the people who will work in this segment are still to come. Engineers who are short on business experience today will gain it, and some will find themselves taking on business problems. I would like high-layer OSS to be there for them — somewhere to land, and an appealing place to do the work.
It hardly needs saying at this point, but underneath OSS work lies the idea of sharing the cost between everyone rather than each of us handling the same problem alone. Even software as good as Odoo is not adequately localised for Japan, and it is plainly more efficient, and more valuable, looked at whole, for the community to build the missing pieces together and to squash the bugs. And yet participants are slow to appear. Why that is, reasons and all, is exactly what I set out in “Why You Should Contribute to OSS Communities”, and I will not go over it again here.
The way out, I think, does come back to monetisation. There is a great deal to be gained from taking part in OSS work, but players do not gather around a game with no expected return. Quartile provides value to the community through its OSS work and takes a reasonable return in exchange, I would say — but I feel we need to build methods and mechanisms that make that return far more repeatable, and then share them with the community. I have ideas I am turning over, and I would like to give them shape by degrees.
Thoughts on the event
The main speaker, Suzuki-san, gave a talk with real pace to it and I enjoyed it enormously. My impression was not of someone holding up one of those high-minded goals and marching at it, but of someone who followed their interests through the twists and turns, produced results along the way, and has arrived somewhere worth being. More people like that and society would be a more interesting place. The other lightning-talk speakers were visibly committed to their OSS work too, and although our fields differ I felt a certain kinship with them, uninvited as it was.
It was in fact my first visit to Engineer Cafe, and Murajun-san facilitated it so well that I spent a thoroughly enjoyable few hours over a highball. Thank you, Murajun-san!
Can high-layer OSS attract more players?