Services, trading, manufacturing, products

It is interesting to write about something I find confusing, not something I’ve figured out. This time, I’ll just pen the questions I see, not answers.

My train of questions started from the term “the service sector”. Remiges is a software projects company, therefore it’s in the “service sector”. And I am told that there are three sectors in the post-industrialised world: Trading, Manufacturing, and Services. Ideally, I should be able to look at an enterprise for five minutes and pigeonhole it into one or other of these three, right?

In that case, why am I confused?

Software services: the T&M model

When I was doing my Masters, the dot-com boom and SAP boom were, well, booming. The software services sector was breathlessly recruiting people, imparting some token training, and shipping them first to the consulates (for visas) and then to the airports (for flights to the US).

I am told that all this is part of the services sector. I cannot understand how. If I buy something from a market, perform very minimal value-add, and ship the “resources” to my client as billable value delivery, this may be services by some definitions, but it has all the characteristics of trading to me. I saw so many Indian engineers who had been employed in US technology companies till then, resigning to jump on the body-shopping bandwagon, building successful businesses with 500 “resources” on their payroll. And of course, we all know that the genesis of the largest software services giants today was in this “trade”.

If I keep textbooks aside and try to understand this model, should I put this business model in the Trading bucket or Services?

Staffing companies

There are quite a few large companies in India who have a few thousand programmers on their “payroll”. Their employment contracts are interesting — they pay almost nothing to their “employees” till they get a customer where these employees may be “placed”.

Large software companies who need a few hundred dotNet or Java programmers engage with these staffing companies and “obtain” programmers on contract. Therefore, these large companies get to reduce their payroll processing overheads and can increase and reduce their headcount at short notice, without maintaining a large “bench”.

The staffing companies in turn bill their enterprise clients just a minimal markup over the salaries they pay to their employees. I have spoken with a few of these companies, and their markup ranges from 5% for simpler programming skills to 10% for rarer skills.

Is this trading or services?

Red Hat, EnterpriseDB, other FOSS products

When I see these open source products, and the revenue model of the companies which own them, I get confused. Everyone tells me that these are product companies. I am not sure how.

I understand a product to be a car or toothbrush (in the physical world) or an Oracle DBMS or MS Windows (in the digital world). That world is quite black-and-white: the product is “sold” (licensed) to me by the organisation which “owns” (the intellectual property of) the product and stands by it. I pay a licence fee, I get a copy, and I get support plus (some degree of) legal contractual commitment from the “owner”. Just like Honda will accept their legal commitment to give me a reliable car which meets their published spec.

When I look at Red Hat, I see a mighty global community working to contribute and maintain the core product (Linux), most of whom are not Red Hat employees. And a team from Red Hat curating and further managing it to create well-tested, packaged releases. Most of the intellectual property of what I get in a Red Hat ISO is not owned by Red Hat. I do not pay a licence fee — I pay a subscription for support.

Is Red Hat in the product business or the services sector?

Gmail

Is Gmail a service or a product? I do not get any digital copy of any software, not even if I’m a paid client of the commercial Google Workspace offering. I use whatever they operate on their cloud data centres, from a distance.

The Google guys are operating some software and hardware, to which I don’t have access except through the official user interface. I cannot install or uninstall the software. I simply use what they operate. They do all the hard work of upgrading their software and backing up their hardware and what not. It sure seems like they are offering a service to me.

I am told Gmail is a product. Clearly I understand very little.

What is a product?

Once upon a time, we used to believe that if a company manufactures many identical copies of a single item and sells them to different customers, that was a product. Like a toothbrush, yes, exactly. The operative phrase here is “buy and sell”. With commercial software products, this “buy and sell” shifted to “license”. You paid for a licence, got a DVD, installed the software on your computer, and got on with life.

Then it switched to: if a company makes one piece of software and runs it on just one server, but sells user accounts to many customers, and they all use that one instance of software on one server, that’s a product. A SaaS product. The operative word switched to “use”, not “buy”.

Then it morphed to something different. A company picks up a piece of software which they did not write and whose intellectual property they do not own. They can do these things, the software is OSS and its licence permits this sort of picking-up. They put in a lot of hard work to test it, debug it, add some extensions and features, and build a good team which offers technical support. And they sell this support. And it becomes their product. They are a product company. From where I’m standing, technical support is a service. I wonder what Red Hat charges by way of GST in India — do they categorise it as a product sale or a service delivery?

This is not too different from a restaurant which cooks food as per well-known recipes, serves me at their tables, and charges a fee. Is a restaurant a product company? Is that plate of biryani their product?

The Remiges product strategy

Remiges is making OSS products which anyone is free to use. Remiges is the first customer/user of our products, because we incorporate them in the applications we build for our customers. Three out of our six products: Alya, IDshield, ServerSage, are being built by extending existing leading OSS products: Gin, Keycloak and Prometheus respectively. The other three Remiges products: Crux, Rigel and LogHarbour, are designed from scratch but use open source components where needed.

Our products will always be available as OSS, and we will keep growing, debugging and supporting them as long as we are in business. But we are referred to as a services company, since we build modern bespoke business applications, which sometimes use some of our products if needed. We will also be happy to enter into contracts to help clients incorporate our products, configure them, and operate them. We will bill for setup, training and support.

Analysts ask us why we are building products if we are not earning licence fees from them. We tell them we do this because it helps our projects business grow faster. They all know the magic word “SaaS”, so they nod knowingly and ask us, “So, you will offer your products as SaaS offerings?” We say “Possibly.” They feel even more confused. If we simply say that our products help us deliver bulletproof custom software solutions, they circle back to the same question: Are we in the services business or products business?

We also have completely frozen our standards and processes for software project development and delivery. We don’t exactly build custom software in completely open-ended ways — we build them the Remiges way. We capture specs as per our standardised processes and templates. We design our web services to accept parameters as per a standard structure. Our web services generate errors in a precisely defined format which remains constant across all the systems we build. Are these services therefore “productised?”

We say that Remiges is a software projects company. We are not a product company till you stretch your definition of products. Are our standards, tools and templates “products”? We also make actual products too — we have six currently. And we do product engineering for some of our clients as part of our services business. Since we know how to make products, our clients entrust us with such contracts.

What do you think? Who are we?

My take on this question

I believe that the distinction between products and services have blurred. The key distinction is: who specifies the specs? If Remiges designs something as per our understanding of a general requirement, and then incorporates it into multiple systems, it’s a product. If our client designs something to meet their very specific internal requirements, and it will be used only internally, it’s a custom software application. If our client designs something which will meet their customers’ generic need and will serve many of these customers, it’s a product. Like Gmail. We in Remiges can build such products for them, by engaging in a services contract.

A good software services company will do product-based software design and implementation to build better custom software systems. A good designer will identify the generic sub-systems which are required in most projects, and productise them, if the company has the values and ethos of product engineering. Remiges does. No one today writes their own data store — they use Postgres or MySQL or Oracle or ElasticSearch. In the same way, a good software services company will often build a product to fill a gap in the product space, to help them build better custom applications.

All the large software services companies claim to have libraries of “reusable components”, but they do not make these components available for even scrutiny, let alone use. So we don’t know the depth of their “components”. We at Remiges have chosen to take the leap of faith and build and release actual products on GitHub — these are not “accelerators” or “reusable components”.

The world of complex enterprise software applications just got a whole lot more interesting. And somewhat more confusing. 🙂


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *