Evan Powell is a serial entrepreneur and served as founding CEO of three companies: Clarus Systems, Nexenta Systems, and StackStorm. Currently the CEO and chairman of Cloudbyte, Powell is also an advisor and investor in a number of startups, including Cloudian, Keewi, TextIQ, Journey Software, and others.
Powell delivered a talk, Innovating in the open: Lessons from a 3-time founder of successful open source-based businesses, at the Open Source Entrepreneur Network (OSEN) Symposium. In this interview, Powell discusses topics covered in his recent talk.
As a serial entrepreneur, what common patterns do you see in new companies when it comes to developing products and services?
Well, I'm most interested in what common patterns the really extraordinary companies share. Like others, I think a huge market—and it can be one that has not fully emerged yet—plus sustainable competitive advantages are crucial. The earlier the state of the company, though, the more we are forced to rely on an entrepreneur and the team she builds to find those advantages and to help create that market—so then you are looking at what makes an entrepreneur a great one. For my money, I'd say persistence and independence are the two most important traits. Intelligence is important as well.
How comfortable are new companies with the open source development model?
The default now is to build from open and in the open. So that's a positive. The downside is that by open source being the default, we may be getting a little lazy. If you remember back 5-10 years, open sourcing was a big deal, and it forced a level of rigor that may have led, in some cases, to founders and early investors taking better approaches to building their company—for example, shifting towards SaaS wherever possible, in part because of the ability to demonstrate clear value versus their own open source.
Open source is neither a product nor a community; it's a process. How do you explain open source to the companies that you mentor or advise?
Recently I've been using the concept of karma and the concept of code as marketing to help drive home good practices. Karma, of course, in the sense of doing the right thing simply because it is the right thing, and code as marketing because we do need marketing—and done right, code that engages the user base itself becomes a kind of participatory marketing that cements user support and advocacy.
How does this process of developing software in collaboration help new companies reach out to their customers faster? Is it low R&D, quick access to innovation, or less overload of managing the entire stack of their own software?
I think that of all these, the first point is the most important—reaching out to potential customers faster. You can get a sense of momentum going sometimes earlier in the evolution of a company just based on the community showing interest, which itself will generate more interest, well before your project is at the point that you would want it used in production by users. And that momentum is enormous for startups for a bunch of reasons, including market awareness, recruiting, team alignment, and fund raising. And of course, those fans can become sources of crucial product feedback.
What big challenges do you see where there is still a possibility that companies may go back to closed source software?
In some cases you will see closed development and open source continue to proliferation. This is especially the case where there is a sense that technical innovations will be quickly adopted by competitors and used to compete against the company developing the software. This model proliferates especially where the developing company is confident of their own technical superiority versus their community.
I'm not sure about just keeping the software closed forever. You see this sometimes, in the case of RBAC, for example, and other sensitive areas that are useful to put only into an enterprise edition (as we did with StackStorm). However, that's not a new class of problems, just a particular pressure point feature that is often kept closed.