Lino reaches a new level

Sunday, June 28, 2020 (last edited Friday, July 3).

We are entering a new chapter in the history of the Lino framework. Many customers and friends have encouraged and supported me during the past years to become a better salesman. I am grateful for these years, but one of the important things I learned is the following.

I am not the guy who is going to sell the big Lino vision. It is time for me to step back from that chair. Because somebody greater than me must sit there. We all want Lino to become big, but I don’t want to become big myself. Lino makes no sense if it is used by only one development provider. It makes sense when many providers can use it as a shared tool to provide their services. I don’t want Rumma & Ko to become yet another industry-level development provider; the world has enough of those.

We can now say that Lino has successfully passed the proof-of-concept state. We have shown that it can be used for providing industry-level software development. The technical aspects are fully satisfying.

The main bottleneck that prevents Lino from entering the next level is the commercial side. People who realize this bottleneck keep telling me things like “Luc, you just need to publish a simple website for Lino Così that explains what the product does and how to give it a try.” And I keep answering them “I just need to? Don’t you know that this is what I am already doing on Do you imagine how much time this took me? Stop taking me for a magician!”

Another bottleneck is that there is no reason to go faster than history. The most important advantage of Lino –avoiding vendor lock-in– is still very difficult to sell. The breakthrough of free software is not yet achieved. Normal managers still prefer a proprietary system over a sovereign system because that’s cheaper and more comfortable. We all tend to value comfort over sovereignty. Normal people just shrug when I tell them that avoiding vendor lock-in is more important than their comfort, or that I will rather grow potatoes and chicken than accepting to write non-free software. Lino exists only because I am crazy enough to believe that open solutions will become the norm some day. I am realistic enough to see that this day might not be very soon.

And here is how this step will look like: Tonis and Hamza will no longer work full-time for Rumma & Ko with a monthly salary, I will rather pay them per hour or per task when there is some work to do. They will remain available for cases that require more work than I can do. Their confidentiality statements with Rumma & Ko will remain active and we will continue to fully trust them. Rumma & Ko will continue as before, all customer contracts will continue, and we will accept new customers. This model can work sustainably as long as I am able to work as a software developer.

The switch will happen as soon as they found a new employer. Given their skills this won’t be too difficult. At the moment we think that Thorgate (Tallinn) want Tonis and AbAKUS (Eupen) want Hamza.

In other words, I send Tonis and Hamza into the world so that other software development providers can use them. I invested into them, paid their salary while they were learning Lino, and now I “give them away” to my “competitors”. A move that would look like a failure in a proprietary world but makes perfect sense with free software. The hope behind this move is that their new employers will start Lino projects within their company or for their customers.

The years with Hamza and Tonis were beautiful and enriching for me. They helped me to grow at many levels. I discovered the beauty of social skills like delegating, leading, managing, selling, manipulating and promoting. And I have no problem with admitting that I am not very good at these skills. These years helped me to learn about my vocation: I am not a boss who tells others what they should do. I prefer listening to other people and then telling their computers what to do in order to help them. I have valuable experience about how to make business with customized database applications, but I prefer sharing this experience by writing code and documentation.