Captain, where are we now Sir?

You just spent a year or two leading this project.  As a pure open-source, project it is a success. Lots of forks and a lot of stars. Now is the time to sell the baby.

What Could Possibly Go Wrong?™

The halcyon days of leading a tightly knit C++ team of like-minded, peers are gone.  You are now responsible to “make a product” that will be used in many different but very valid, situations by many different and very relevant teams. Also known as “paying customers”. Few galaxies away from the Git Hub fraternity. And now.

The investor’s are banging on your door.

OK. Not to panic. Let’s move slowly backward until you are able to see the full picture.

Let’s call your product (to be): XYZ. XYZ is a (very useful, fast, and snazzy) C++ library. It is fast because it has also some very clever low-level, OS-specific code using the underlying OS services and the CPU that needs to be not older than .e.g 2 years. It is a wonder how fast it is. Allow me now to paint the:

2021 Q1: The full picture

  • The primary value of any C++ code and thus your “XYZ” product too, is on the cloud-side a.k.a. server side.
    • Living in a run-time alongside apps/modules/services written in a myriad of languages, not just in C/C++.
    • Across many solution domains: NoSQL DB, Message brokering, trading, simulations, and such.
  • Server-Side Business Logic is not written in C++.
    • It actually is not, for the last 10 years or so.
  • Server Side business logic components are written in Python, NODE.JS, .NET Core, C#, Java, GO, SWIFT, and such, but not C++.

These are the cold facts. And you are now responsible to produce the plan. The overarching theme is: How to make XYZ malleable and feasible for a lot of projects and their server-side components. Some of them projects wish to pay for and use your baby: the “XYZ”.

To visualize and make you understand better the role reserved for XYZ here is one typical Cloud Side (Azure) system that might be using it, where it might be needed. Can you spot your product, aka “XYZ”?

Spot your product
Quiz question: Spot the product “XYZ”?

There it is! Just in the middle, it is used from NODE.JS code implementing that “Function App 2”. Huh, NODE.JS? Ah ok, that really means some C front.  That is what I am calling a “full picture”.  With the big neon sign in the middle:

Integration is the key to your success

That really means integration of you personally and integration of your product. Those are the two keys to enter the market and stay in the market.

Please note that is just a very high-level view on the “cloud side”, of the common system architecture, in which you and your product: “XYZ” will be used. Or not.

What the eval license is for

Even if  “XYZ” is bought by the team responsible for the delivery that does not guarantee the actual usage. They usually buy a few shortlisted components and then select the finalist “in house”, without vendors present.

Actual real-life reasons these organizations and projects might pay and use “XYZ” are falling into only three categories:

  1. Comfortable API
    1. Or “Dumbed Down API” as known in your  GitHub uber circles
    2. You need to “integrate” with new “friends” who have bought just one eval license.
      1. Developers and management.
  2. Speed & Security
    1. “XYZ” will be hammered and abused over and over again. In all sorts of very “unfair” situations
    2. That is where you need to stay calm.
  3. Cost
    1. The Maintenance cost is the most critical component of the final cost
    2. This is where you should realize, competition is somehow always cheaper.

In that order of relevance. Yes, you got that right, the cost is least relevant. And customers are not always top-level snazzy C++ developers you worked with, in your previous GitHub life. And it seems that was just yesterday.

And the plan is, Captain?

Recap. So you have these bellowed C++ baby of yours. And now, you have investors who are asking you to make it into a product that will be sold. So they can enjoy a large ROI. That means much more than few copies. And to maximize the ROI,  “XYZ” will have to be easily installed and maintained on all the relevant cloud’s. On both relevant OS-es. By now there is one prevailing thought coming fast and direct: “This is not fun”.  Thinking of leaving? Hardly practical. Please stay.

Chinese Proverb: “Stay cool calm and collected, and all things will fall into place.”

My proposal to you is to respect the core observation: Integration is the Key. Thus I suggest to you if you want to sell it and do that repeatedly, dramatically change/refactor “XYZ” to conform to the following:

  •  Re-Architect
    • First re-write XYZ core in C11 — delivered as .h and .c file(s)
      • That is the only feasible way to integrate your product, cloud-side. Any cloud.
      • The only way around the ABI problem.
      • yes, that might include Android and iOS
        • for which you never planned because you dared not to hope investors will find you interesting.
  • Re-Factorize
  • The second step is C API (aka interface) to the C11 core
    • that is the only feasible way for customers to integrate XYZ into their server-side
  • The third step is a remake of your single header Standard C++ API
    • using that C11 core engine
    • that is for few teams wishing to use the XYZ in their C++ 11 code.
      • Wait! Did I say: 11?
    • Be sure to be malleable about the C++11/14/17/20 issue.
      • 2021 Q1 many customers are still on C++11.

And now the “secret sauce”. If carefully planned this seemingly high-risk strategy will be much easier to implement than your team might think. That is your code. It is already well designed with a very high degree of decoupling and encapsulation in place. Right?

This is really true

First of all, you are quite able to decide on that one. My favorite use case argument is SQLITE. Read and think about it. That ubiquitous “embedded” but full SQL database file driver, is first and foremost super easy to integrate into “everything”: consumer devices, medical devices, mission-critical devices, mobile platforms, any OS you can imagine, and runtime module in any language that can integrate with C (read: all of them).

And then try to think how you would achieve the same market penetration and staying power, with your XYZ you and your team wrote in “standard” C++ as your codebase primary language. But please do not forget all the socio-political-economical requirements of which some are explained above.

If XYZ has been re-done into what I boldly advise to be done this is the runtime with XYZ ticking in many instances on the server-side stack on the left: