Private Opinion

If you have ever had your wisdom tooth taken out, you know how tempting it is to poke the crater left behind with your tongue. 

There is something satisfying about rolling your tongue where your tooth used to be. Maybe it has something to do with our evolutionary past: Many animals lick their wounds. I'm neither a zoologist nor an evolutionary biologist, so I leave the answer to the experts. Still, I have put my tongue where my wisdom used to be many times, both physically and metaphorically, to know the pain that follows.

Dentists know this phenomenon very well and strongly and explicitly advise you against it. If you lick your dental wound, you might take out the blood clot formed in its place and open it to all sorts of infections. 

Most of our late-night TV hosts are licking the wound left behind after Trump was extracted from the Whitehouse and risking a great deal in doing so.

True, Trump is as far as you can get from a wisdom tooth, not just because he's not a tooth. But the risks are all the same.

Here I'm not talking about Carlson Tucker or Laura Ingraham, who are still recovering from the shock of the election on Fox News. 

I am talking about Jimmy Kimmel, Seth Meyers, and a few others in their ranks on the left, progressives, liberals, or whatever you feel comfortable calling them. 

These guys are risking the blood clot coming off, and the result will not be pretty.

Firstly, I understand why Jimmy Kimmel cannot let go of Trump. Trump was comedy gold. These TV hosts have never had it so easy: from misspelled, all caps, and toilet-written tweets to ruffled combovers or giving a ride on the Airforce One to a piece of toilet paper, who can resist not making fun of him?

The issue here is that by refusing to let go of their comedy golden goose, they are making three mistakes.

First, they keep Trump on the airwaves constantly. Do you remember when an empty podium was on CNN for 40 minutes because Donald Trump, a joke of a candidate, was about to give a press conference? This is how Trump got the publicity he needed to run, and he got it to everyone else's detriment. Even Jeff Zucker admitted that it was a mistake. This time, however, this is not about Trump. This is about the grip of the populists on the GOP. Marjorie Taylor Greene and Matt Gatez are no fools. They grab the headlines by saying outrageously populist things for publicity, not ideology. Giving them air by anyone is a trap, and Mr. Kimmel can't see this trap through the gleeful laughter of his audience.

You might point out that Kimmel and Meyers' audiences will never vote for Ms. Greene, so what's the harm? Well, isn't that the central issue with American politics? That we are so wrapped up in our cocoons that no matter what we see or hear from the other side, we're never going to consider them worthy of our votes. 

This leads me to the second sin of the late-night TV hosts: playing the role they are being assigned in this drama.

The Trumpists on the right have a clear description of their opponents: Elites. 

In their portrayal of the left, the bicoastal elites look down and laugh at the hard-working and honest Americans. They are getting richer through their schemes of globalization and free trade and kicking down those who built America of the past. Immigrants take away whatever opportunities are left for the factory workers of the rustbelt, while the progressives worry about which toilet we can enter.

All the while, the majority on the left still don't have a clear way to describe those who elected Trump in 2016, and as such, they revert to laughing at the stupid things that happen on the margins, thinking the problem was Trump and it is now solved. Hurray! Bring out the champagne, and let's have some harmless fun. 

Making fun of the "hard-working Americans" is precisely what the populists say the elites are doing instead of listening to their grievances. 

Well, guess what, if you successfully position yourself as the champion of the ignored and disgruntled middle America by telling them they are being laughed at, what's the best thing that can happen to you? Jimmy Kimmel from California.

The third issue I take with these times' comedy shows is the missed opportunities. 

Between them, Jimmy Kimmel, Jimmy Fallon, Stephen Colbert, Seth Meyers, and Trevor Noah have more than 45 million subscribers on Youtube only. That's almost 15% of the US population. Assuming most of that 15% is on the left of the US political divide is not too off the mark. 

Therein, Kimmel et al. have the opportunity of helping to bridge the chasm of US politics. By using their talent in comedy, they can show the more rational and reasonable side of the 150 million of our compatriots instead of focusing on their divisive fringes and playing into the hands of the worst of our politicians. 

Ignoring this opportunity might bring about another round of golden comedy material for the hosts through the election of another ignorant, bigoted, demagog-wannabe with much more than a fake orange tan to make fun of. But in the long run, we're all going to have to pay a higher price to fix what we all broke by our condescension and laughter.

Imagine 100 people in a stadium. Write down their heights, round it up and take the average. I don't know what your imaginary stadium looks like. Neither do I know who your imaginary 100 people are, but I can tell you for sure that the average you just wrote down is no more than 8 feet. Now, go back to the beginning and this time write down your contenders' wealth and take an average. This time, it would be impossible for me to give you a range of this average number. I can make a guess about the average height, because I know it to be impossible for a human being to be so tall to raise the height average of 100 people up by so much to take it over 8 feet. However it's completely possible to imagine only 1 of your 100 sample to take the average to $100M dollars or more from the global average of well below $10,000. By the way, how did you manage to get Bill Gates into a stadium?

The Black Swan, is about the impact of highly improbable. Until the 17th century people used to think swans are only white. It was simply not possible to think of a black swan. However, in 1697 the Dutch explorer Willem de Vlamingh discovered black swans in Australia. Following black swans, Mediocristan and Extremistan, Taleb tells us how predicting the future in Extremistan is impossible, futile and potentially a bad thing. He tells a convincing story of how self proclaimed "experts" fill up the airwaves and newspaper columns to tell us about the markets and other things from Extremistan where their opinions fare no better than a coin toss. In Thinking Fast and Slow, Daniel Kehneman, the Nobel prize laureate in economics, cites numerous experiments where not only the estimates of experts were worse than random guesses but actually worse than of the average population (who fared slightly better than random chance).

Now, don't get me wrong. I believe in mathematics as much as those VCs and cannot disagree with their logic of trying to find companies that will produce a 10x return for their funds to beat the market. My point is that, in a world so firmly grounded in Extremistan where events are unpredictable, improbable and have huge impacts, how do they pick the winner? More importantly, how do they, and the founders they pick predict the future, forecast it, plan for it and succeed?

I don't know the answer. If you are that person who's pitched a social network in 2003 to a VC, I'd love to hear your story. What I do know however is how things turned out to be, with the benefit of hindsight of course. I know Google abandoned Orkut for unknown reasons shortly after that. I know Facebook became popular with college students, until their parents showed up on the site so they had to leave Facebook for Instagram and Snapchat. I know everyone thought $1B is an insanely high price tag for Instagram until Facebook bought What's App for $19B and made Instagram founders look like losers. I know none of those who invested in What's App could give me a reason why they invested in it and more importantly none of those who didn't invest in What's App could tell me why they didn't. I know everyone thought Snapchat founders are rich, spoiled kids out of their minds for refusing a $3B acquisition offer until they went public. I know Twitter finally managed to be a business, more or less, or still is trying, this time in the public eye while Ev Williams started Medium to encourage long-reads, as if to resolve himself from his sins of making people's attention spans even shorter. I know once they realised they lost the social media game, Google tried to enter the market again with Google+ but didn't succeed and no one knows why they left the market they were in first and why they didn't succeed the second time with all their might.

We don't know these things because we haven't seen the rest of the movie yet but that's not the point. The point is there is nothing, absolutely nothing in the past events in this space that can be used as an indicator of what's coming next. In short, there is no value in history when you operate in Extremistan.

The point is, startups are as extreme as Extremistan gets. As a founder, you can - and should - have a vision of the future. You can - and should - have faith in your ability to change the world (and reality) and execute your vision. Without the vision and borderline delusional faith, you won't be able to make it. You might even want to raise capital from some of those experts, known commonly as VCs to accelerate what's working for you. But don't confuse what's necessary for success with what makes you successful. More importantly, don't ever listen or believe the experts who weave stories about the past events to convince you they can use those events to predict the future.

“We’ve built a 70,000-node Mesos cluster for our developers, but they won’t use it. Can you help?” This was the beginning of a conversation with the VP of infrastructure operations in a very large and famous company. While an impressive feat to accomplish, it was also by far the largest containerized infrastructure setup I had seen that had gone unused—nor, sadly, was it an isolated incident.

I’ve talked about this encounter with a large number of customers, analysts, friends, colleagues, partners, venture capitalists, and competitors. We all expressed similar experiences, and all wanted to know why this is so. After all, if so many resources are being wasted in our industry, we are all risking a great deal by not understanding and solving the problem. Otherwise, the next wave of adopters might start to doubt containers can help their businesses, and we would all need to starting polishing our resumes.

I have to be honest here: I am a developer, an engineer and a technologist who loves to build products and use the latest technologies. So, the first place I looked, in my quest to find an answer to this 70,000-node question, was the technologies used. Was Mesos the wrong technology? Was it implemented the wrong way? Did they use open source or closed source? Was there an SI involved? Questions like these came first to mind. In hindsight I think those were probably the wrong questions.

Sitting at my desk as a developer in a large bank, I remember impeccably dressed salespeople coming and going into our meeting rooms, courting our VP of infrastructure and his team. They were from VMware, back then the company for virtualized infrastructure. I was just a developer at the bank, but not even my boss or his boss or even his boss’s boss were invited to any of the steakhouse dinner events the VMware people were hosting almost every week. VMware salespeople were only interested in the operations and infrastructure decision makers. Two or three months later, our team was told that a deal with VMware had been signed and we would be moving our services over to VMs soon, and shortly after this move took place over a couple of weekends.

Then one Monday morning, the services my team were responsible for were running on VMs instead of the old bare-metal servers with flashing blue lights and noisy fans. That was all. Our entire infrastructure was virtualized in a matter of months without much say from the developers, and while we were putting on some fake resistance for this change (and who likes change after all?) and grudgingly agreeing to be on standby over a couple of weekends, we couldn’t really tell the difference between the old and the new setup: Everything was the same. Our VM servers behaved and felt like “real” servers. I am sure we wouldn’t have been able to tell the difference in a double-blind test if anyone had conducted one.

Remembering those days made me wonder why the new containerized wave of infrastructure change doesn’t work the same way. Why can’t we build a Mesos or Kubernetes cluster over a weekend or two and send a memo to the developers with the subject: “Welcome to the future of infrastructure. You’re welcome!”?

The answer as we all know is that containerization is not going to work without developers’ involvement and buyin. Developers need to build applications for a containerized setup, but inherent to containers, with APIs like Kubernetes exposed across the software life cycle, is the imperative for developers and operators to change the way they work and communicate with each other. The reason for a 70,000-node shiny cluster that runs tumbleweed instead of business applications is that the tools we have built for this new transition are not addressing this fundamental and essential organizational change, the meshing together of devs and ops.

Each side of this equation (devs and ops) has its own vendors, tools, and open source projects to help them with what it takes to move to a containerized world—but that’s not enough. We are still missing the framework for devs and ops to work together to make this a success. There are simply very few, if any, tools and technologies available that facilitate this communication.

We are all so focused on our individual areas of innovation—from network to storage and orchestration—that we can lose focus on our customers’ achievement of their business goals. In such an environment, system integrator, consultancy and professional services companies do well, as they are the only ones who are focused on the result and on delivering across the software supply chain; but this is not sustainable. Technologies that require customers paying so much to consultancies to make them work are not going to be breakthrough technologies. Let’s face it: If virtualization needed McKinsey to be ever-present on the payroll for it to work, there would be no cloud today.

For us all to benefit from a breakthrough technology like infrastructure containerization, we need to think more broadly than our single-purpose tools or primary focus areas and rethink the way we build products for this industry. This is different from the revolution of virtualization and cloud, and the sooner we realize that, the greater the benefits to our customers.

Devops is not just a bunch of fragmented tools or a fancy “digital transformation” project, it is a method of working collaboratively between functions, enabled by technology. Therefore, any technology aimed at the devops market, specifically around containerization, also needs to address the continuous collaboration mindset before anything else. So, let’s all build products with that in mind to start and maintain a conversation between developers and operators.

This post was first published here

The killer feature of any SaaS business is the massive reduction of operational cost and complexity including setup, configuration, ongoing maintenance and upgrades. Given the runaway success of SaaS in recent decades, we can clearly see that using a SaaS model instead of traditional shrink-wrapped software has made perfect financial sense for many customers. This in line with a theory that says that is a constant level of complexity in a system at any given time—IT organizations can deal with this by investing in-house (investing in a team that handles complexity), or outsourcing to a partner or SaaS/PaaS/IaaS vendor (exchanging money for complexity). When one combines the latter with an OpEx vs. CapEx financial model, easy installation/setup, and flexible pay-as-you-grow options—it becomes be very difficult to justify any other delivery model for generic software.

SaaS businesses, on the other hand, make this model profitable by distributing the operational running costs between many customers using (almost always) a subscription-based model. While legacy software delivery models share the same cost-spreading principle on the R&D level, they lack the ability to arbitrage the operational cost at the delivery level: it is costly to deliver a secure, highly available and continuously upgraded software at scale—and it takes a skilled team of developers and operators to deliver software within the customer-defined SLA boundaries, over time.

Since a large portion of the cost of SaaS development and delivery goes into building the robust and secure infrastructure needed to host the service, vendors make money by building and breaking up a large, robust infrastructure into smaller pieces of the same quality, and sells those pieces to many customers. SaaS infrastructure usually consists of many components—from databases to load balancers—each configured specifically to deliver the service in a particular way, with component-level high-availability (HA), redundancy and security requirements. Think of a typical CRM SaaS: you will need a multi-zone replicated database server, a group of load-balanced and securely firewalled frontend servers, and a cluster of servers to take care of background jobs and housekeeping of the system.

As an example, to keep the details of your 2,000 customers, you will need about 12 servers, two load balancers and several gigabytes of storage; on top of that, add the Ops team cost of maintaining those databases and servers—all of this probably represents a cost of $20k per month just to get going. To make things worse, even with this investment, you are not going to get anywhere near the five-9’s (99.999%) uptime that a SaaS vendor is going to give you at a fraction of the price. In this scenario it makes perfect sense to sign up for a SaaS alternative, paying $2,000 per month for a service that’s always up, upgraded and backed up.

This, however, might change

To see why, it’s worth understanding why running a highly available, secure and robust infrastructure is so expensive. When it comes to infrastructure, “the chain is as strong as its weakest link”. High availability and security cannot be achieved by only making parts of the system highly available and secure—this needs to be done across each and every component, which adds to the cost and complexity, increasing the bill even further.

Now, consider if all those requirements were built into a generic, self-healing, hyper-scale infrastructure, so any application running on top of it was inherently highly available, redundant and secure. This is the promise of containers. Instead of spending time on each service being delivered at a high SLA, the infrastructure takes care of this at the lower level, and provides these attributes as a service to the user. By doing this, containers take away one of the biggest benefits of the SaaS delivery model: infrastructure arbitrage, which I defined earlier in the post. 

Container-based infrastructure systems like Kubernetes allow companies of any size to build their own custom, highly-available and robust infrastructure on top of private data centers or public clouds, at a high granularity and flexibility, without compromising much in return. In this new world of container-based infrastructure, IT teams spend their time on building and maintaining a few Kubernetes clusters, while external vendors and in-house developers use those clusters to provide services to their clients.

It will probably take years to get to a point where this shift affects the SaaS industry at a significant level. However, if we look carefully, we can already see savvy IT teams who are looking to bring on this future: building pipelines for their code, as well as application management stacks that unlock the automation of containerised infrastructure, on both public and private cloud. 

Remembering that I’ll be dead soon is the most important tool I’ve ever encountered to help me make the big choices in life. Because almost everything—all external expectations, all pride, all fear of embarrassment or failure—these things just fall away in the face of death, leaving only what is truly important.

Around 6 months ago, I received an email from Laura, our financial controller. It was the monthly financial projection of our company, but it was different from the previous projection emails in one crucial way: it showed we are going to run out of money in 6 months. Suddenly we were going to die.

It was late at night and while the urge to pick up the phone and call Laura was almost unbearable, I managed to hold back and think. Reflecting on my emotions, I couldn’t help but to have the same feeling as when I had a cancer scare some years back. It was the same feeling: the feeling of facing imminent death.

Naturally I went through all of our available options: raising more capital, taking pay cuts, or letting people go. None of those were good or feasible options. It was like driving at 100 mph and suddenly seeing a concrete wall on the road 50 meters away. Being paralyzed from the neck down on a life support machine might be the best outcome you can hope for.

The next day, first thing in the morning, we sat down and reviewed the numbers. It turned out a misunderstanding on some cashflow realization and rent payment caused the “runway” to drop to 6 months. We were not about to die after all! We made the changes in the spreadsheet and the concrete wall in the middle of the road was gone.

That episode, while triggered by a false alarm, made me think about life of startups and how they are similar to our own lives. The prospect of death brings focus and attention to the most important things in life. This is no different in startups. When faced with imminent death, I didn’t think “maybe we should build a new feature to get out of this” or “perhaps it would help to release our product as open source and get out of this by increasing the number of retweets we are going to have on the story”.

One option however looks deceiving: raising capital. On the surface raising capital might look like a reasonable way to get out of a running-out-of-money situation. I believe that’s not the case. I would go further and say raising external capital has become an overgrown part of the startup life. It’s not the cure; it’s the cancer itself.

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma—which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice.

No matter what the latest article on HackerNews or your favorite VC’s blog post tells you, your aim should be to build a profitable and purposeful business. All the land-grab, moonshot, “reach for the Mars,” “you are the next Elon Musk,” “build the next unicorn” hoo-ha is self serving for the VCs who want you to raise loads of money and burn it fast so they can get a 10x return or stop wasting their time with you and turn over to the next entrepreneur.

It seems to me that we might have overestimated the role of external capital in building a business. Our industry’s over-reliance on VCs is absurd, unhealthy, and downright dangerous.

Let me be clear here, I am not against raising money to grow an existing successful model. I also acknowledge that some businesses can only be built at scale which requires external capital. But those are exceptions, not rules.

To be fair to VCs, I also need to clarify something: my issue is not with external capital coming from the VCs. It is with having too much cash in the bank. In most startups, this is either by raising money from a VC or by the virtue of having a rich founder. No matter where your money comes from, if it is not from your customers, you are harming your business by having it. Those zeros next to your bank balance take the focus away from what’s most important in your startup’s life. They will fool you into thinking you should be spending your day in upgrading your infrastructure or building your next awesome feature. Would you be doing that if you only had 6 months to live?

I find it ironic that while many might look for external capital as a way of getting out of deathbed, it is the cancer-like growth of venture capital in the startup business that’s causing a lot of those businesses be on deathbed in the first place. This constant demand for building more, capturing more, and grabbing market faster without solid foundations of a business, serves investors very well and that’s why they propagate it in the startup market so readily, but most of us started a business to live our own lives and not someone else’s. It feels to me that many of us are now in danger of living a VC’s life instead.

It is true that “If you live each day as if it was your last, someday you’ll most certainly be right.” It certainly applies to us mortals and while it doesn’t have to be true for businesses we build, living by it is the best thing we can do to stay hungry and focused, both for ourselves and our startups.

Quotes in this article are from the Commencement speech given by Steve Jobs at Stanford University in 2005. For many, Steve Jobs is the guy who brought smartphones to the world but for thousands of entrepreneurs around the world, he is the inspiration to take on the daunting challenges of building a business and creating something new from nothing.

I read this speech every year or two to remind myself why I do what I do and I know many others who do the same. I invite you to listen to his talk if you haven’t done so already.

I own a Smart car. It is Smart only in name, especially the "Multimedia System" that comes with it.

Every morning when I get into my car and start it, the multimedia system comes on and plays the radio. I don't listen to radio much but my smart car probably thinks it is good for my mental stimulation and cultural cohesion. I disagree with the car and want to listen to Spotify on my iPhone connected via Bluetooth. So I wait for the multimedia system to connect to my phone. This takes about 20 to 30 seconds.

Once it is connected, I go to the Menu, select Media, then Bluetooth. My car shows each page with a smooth visual transition as if choreographed by a movie director: each page fades out and the next one slides in from behind while fading in with vivid orange colors. Beautiful. It takes 3 seconds for each page to run this transition.

So now 40 seconds later I have gone through 3 pages of menus to get to Bluetooth. Once I press Bluetooth, the multimedia system starts playing the same song from my iTunes: a song that begins with letter A. Every time with no exceptions. I never listen to iTunes (or Apple Music or whatever it's called now). I listen to Spotify, and I had just listened to Spotify at home before I left to get into my car, so I expect that to carry on. But my smart car thinks Apple Music is better for me.

So we disagree again, I stop the first song on my phone, open Spotify and play my favorite playlist. Well, not so fast.

Since connecting to my phone, my multimedia system decided it wants to download all my phone contacts first, and since it has the CPU power of a calculator in the '80s, this takes a couple of minutes at least, during which everything on the multimedia system slows down to grind. This is slowed down even further by interjecting alerts that it has "Downloaded contacts" or "198 traffic incidents received". Why do I need to have my contacts on my car and why would I want to know that there are 198 traffic incidents in town that morning is beyond me, but my multimedia system thinks it's a useful piece of information. Perhaps I'm supposed to spot a trend in the number of traffic incidents in the city. I wait patiently for technology to be helpful in its own way.

So now, about 2 minutes after getting into my car, I am ready to listen to my favorite music and drive off to work. This is my daily dance with a bad product.

My car's multimedia system also uses a car icon instead of an arrow in the GPS navigation. Better still, it allows me to change the color of this car icon. I have a choice of about 42 different icons of Smart cars with different models and colors to choose from. I never change that, of course, but my children love that feature. The first thing they do when they are in the car is to choose the color of the car icon for the day. I don't mind the feature. Its uselessness and its appeal to 10 year olds who clearly are not the primary users of a driving navigation system is puzzling, but hey, what's the harm?

Do they actually ever drive their own cars or they just love listening to radio every morning? Because there is no other way not to notice the issue with this daily dance of technology.

As a customer and user of this multimedia system I am not annoyed by the complexity of the UI as much as the daily inconvenience I have to face every day, however minor they might be. Inconveniences like this add up to frustration while configurability of a GPS navigation icon is just silly.

Many product startups know the value of minimalism and "doing less." They focus on doing fewer things and doing them well. Asking for a new feature from many of them is most likely going to get a "no" answer, and for all the right reasons. I, however, think that customer churn is not caused by silly or unwanted features. Even edge-case missing features are not a big factor in customer churn: it is these daily inconveniences that contribute to churn the most.

As a product designer, you need to be able to see your product with a fresh pair of eyes and see if often and regularly. You need to be the primary and first user of your own product and notice how you work around inconveniences caused by bad design or poor quality in your product without getting used to or blind to it.

If those who designed my car multimedia system used it every day themselves, I wasn't going to look for CarPlay in my next car. I not going to buy a car because it's called Smart. I would buy a car called Dumb as long as its designers are smart.

This post was first published here

Getting old doesn’t have many upsides. But if you are my age, there is one good thing about getting older: You remember the happy days of 1999. The internet was new, content was everywhere, and the future looked bright. AltaVista and Excite ruled the world of portals, and “eyeballs” were the most prized commodity. In pursue of getting more visitors, dot-com companies would give you a lot of stuff for free as a “user.”

Sadly those days are gone (alongside my youth). Now running up four flights of stairs is not an option, VCs are more prudent, and users are more savvy -- all for the better, I would say. Well, that’s what I thought until I sat down with John, the young and clever founder of a developer-focused product.

John and his co-founder had poured their heart and soul into building an impressive product that can be used by IT teams in larger enterprises and were looking for investment to take it to the next level. Naturally, we went through the team, product, and technology. It was going so well that I was starting to think this might be it -- until I asked about their go to market

How were they going to sell their product? “We are going to open-source it,” John told me confidently and casually. His conviction in his answer was so strong that I cycled through three or four emotions and arrived at self-doubt in a couple of seconds. Did he know something I didn’t? Was open source actually the way to go to market with a product like this?

The truth is this is not an isolated incident. Everyday, talented engineers start companies and release their IP as open source in their insatiable thirst for developer mind share and adoption. Many times it works: They get more stars on their GitHub repositories than you need to make everyone in San Francisco an army general. My question however: Where is the business?

Open source is often pitched as the only way to sell software to the enterprise of today. The argument goes that since developers use what they like and not what they are told in their projects, they have become the kingmakers of IT enterprise. Get them all and get them soon, and you shall rule the world. Developers don’t love anything more than an open source product where they can look under the hood and tinker.

While all of those arguments are true, I am still looking for financially successful open source companies that can be reproduced. Looking around, Red Hat is the only company that makes money from its core open source offering. All other “success stories” of the open source world from 10gen (MongoDB) to Docker either make money by selling closed source tools or are still to show a viable revenue worthy of their billion-dollar valuations.

To be clear, while I agree that open source is a very effective and low-cost option to enter the enterprise, I also think it is not the way to build a software business without a plan. You simply cannot build a business around a highly popular open source project without having a clear plan on monetization.

All these are important questions that you need to answer before changing the type of your GitHub repository from Private to Public and enjoy those starts, forks, and pull requests.

I worry that GitHub stars have become the new eyeballs, and I fear this one might not end well like the last one I remember.

If you've been part of any startup accelerator or have talked to a "startup mentor" you know how obsessed most of them can be with the elevator pitch i.e. the ability to explain your idea or business during a short elevator ride. During my time working at startups, I've heard different versions of this ranging from the beer mat pitch (a pitch that can be written on a beer mat and explained to a fellow drinker at the bar) to the grandma (or granny to my fellow Brits) pitch, which is describing your business in terms your grandma would understand.

I've always disagreed with these notions and at this point in my life, having founded several companies and running Cloud 66 for about 4 years, I'm pretty sure I'm right. The elevator pitch is useless, the beer mat pitch is a waste of time, and grandma's pitch is just plain old stupid.

Elevator pitch issues relate to two areas: context and goal.

To illustrate my point, allow me to introduce you to Paul. Paul is a Professor of Applied Mathematics at UC Berkeley. I'm sure you know what it means to be an Applied Mathematics professor. I wouldn't be surprised if you assumed he must be a good professor, since he teaches at a university like UC Berkeley. You might even be able to accurately guess his age and even picture his appearance in your mind.

This is because you have a great deal of context and an existing pattern in your mind about what Paul does. You know what Applied Mathematics is. You know what a university is and what being a professor means. You know UC Berkeley is a good university and might know it has a particularly good Applied Mathematics faculty.

Now imagine you didn't know any of this. Let's see how he'll fare pitching his work in an elevator:

Me: So, Paul. What do you do?
Paul: I'm a professor of Applied Mathematics at UC Berkeley.
Me: [looking confused]. Hmmm.... I know what mathematics is. But what's applied mathematics?
Paul: It's the practice of finding uses of mathematics in science, engineering, business, computer science, and industry.
Me: Right. I think I have an idea. So what's UC Berkeley?
Paul: Erm.... It's a university in Berkeley, California.
Me: University, eh? What do you do there?
Paul: I'm a professor.
Me: What's a professor?
Paul: [murmurs something] ... I help people gain a better understanding of the world by providing them with regular lectures and introduce them to instructional books.
Me: Ah! Now I get it! Like a school teacher, right? But what's your USP? Why not just call yourself a teacher instead?

At this point, we've ran out of beer mats, grandma is snoozing on her rocking chair, and the elevator has reached the roof garden and people are waiting for us to leave so they can get in.

But while it's difficult to think of someone who doesn't know what a university or professor are, it's completely plausible to imagine the same assumptions being impossible if Paul was pitching a cold laser surgical scalpel for retina surgery. In this scenario, it's not hard to imagine me asking him, what's a cold laser? What's retina surgery? Why cold? Is there a warm one? What's the USP? How is this different from any other scalpel?

The problem is, many startups work in cutting edge science and technology fields. Fields that inherently have few people with insights into them. That's the exact reason they can build something new: Because they know something others don't. The context is seldom as commonly shared for those types of companies. As a result, elevator pitches for startups have evolved to take on 3 different guises:

1. Useless or meaningless: "We help companies turn into social enterprises"
2. Incomprehensible: "We reduce tissue damage by using flexible fibre CO2 lasers"
3. Relative: "We're the Airbnb for washing machines"

You can see how only the third one is useful in communicating something meaningful, because it benefits from a shared context. I know what Airbnb and washing machines are. Frankly this isn't unique or a particularly new insight. This is what communication is. This is what we humans do when we communicate: start from a common ground and build new pieces on top of it.

It's often said that the aim of an elevator pitch is to get the other side to ask intelligent questions and guide them through the course of understanding your business. While I agree that this is a method to engage people, the goal of an elevator pitch for a startup isn't to be a conversational piece. It's to go get investment, form a partnership, or sell a product -- not start a conversation.

Given the goal, it's justified to ask a simple question: "How likely is it to get investment from someone who doesn't even have a contextual understanding of your field? How useful is that investment going to be? And how likely is it to sell your cold laser scalpel to a removal van driver?"

While it's possible for those conversations to turn into a business transaction, it's not the most optimized way of approaching a business deal. The scarcest thing in a startup is time. Waste your time and you'll watch your startup die. It's the same thing.

But not all startups specialize in cold laser scalpels. A dating website, an online cookery school or a mobile gaming app startup can benefit from elevator pitches, precisely for the reason that people will share their context with you. But if you're building a business on new frontiers, solving hard or novel problems -- what Sam Altman called Hard Tech Startups -- elevator, beer mat, or grandma pitches are as efficient as advertising lease time of the Large Hadron Collider on TV during prime time Saturday night viewing. It might work, but it's quite likely not to.

So do your homework. Find relevant investors and business partners who don't need priming about your business. You have a short elevator ride. Don't waste it on context.

Our office in San Francisco has communal bathroom facilities, which like other communal areas, gets thoroughly cleaned every morning. But everyday around 5pm, if you go to the men's restrooms you’re usually confronted with a pool of urine right in front of the urinals.

This is obviously not a pleasant experience for anyone, including those who contribute to the aforementioned pool of fluids. So it got me thinking: Why does this happen? And why would you not stand just that little bit closer to the porcelain to avoid pool formations by the end of the day?

I couldn't really think of a reason, but I thought of a solution: Printing a sign and attaching it at eye level that reads: You’re not as big as you think, please step closer!

I think most of what we’re told is true: Google is indeed light years ahead of many others in running infrastructure. I also have no reason to believe Google hasn’t been using containers in production, nor do I think systems like Borg don't exist.

I would, however, question two things: Kubernetes was built by Google to make us benefit from their expertise in running containers and that everyone is better off running infrastructure like Google.

The truth is, Google is unique. With all the talk about unicorns and the next Google and Facebook, the likelihood of your startup making it to unicorn league, let alone becoming the next Google is less than being hit by lightning, while eating an ice cream as you're swimming away from a shark attack during The X Factor final.

But wait, doesn't Google use PwC and Merrill Lynch, and isn't Eric Schmidt part of the furniture at Davos? So why wouldn’t you do the same?

The answer is simple; those services are built for Google size. You don't find a company saying GAFEE (Google Accounting For Everyone Else). That would be ridiculously absurd, and we all know that. Interestingly, Google's accounts are more likely to look like a normal multinational than their infrastructure. I can think of at least a dozen companies that have the same accounting practices as Google: Unilever, Procter and Gamble, Glaxo Smith Klein, Volkswagen, Exxon Mobile, British Petroleum ... but none of them are anything like Google in terms of infrastructure sophistication, and we can imagine why.

“So what's the problem,” you might ask? "OK, we get the point, we’re not as big as Google and we don't use Google's accountants because their practices don't apply to us (or are too expensive).”

“But what's wrong with using Google's infrastructure when they’re giving it to us for free?" I hear you say.

In reality, it's not all about the nominal price. Getting Merrill Lynch to do your banking. even if it’s for free, might not be a good idea for your company because of the burden it puts on you and your admin department. The situation would be akin to taking a Formula One car to do the school run at best.

The issue is, by using tools that aren’t built for your goals, size. and achievable targets, you’ll be burdening your business with unnecessary complications that can be avoided both now and in the future. As software engineers, we’re familiar with Donald Knuth’s saying: premature optimization is the root of all evil.

Why does Google promote tools like Kubernetes? Google's promotion of containers is a lot about taking on Amazon. In short, Google has no way to take on AWS in their game of compute, network and storage -- the traditional blocks of cloud computing. But they have a lot of experience in running infrastructure that doesn't provide those traditional components since they’re using containers. By promoting containers as the building blocks of infrastructure, they’re hoping to leapfrog over Amazon to become the infrastructure setup of the future. Their advertisement campaign for Google Cloud Engine also points to this goal.

By using tools that aren’t right for our size, we run the risk of contributing to and stepping in a pool of urine as the day draws to an end. It’s not only harmful technically, the administrative costs can also quickly become a burden. As a start-up, we all want to believe we’re destined for greatness as the next big thing. Mentally, chasing after an aspiration to become the next unicorn makes us into an unsustainable business, addicted to where the next round of funding is coming from. We see this everyday in Silicon Valley, and trying to imitate Google’s infrastructure is just one aspect of this mentality.

And if all else fails, it's always useful to have a cautionary sign in front of us as a reminder: You’re not as big as you think you are, please step closer!

Coming out of a London Underground station these days means getting bombarded with a deluge of freebies ranging from drink samples to a couple of months of free gym memberships.

We've become accustomed to free samples given to us by marketers, even when (in the case of the free gym membership) we know this act of benevolence has nothing in the slightest to do with improving the health of society. Anyone's who's tried to cancel a gym membership post-trial will know exactly what I mean. No organization that cares for your mental health and well-being would treat you like that when attempting to terminate a contract!

But staying on the good side of marketing, there are similar patterns in the software industry: demos, trial accounts, free and "freemium" products.

It's all fair play. No one claims altruism, no higher moral ground. It's just transactional business.

However things aren't as straightforward in the open source world. The fact that many vendors boldly profess their love for "community" and "giving back" onstage at trade shows, while every other bit of their business is just as profit-driven as the burger joint next door, is hypocritical to say the least.

Frankly I have no issue with using open source as a way of getting more software users, letting them experiment with it before buying. I don't even have much trouble sifting through the marketing BS behind a vendor's altruistic motives. It's all fine. We're a sophisticated enough bunch to get it after all.

Yet I do think we need to stop seeing all open source as the same. We need to start differentiating between open source that has a higher aim of making everyone's life better, giving back or building communities, from the type of open source that's purely there to be used as a marketing tool.

Open source is something that's built, governed, and run by a community of people with no single vendor sponsoring the project. Open Trial is a project with almost all of its contributors on a single company's payroll, where the sponsoring vendor makes money by selling support (read: compensation for bad documentation) or the "enterprise" (read: usable) version of the software.

But why should we care what it's called? The reality is, when you look around, no new startup cuts checks to Oracle or EMC anymore. Facebook runs on MySQL and PHP, not Oracle and ASP (or whatever closed source web development framework is still around), and this doesn't paint a rosy future for these giant companies of our industry.

Decisions about fundamental tools used in a stack are made by developers during the early days of a company's evolution and most are stuck with those choices -- be it good or bad. This is great news for us software developers. We get to make our decisions purely on technical merit. The question I'd like to ask is, Are we equipped with making the right business decisions when it comes to our choice of tools? Knowing what we're dealing with when using open source can only make answering this question easier.

The importance of how we answer this question becomes clearer when you think about how an open source project is governed? How is it building, keeping, and distributing IP within its product and community? What levers does it use to move you from the community edition to the enterprise one? Calling them for what they are (open trial or open source) makes things easier.

An open source project is about community. I'm happy to use it, fix it, contribute to it, and benefit from its openness. On the other hand, my approach toward an open trial project is going to be different. If the main IP is going to be kept closed and paid for, my contribution to the project is going to have different beneficiaries and therefore might affect my decisions.

Same goes with understanding where a project is heading (i.e. its road map). Open source projects have transparent governing bodies for the most part. An open trial project is usually completely different: the commercial decisions dictate its future. Sometimes these decisions are made behind a pretense of transparency and multi-vendor governing bodies, but the reality is often very different. Don't get me wrong, there's nothing wrong with this either. As I said, it's all about knowing the score so we can make more informed decisions.

There's danger in misrepresenting open trial as open source. I believe it can lead to bad business decisions by the consumer (developers), which in the long run will hurt not only developers but the vendors themselves.