Party like it’s 1999

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.

Making a project open source is a one-way street in many respects: Once a project is open source it is almost impossible to make it closed source successfully again. Spending your money to build IP and making it available to everyone including your potential customers and competitors should also be a well-considered process: Which parts are going to be open source and which parts are closed source? How are you going to make money? Is it by selling services and support or by making your product “open trial,” while the actual “production worthy” and “enterprise ready” version is closed source? Are you building an ecosystem around your product, and if so, how are you going to nurture that without alienating other players in your ecosystem when you start making money from your open source IP?

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.

This post was first published here

Defining the 'open' in open source

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.

We're all beneficiaries of this method of marketing -- but more importantly, we know what's going on: I use your product for free in return for being targeted by your ads and then pay you when I use more than a certain limit or want to activate features. In exchange, I enrich your database with my usage patterns, and if I grow to love your product, I probably increase your sales by referring you to my friends.

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.

Not all open source is created equally. I'm even going to suggest calling them by different names. We can simply refer to them as Open Source and Open Trial to make sure no value is attached to either one or has negative connotations. Just clear labeling.

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.

"Our product is open source" is often exploited by vendors seeking to create positive sentiment. Exploiting open source for commercial reasons without offering full disclosure, transparency and complete understanding by its intended audience has the potential to get shrouded in negativity. So lets just call a spade a spade and help move the conversation forward.

This post was published first here