EPO Conference 1. Speaker João Miguel Neves
Ladies and gentlemen, thanks for inviting me to be here and for taking the time to, like me, try understanding what the heck is the software industry about and what's at stake in all these discussions on software patents.
My name is João Neves and I'm the CEO of Intraneia, an IT support company. I was asked to come here to share some of the reflections I've done throughout the years and that resulted in Intraneia's present form (and paying clients).
So the first thing we went through was the pain of accepting that we don't create value. For people that always worked in the IT business, that's a very painful realization. IT doesn't add value per se, it allows the reduction of costs, either through empowering people to do more or better work with the tools we provide them, or replacing people with machines through process automatization.
This realization was so strong with us that it defined the name of the company: Intraneia is a wordplay on the greek word for entrail, meaning that our job is to work inside the organizations supporting their business. (Sometimes the organization is a set of companies wanting to work together.)
Knowing this we started gathering what our potential clients would like to have and were willing to pay for. Having already clients as freelancers helped this process. What we found out was that our clients weren't claiming for more software, but for two different things: 1) the right software, 2) how to use the software they already have.
By the right software, I mean software that will have a positive impact in their operation (reducing costs or allowing them to do more with the same resources). They needed someone that either had a broad knowledge of the software available (and respective services) to help them choose. They also needed someone that could build and maintain the bridge between their needs and the what the software does (what we usually call implementation and support).
Nothing of this is new. After all it's something that's been known for a long time as IT consulting. The little difference I failed to mention before is that the clients needing this are micro, small and medium enterprises who can't afford to deal with the big IT consulting companies.
It also means that some of the projects are one-time short projects (sometimes covering less than a week). Some others realize that they need constant support and we just agree on a regular payment for services rendered.
Regarding "how to use the software they already have", I just want to say that most software implementations keep disregarding the users. Even if the interface is supposed to be intuitive, our experience is that it's easy to teach someone to double its efficiency in working with tools as widespread as office applications. Right know there's a huge population of users that (rightly) mistrust IT professionals. We found out that hand-holding those users on their workplace for a few minutes every week or even month helps regain that trust and wins a loyalty we never expected.
But it's not only end-users that mistrust the IT industry. The well-know failure rates of implementation for an IT project going well over 70% don't help (and some people still wonder why - unfortunately I've heard repeatedly remarks like "but it only cost twice the budget").
The other reason they mistrust the industry is because of the difference between their expectations and what they get when they buy software. They expect the software they bought to be ready to use.
Instead they find out that they need maintenance, sometimes even patches for it to start to work (or even install), training (that didn't come included and, unlike batteries for a toy, there was no mention of it in the prospect or in the box of the product).
The more experience buyers mistrust the IT industry for even another reason: they've had the experience of dealing with legacy applications. Legacy applications are the zombies of the IT world. They exist and are kept working because they simply work. These are unsupported applications, for which maintenance is extremely expensive. Replacing them is a risk: nobody will give you a guarantee that they'll replace, function by function such an application and that it'll work as the old one did (unless you pay a small fortune that I'm always willing to receive).
So either the risk of not replacing them becomes too big (like it happened with the Y2K bug), and you're willing to risk the replacement, or the zombie will just keep lingering somewhere in the server room (or closet - depending on the company).
By the way, some technical solutions needed to deal with the legacy applications problem are prohibited by european copyright law. These solutions are usually refered to as "reverse engineering", even if there are legal reverse engineering techniques.
So we have a lack of trust that comes from failed projects, a gap of expectations between users and vendors and the non-existing support for old apps. This is what we defined as our opportunity.
So our projects had to work, our products and services had to include training (formal and on-the-job) and support, and we had to have the possibility of supporting our systems as far in time as needed by our clients. This defined our mission.
From there on, we had our basic requirements for our processes and licensing needs.
Our products are based on reliable, well-supported software (where well-supported means: with information so that we can support it ourselves). Our most used processes always start with a full audit of infrastructure and setting up a monitoring system.
As for the licensing needs:
In an industry where 20 years is an era, outdated means 3 years, and you have computers reaching 10 years and some software programs more than 30 years, we established that we needed vendor independence.
Supporting software over the lifetime of the vendor, means that we need to be able to modify it and distribute the modified versions to our clients.
For some reason, our clients insist on using the software, so the possibility of using the software might be included.
So, these were our needs. But that was not enough. We found out that, for some reason, our clients weren't willing to depend on us (one of them even insulted us that we just wanted to be like all the other vendors). So they also wanted the ability to be independent of us.
That's one of the reasons why we work mainly with free software, the only way that we found to go over the gap of mistrust was to give our clients the freedoms to use, modify (or hire someone to modify), copy and publish modified versions. Or, as I like to put it to prospective clients: the freedom to work, vendor independence, the freedom to grow and the ability to share support costs with others.
This also means that the software we produced is also licensed in the same terms. I would just like to note that most of the software we produce is a result of direct client needs. We don't produce software just because we felt it was a good idea and hope somebody will pay for it.
For some reason we don't quite understand, some customers like the idea that we can support software that they can download gratis from the Internet.
One of the internal discussions we had was about: we're using software done by others and not paying them for it? To avoid that, we adopted a rule: a percentage of every contract go to the software projects we used on that contract. Honesty and rewarding good work are two of the values of our company.
So, with all this defined, we started collecting contracts (I prefer collecting contracts to selling them, a steady cash-flow is better than nice values once in a while). When we receive the next payment, we will have reached operational break-even, which is impressive for us.
In the meantime, and a bit of the reason I'm here and having someone covering for me back at home is all this software patents issue. Until know we could just use the software and be merry (legally acquired software, of course). What we found out is that we are at risk of closing down. Most of the software we present to our customers is made by others. We also work in a low income market (by IT standards) depending on highly intelligent and well-payed professionals. Our sucess depends on automating most tasks so that emergencies can be delt immediately by very good professionals, preferably before our clients even notice.
What changes with software patents? We risk being sued, or even worst, that someone sues one of our clients. In this situation we have a simple choice, either to defend our client, or to get throw out of the market because no one will want to deal with a company that implies an aditional risk to their company.
The problem is that diverting, at this moment, one of our engineers to reply to a subpoena, means loosing support to hundreds of computers that need to be payed to a freelancer to be on call. Even with our network of experts, that costs can go over 1,000/day while that engineer is analyzing the situation. Either that or diverting the work to the other full-time engineers, risking to burn them out (which would, in the long term cause lost customers for degraded service). This can happen even with software we produce to solve a client's problem. And this is not taking into account any legal costs and the fact that a court case in Portugal can easily take 3 to 20 years.
I've talked about the basis of my company, the reasons we adopted our mission and licensing model and what we fear regarding software patents.
