Skip to content

Thoughts on a freemium software product

At FusionAuth, we have a free software product that is a critical part of our business model.

A free product is pretty common in the software space because of two things:

  • Software needs to be used to determine its efficacy; a software package is not like a shovel. With a free option, money is no longer a barrier (though time is).
  • Software has zero marginal cost; once you put the effort in to build the first copy, you can create 1M copies for essentially the same cost.

However, supporting a free software product sure isn’t free. This post covers what you need to think about in terms of investing in a free product.

If FusionAuth were a public company, this is where there’d be lawyerese talking about forward looking statements and safe harbors and whatnot. Suffice it to say that this entire post is my personal opinion.

Side note: a free product is often but not always open source. Free can mean a tier of a SaaS, an open source project, or a downloadable product. Open source has additional complexities, so I’m going to focus on products that are “free as in beer” in this post. FusionAuth has a downloadable product that devs can run for free, within constraints.

We have internal discussions about tweaking the free version of the product. Options include:

  • Keeping the product as-is, but making investments in the community version. This includes bug fixes and feature improvements. Since our free product is production ready and feature rich, this is a solid choice.
  • Improving the free product. There are multiple dimensions to doing so, including:
    • Improving discoverability of the free option, such as highlighting it more on the website, advertising it, or investing in additional documentation around its features and usage.
    • Changing the license to make it usable across a greater number of use cases or with different limits.
    • Move features currently restricted to paid plans to the free product.
  • Degrading or limiting the free product. These are basically the flip side of improving it:
    • Increasing friction to find or use it.
    • Modifying the license to prohibit currently allowed use cases.
    • Clawing back features from the free plan, focusing on features useful to businesses who are likely to pay. For example, the free plan currently allows unlimited SAML connections, which many competitors throttle.

For the foreseeable future, we are following the first path, improving the free product. The free product is usable and robust, and we get substantial benefits from the community’s usage.

Let’s dig into these benefits.

The value of the free users

First, if developers are using our free software to solve their authentication needs, they aren’t using someone else’s. While you can’t pay a mortgage with developer attention, that doesn’t mean it has no value. Such attention expands our mindshare and market share. More mindshare means that people are learning about our solution. Gaining market share means they aren’t using someone else’s solution. Therefore they are neither paying a competitor money nor getting more familiar with their solution.

Second, such users spread the word about our solution. Sometimes they talk about it on social channels and sometimes on a review site. But often it is prompted by us; here is an example of one of my favorite set of blog posts, entirely drawn from community experiences. Talking to community members has opened up my eyes to the wide variety of ways our product is used. Community stories are not, however, useful as case studies for the sales process. They aren’t detailed enough. But they are still helpful to spread the word about the product, highlight our community members and catch long tail keywords.

Third, free users improve FusionAuth. They do this by:

  • Finding flaws in FusionAuth, such as bugs or regressions. Here’s an example issue, including workarounds.
  • Requesting new features. We leverage the community further by asking users to upvote such requests so we know what the community wants from the product.
  • Exercising the software by performing integrations that we would never have done. This is a variant on finding bugs. For example, a free user reported we aren’t to spec with regards to the SAML relay state; that’s never been an issue for the existing SAML integrations.

Finally, free users also offer each other support. While not all community members are active all the time (our community is more of a Google than a Facebook), a few have a presence on our forum, slack and GitHub issues.

The conversion of free users to paid users

Free users may purchase the software in the future. Once someone needs paid features, they may stop using the free plan and buy. We’ve built up trust as a solid solution in their mind and they have already integrated us. So a free user will consider paying you when they are looking to purchase.

Of course, you need  a product worth paying for above and beyond your free offering. At FusionAuth, we accomplish this in three dimensions:

  • Operating the product. Many of our customers are fine with the features of the free plan but don’t mind paying us to run it. This can include service level agreements (SLAs) as well, which are like catnip for enterprises.
  • Paid features. These are either features good when you are at a certain size (like SCIM) or enhancements of features available in the free tier, such as a more customizable registration form or MFA policy. Choosing the features to charge for is critical, but is really hard to get good data for since it is very business specific.
  • Support. Knowing you can ask questions of the engineers behind the product is valuable, especially for larger businesses.

There are two ways for free users to convert.

They can do it directly, where they use the free version to evaluate or run a “proof of concept” to ensure that our product meets their needs before they ever engage with us. We have plenty of customers who say “we’re already a few months into integrating with you” on our purchase kickoff call, and that ability to “get going” with the product without talking to a sales rep or pulling out a credit card makes the decision easier. Again, they trust the solution will solve their problem. They can also see how the company treats the free users and the community in general too.

There are also people who “kick the tires” with the free product and discover that it doesn’t meet their needs. We don’t hear about as many of those, but I have talked to a few. In this case, both parties win; getting to a quick no is not as good as a “yes” but is still pretty good. There are also people who do a self-led POC and incorrectly determine it isn’t a fit. They might miss features through lack of docs or a conceptual mismatch. We keep trying to improve our docs, education and product, but you can’t win them all!

There’s also an indirect conversion path, alluded to in the above mindshare point. Free users may use our software on a side project or to learn about authentication and OAuth in general. This lets them add FusionAuth to their toolkit. Then, later, perhaps years later, they can bring us into a project as an option to evaluate or to recommend us for purchase.

In general, free products let you build trust and de-risk purchases.

Keeping up with the Joneses, err the competition

Finally, competition matters. Lots of our competitors have a free offering. Again, this is due to the nature of software. Yay to zero marginal cost!

This is also compounded by the nature of developer tools. Devs are looking for tools to solve a problem, but once they’ve integrated one, it sticks around. One time I picked a bug tracking system in a few days (phpbt, what what!) and it was used at our company for years. This means if you have a friction free evaluation process, you stand a good chance of being embedded.

Offering a free product matters for our market positioning.

Nothing sells quite like free.

In conclusion

When you make a free product available, you are offering users something of value. Resources are scarce, and supporting the free product isn’t free.

Determining how much time and effort to expend supporting it depends on the value your company gains. You won’t always be able to calculate it in dollars and cents, but it exists nonetheless.

Books and other resources to level up as a software developer

A while ago there was an HN post asking for suggestions on [r]eading material on how to be a better software engineer.

Here’s my list based in part off a comment I made there.

First, books:

  • Secrets of Consulting by Gerald Weinberg because every problem is a people problem.
  • Refactoring by Martin Fowler et. al. discusses how and why to refactor, as well as providing a nomenclature for the process.
  • Code Complete by Steve McConnell is a bit dated (the last version I could find was from 2004) but a great overview of the entire software process, from requirements to maintenance.
  • The Mythical Man-Month by Fred Brookes covers best practices about software development, written about a project from the 1960 and 1970s. Nothing new under the sun.
  • The Joel On Software Strategy Letters cover different aspects of software strategy. The link is the first one, but all of them (I think there are five) are great.
  • Letters to a New Developer is a collection of essays helpful to new developers. Note I wrote this book, but I think it does a good job of discussing the “soft skills” in an easily digestible format.
  • The Pragmatic Programmer by Dave Thomas and Andy Hunt. I haven’t read the revised 20th anniversary edition, but the first one opened my eyes to the craft of software.
  • High Output Management by Andy Grove illustrates how think about throughput.
  • The Phoenix Project by Gene Kim et. al. is a fun novel(!) about applying lean management principles to software engineering.
  • Good to Great by Jim Collins focuses on what great companies bring to the table. Helps me evaluate where to work.
  • Managing Humans by Michael Lopp. The whole Rands site is worth reading, but I enjoyed this book about how to manage teams and build software. See above.
  • Don’t Make Me Think by Steve Krug shows ways to think about usability, focusing on webapps. Short and easy.
  • Badass: Making Users Awesome, by Kathy Sierra helps you put yourself in the shoes of your users and think about how to build software they will love. Short and easy.

Then, podcasts and videos:

  • Mastery Autonomy and Purpose, a great video about what people really want in work.
  • The Manager’s Toolbox podcast, focuses on nuts and bolts skills for managing people. You didn’t say you wanted to be a people manager, but knowing what managers think about will make you more effective in any org.
  • Screaming in the Cloud is useful for keeping up with AWS and other cloud provider offerings.
  • SE Radio is a bit dry, but has a great back catalog of software engineering focused episodes.

A few other resources:

  • The Rands Leadership Slack has over 10,000 engineering leaders discussing all kinds of software related topics.
  • CTO lunches is an email list of engineering leaders. The discussions aren’t consistent, but when they happen, they’re great. Plus, it comes to your email.
  • HackerNews is a great way to burn time, but also a great way to keep on top of topics that are top of mind of some of the best developers in the world.

Reading up on software practices can help you level up as a software engineer because you’ll be able to avoid mistakes others have made before you. I can also offer a view of the big picture; knowing how your software helps your organization or company will only make you more valuable as a developer.

Management is not leadership, leadership is not management

I’ve been a leader in one way or another through much of my career, and I’ve also been a manager of teams as well. Management is, in my experience, focused on organizational goals. It’s hierarchical. you need to manage up, but also take care of those who are below you.

Leadership, in contrast, is focused on personal goals. In some cases they may be related to the organization’s goals, and in the workplace there should be significant overlap. But when you are leading, you are walking the fine line between taking people where you want them to go and finding out from them where they want to go. You aren’t commanding anyone and if you aren’t interested in the goal, you probably aren’t leading progress toward it. Leadership is nowhere near as hierarchical as management.

Here are two examples of leadership from my career.

Perl code formatting guidelines

I worked at a consulting company in the early 2000s and we wrote a lot of perl. If you’ve heard of perl, you might know it is often called a “write-only” language because there’s more than one way to express anything. I noticed that we were not standardizing our perl code across projects, and a lot of knowledge wasn’t being shared.

I mentioned this issue to my manager and said I wanted to write some coding standards. While I was a junior engineer, I worked with my manager and perl engineers. I wrote a preliminary draft, then shopped it around and got feedback from other team members. At the end of the day, I had a working document that all teams could live with and that would help us avoid silos of perl coding idioms.

Notice what this involved:

  • seeing a problem
  • working with others to scope it
  • putting a solution together
  • getting feedback

But it didn’t involve:

  • hiring
  • firing
  • giving feedback to anyone
  • coercion

Even though this task had aspects of management, in particular the coordination and communication, it wasn’t management. Instead, it was me picking a goal (“coding guidelines to share knowledge across teams”) and working toward it with others. In other words, leadership.

Hackfests

I have written before about hackfests, but they are one of my favorite things to introduce at a new company (I’m at three and counting).

With a hackfest, I want to foster communication across departments, have fun, and offer a chance to help folks poke their heads up out of their day-to-day.

In each of these companies, I talked about hackfests to both the senior management and other employees to build support. I adjusted specifics about the hackfest (frequency, length, topics, format) based on the feedback. At most of these companies, I was one of the more senior technical employees, but I still built support for the event.

I also scheduled it and did some of the grunt work that goes along with any event, including educating folks on what the point was, emceeing the presentations, following up to get it on the calendar regularly and more. I even occasionally “rang the gong” when my bosses’ presentations ran long.

Fostering leadership

So, should you want to foster leadership within your team and organization? This seems like a no-brainer, but I still find it helpful to examine why.

Leadership, in the form of picking a goal, organizing work around it and delivering it, is critical to scaling an organization for so many reasons:

  • Lets people work together toward a goal without a “manager” around to give them instructions.
  • Is training wheels for management, but can be done by people who are not managers.
  • Can be “tried on” easily. It’s easy for someone to be a leader for one project or aspect of a problem and not others.
  • Pushes decision making closer to people confronting problems.
  • Builds a scalable culture.

You can foster leadership in your team or organization by:

  • Allowing for autonomy and space. It’s easiest to be a leader for a task you care about, but even the most passionate person can’t lead if they are overclocked in the day to day.
  • Encourage communication between teams and employees. Collaboration often offers areas for “bite-sized leadership” opportunities.
  • When someone steps up and takes a leadership role, don’t hand it off and forget. Check in and follow up. Delivery is a key part of leadership, as is accountability.

Just make sure that the projects that are chosen are at the intersection of the desire of the leader and the needs of the organization.

Advice for finding a technical co-founder

So, you’re a non-technical founder. You have a great business idea. You have some market validation.

You’re ready to find a technical co-founder who can help build out your startup. You’ll need some coding done, and you imagine there are a whole host of other technical things that need doing. You want a partner who can help you.

You start looking and realize a few things:

  1. Anyone you pick is going to have a huge role in the success or failure of your business.
  2. You don’t have many developers in your network.
  3. It is hard to find technical people willing to work for equity in your unproven startup.
  4. Any time you post looking for a technologist co-founder, agencies (many offshore) respond, happy to help for $$.

I have had the “how can I find a technical co-founder” conversation a few times in the last week so wanted to share my perspective. This is based on my observations and reading, as well as having been a founder (two times, one successful) and early stage employee or contractor multiple times.

Where are you trying to get

Knowing this is important, as it affects the rest of your search.

Are you trying to get to an MVP you can raise money on? A partner you can work with for a long time (if so, consider the 5 Cs)? An application you can sell to someone? A refinement of your current vision which may have technical uncertainties? Advice if what you are trying to build is possible? A technical network so you can hire quickly?

All of these are valid answers, but different ones shift where you look.

It could be because of who I am rather than indicative of the larger need, but most of the folks I’ve talked to really don’t need a CTO. They need a founding engineer. I wrote about the difference between the two; the latter may grow into the former.

What do you have

You also need to get clear on what you have. The people I talk with often have the following situation:

  • no money (raised or in savings)
  • no tech skills/network
  • an interesting idea
  • a no-code or partially coded solution proving out part of their vision
  • some level of market validation

If you aren’t in a similar spot, you can read the rest of this post with some skepticism. Immediately below I give advice on what to do if this doesn’t apply to you.

If you have money, it’s easy: hire someone.

If you have a network, reach out to that network. Most people are happy to help. It won’t guarantee you a partner, but it can lead you down the path.

If you don’t have an interesting idea, well, you’re in trouble. That’s one of the key things you can bring to the table to interest a tech co-founder.

If you haven’t proven out some aspect of your idea with the tools you have at hand, that’s worrisome. Why not?

What can you offer

Being realistic about what you have means you can be realistic about what you can offer.

Here’s a fact: right now, technically competent people can be hired by companies willing to pay them money pretty quickly.

The idea that you are so passionate about that you’ve quit your job or are working on it full time off hours (if not, that’s a serious red flag to any developer)? That idea is exciting and unique for you, but it is one of many ideas the developer has heard about from passionate would be founders. In addition to not being bought in to your vision, technical talent has the following other considerations:

  • there is significant opportunity cost to joining a startup for equity only. It depends on market and experience, but call it a net swing of -$150k/year ($100k in foregone salary and $50k of debt/savings drawdown for living expenses). Yes, you might raise money, but will you pay market salaries to a co-founder then?
  • the risk is front loaded. I know tech folks who joined a startup, worked their butts off to build something, only to discover that their partners were unable to market or sell what they’d built. Whoops! That was a waste.

So, how can you mitigate those risks?

Don’t stint with the equity. Double digits for sure. Make sure to leave some aside for dilution and/or an employee pool.

In fact, thinking intelligently about equity is a subset of something else you should offer: understanding the business. The Nolo books are great for the fundamentals of business, but you should also understand the domain. If you’ve thought deeply about the domain and the business, you will stand out from the “idea folks” who just have, well, ideas.

Be flexible on working arrangements. In one situation where I was the tech co-founder, I worked full time on the company for the first four months, then half time after that because I contracted to pay the bills. Bring finances up in your initial discussions. Be honest and upfront about living expenses and how everyone has different needs. This will filter out some folks, but that’s ok. Better to do that early.

Push forward on your own. You can get a long way with no-code tools and manual processes. This is a grind, but a tech founder will be impressed by this effort if you get results. If you don’t get results, that might be the market telling you something. You can also start an accountability email list for $0 to share your progress.

You may even decide you want to code. Depending on the complexity of your idea, it may be possible for you to build something using free resources. Or buy a book–you are going to invest years of your life, so buying an intro book on coding is cheap. I’d suggest the Rails Tutorial if you are building a webapp.

I, and other devs, judge non technical founders by their ability to get sh*t done. Show that you can.

Know who you are looking for

Based on where you are trying to get and what you have to offer, you should be able to narrow down who you are looking for. Think about the following factors:

  • risk tolerance, including emotional and financial
  • experience
  • domain expertise
  • personal chemistry (you are going to be spending a lot of time with this person, they’ll know your triumphs and low points like no one else)

Write this down. It’s the start of your job description. You should flesh it out with your vision, experience, and what you’ve accomplished so far.

You want a written job desc because you’ll want to share it with anyone who is interested in helping. That’s the first thing I ask for. Put the job desc at at a URL. It doesn’t need to be fancy, a public google doc is fine.

This lets people easily help by sharing the job with anyone or any group they might think a potential co-founder frequents.

Where to look

Share that job desc with your network. You never know who may know someone.

Tech folks congregate in groups. This is often in a slack. Google for “<your area> tech slack” and you should be able to find something. Join, but watch for a while before posting your job desc. There may be certain channels where it is appropriate. And you’ll get more response if you aren’t a “drive by” poster.

There are also meetups. Google for “<your area> tech meetup”. Again, these are communities, not bulletin boards. Be prepared to join and interact for a while before making any pitches. Could be months.

Angellist is a good site on which to create a company listing and post your jobs. They have an email that goes out to interested folks. That’s how I first made contact with one of my co-founders.

Another option is targeted outreach. Tech folks, as mentioned above, congregate in online communities. They often comment. You can search for comments related to your idea/business and see who is talking about it. They may have contact info in their profile.

For instance, I had someone reach out to me because I’d commented several times about agriculture, and that was the domain of their business. This is a bigger time investment, but can lead to interesting connections. Reddit and Hacker News are good places to start. Doing this helps you build your tech network, because even if the commenter isn’t a fit for a co-founder position, they may pass along the job desc to someone else who is. They may also be interested in remaining in touch; if the company grows or their circumstances change, there may be a possible fit in the future.

When you find the person

Great, you think you have found a co-founder.

Have their skills validated by other technical people. You don’t have the knowledge or perspective to evaluate the co-founder. You are excited about possibly working with someone who can help make your dreams a reality. Sometimes an incubator can provide these advisors, other times your network. (As an aside, you should be trying to build your tech network. When you talk to someone who is helpful, see if you can add them to your startup accountability list.)

When people share equity in a business, it’s like getting married without the sex. Date first. See if there are a couple of projects you can work on before jumping in. Offer to pay them something for these, even if it isn’t full market rate.

Set up vesting for founder equity. Everyone should be on the same page if you are starting a true partnership. This will save you heartache if someone has a change of perspective or goals two years into the startup.

In general, plan for the worst, hope for the best. Discuss exits, future roles (do they want to build a team or continue to be an IC), co-founder departures, and long term vision. Do this even though the business model and organization is imaginary at this point. Having these conversations while everyone is excited about the company will make the inevitable tough times just a little less tough.

Make sure you discuss who will be in control. If you are partnering with a childhood friend, maybe 50-50 ownership will work. I’ve definitely seen it blow up because there’s a tension between the “owner” role and the “CEO” role, so even then I’d be hesitant. But if this is someone you just met, you should stay in control with more than 50% of the shares. Make that clear from the get-go so there is no confusion. That said, you aren’t partnering with this person to micro-manage them. Be clear about the areas they’ll have autonomy in.

I know I had issues with my lack of control when I co-founded companies, but that’s all the more reason to have that discussion earlier rather than later.

When it comes down to it, the technologist is crucial for many companies, but the non technical founder is even more critical. It’s a bit like the product and company is a racecar. The technical founder builds the car, but the CEO drives it. Both are important, but you can often find other car builders once the car is running (to mangle my metaphor a bit).

Conclusion

It’s going to be a long haul to find the right person for your startup.

It might be easier to try to raise some money to pay those ravenous agencies (I’ve worked there, so I can call them that) or hire a freelancer.

But the right co-founder will be someone you can trust, someone who will experience the depths and heights of startup life.

Best of luck finding them!

Open source software business model concerns in the age of the public cloud

A few years ago at Gluecon I was sitting at the lunch table with some new acquaintances. The talk turned to business models and someone mentioned the chilling effect of the public cloud providers on open source businesses. Companies whose main product was open source software (OSS) originally had a straightforward business model: sell support and consulting. (I’m leaving aside sponsorships, donations, dual licensing and other smaller streams of income. I’m focusing on what I’ve seen work to build larger, stable companies. If you are solopreneur you have a different set of options.)

This shifted over time to withholding certain features (the “open core” model) and licensing them to customers who wanted them. Open core was better for companies because it is more scalable and profitable to sell software than it is to sell labor (which is what support and consulting essentially are). Customers won because a certain set of them needed features that were likely not core to the software, such as single sign on or auditing, but were critical for their use cases. These customers tended to be businesses with money to spend. Open core, however, has some problems.

The fundamental one is “what should be OSS and what should be licensed” becomes a pressing question. Building a product is tough enough in general, but now there’s an additional marketing, product and engineering complexity.

The SaaS Business Model Cometh

With the rise of SaaS a third monetization option appeared: offer their software as a service and run it on behalf of their customers. NodeBB, ElasticSearch  and others all do this. The customer wins because they have a lower TCO and benefit from continual updates and the company wins because SaaS combines the margins of open core with recurring revenue. This has even caused some companies to move away from open core. The community remains satisfied because if they want, they can self-host.

Enter the cloud companies. Cloud companies could and did take open source projects, packaged them up and offered them as a service for a low monthly fee.

As a customer, and I’ve been such a customer many times, using an offering from these providers has definite benefits:

  • The cloud operators know how to run software at scale.
  • They are already part of the accounting infrastructure. There’s no additional procurement process.
  • They don’t typically deprecate software (killedbygoogle notwithstanding), so as a customer you are less worried ongoing support and availability.

Adoption by a cloud provider has benefits for the open source project, too.

  • It’s proof the software has reached a large level of customer demand, otherwise the big clouds wouldn’t bother.
  • Improvements to the software or documentation may be donated back.
  • It increases the number of folks who use the software or know about it.

However, those benefits may not balance out the loss or threat of loss of revenue from SaaS hosting. This was the chilling effect mentioned around that lunch table. When I read or ask folks about this issue, I’ve heard three separate proposed solutions:

  • Be better
  • You should be so lucky
  • Close your source or re-license

Be Better

First, as the prime mover behind the product, a company should be able to be better than the cloud operators. Not necessarily better at running all software, but better at running theirs. After all, they built it. This does assume that the best people to operate a service are the ones who built it. This may or may not be true. I think it is definitely true at a small scale–they are going to know which knobs to tweak, and if they run into an issue they can immediately fix it in the code base. As software gets more and more popular, the ability to run it well diffuses, however.

The company behind any project also should certainly have a better sense of customer needs and the ability to map those to its internal roadmap. Of course, being an open source project means that the advantages are fleeting. If anything is turned into code and released, it made available to competitors.

An even bigger issue is that this relies on customers being willing to stick with the company on the bleeding edge. For rapidly growing or changing software that may make sense. Where major functionality is being built regularly, upgrades are an easy sell. But OSS isn’t adopted by the cloud provider until it has a large audience, which means they are likely very functional for a lot of use cases. This means that the company won’t get as many folks on the upgrade train, which makes the “be better” argument more problematic. If the cloud provider can offer a “good enough” experience, then their other advantages start to dominate.

You Should Be So Lucky

This is the argument that the chances of an application becoming popular enough to be adopted by a public cloud are so low that it’s not worth spending time thinking about. I asked Steve O’Grady about the OSS business model predicament at a webinar once and this was his answer.

There’s a lot of merit to this. The biggest obstacle to an open source company succeeding is not anyone taking the software and running it, it’s the software not being useful or known. Obscurity has killed many a company, far more than AWS adopting their software.

But when a company reaches a certain size, this advice is less of a solution and more naming a strategic threat. Yes, they are lucky to have their solution be popular. But what can they actually do about the threat to what may be a sizable portion of their revenue? This argument doesn’t help with that.

Close Your Source

Depending on how the company developed the software, they could relicense or close source. This may require some prep work. First, make sure the software is all owned by the company; have all contributors assign over their copyrights. This will make it more difficult for you to reap some of the benefits of open source: easy contributions from others.

The company can also choose to relicense only certain portions of the codebase, taking a step towards open core. In any case, prepare to consult an IP lawyer.

The company must also be ready for the blowback from the community. Which hurts more, losing something that was once free or paying for something from the get-go? For me, it’s the former. Many of the marketing, engineering and product benefits gained from being open source will be lost; this is the price to pay for obviating the cloud vendor SaaS threat.

The firm could also dual license the software or use something like the Business Source License, which strikes a different balance, but still has some attributes of an open source license.

Alternatives

None of these sound very fun. I think the answer is to back up and consider whether to make a project open source initially. Consider this very carefully initially to avoid pain.

The benefits of open source for a business’ core offering are:

  • Lower friction of adoption
  • Contributions from outside an organization (these must be fostered, they may be free in terms of money but not time)
  • Increased rigorousness for the eng team (coding in public can make code better)
  • Easier to recruit because devs like working on open source
  • More eyes on the code means shallower bugs
  • Marketing halo

Are these worth the risk? I can’t answer that authoratively. If they are, another option might be to prepare for SaaS revenue cannibalization; this may mean going open core, focusing on consulting or support, or possibly never even building a SaaS solution.

There’s more than one way to be open. A company can do open development, inviting customers in to the product process. Would being more open with the development process (using public GitHub issues, for example, instead of an internal issue tracker) allow a company to get some level of contribution from outside the org? This would also imposes that “spotlight level rigor” on the eng team. Could the company make the software “free as in beer”, rather than “free as in speech” to lower adoption costs?

A firm can also release software as open source without taking any feedback from the community (“throw it over the wall”), which may be a good choice if the software isn’t core. Big companies do this every day. Facebook gladly open sources their computer plans and React, but certainly wouldn’t open source the core Facebook application.

In conclusion, if you are planning to build a company on an open source project, think about the main revenue flows for that company and what you’ll do in the unlikely, but hopeful, event the project succeeds.

Book Review: Am I Being Too Subtle?

I recently finished “Am I Being Too Subtle”, which is a business book by Sam Zell. He is an American businessman and real estate tycoon.

I quite enjoyed the book. We learn a bit about his parents and upbringing, and then he plunges right into the deals. Some of the details are great (he was able to complete a transaction once because he found out the owner of the property had buried a favorite dog in the backyard, and added a clause to the contract allowing the pet to be exhumed). He addresses his successes (helping professionalize the REIT market, selling the equity group, the loyalty of his employees) and his failures (the bankruptcy of the Tribune company in 2008).

The single biggest lesson that I took away was that to succeed you need to be looking in places that others aren’t and that eventually what worked for you will stop working and you’ll need to change. There are other pieces of wisdom in the book, and it’s less than 250 pages. A great fun read if you enjoy learning about business and deals.

The Challenger Sale

I just finished reading The Challenger Sale, a book about consultative selling. I really appreciated its data driven approach. The book, written in 2011, outlines a new approach to selling that is fundamentally about bringing the seller’s business knowledge to bear to provide value to the seller. But not just value, value in a way that is both striking (something new the customer hasn’t thought of before) and that emphasizes the product the seller has to offer. An example they give is Grainger, who sells parts. Grainger did research and determined that a large amount of the dollar spend with them was for unplanned part purchases, which can be expensive in both purchase price and staff time. They worked with customers to take advantage of their sprawling inventory to better plan parts purchases.

They cover the different kinds of sales techniques that their research uncovered, as well as tactics to help people adopt “challenger” traits to become more successful. They also cover how to sell this methodology to front line sales managers.

Two things really stood out for me. The first is that every company needs to answer why their customers should purchase from them, as opposed to anyone else. This can be a hard conversation to have because once you strip away all the “innovation” and “customer centricity” sometimes you aren’t left with much. I know that when I was a contractor, I would have had a hard time with this–my best answer would probably have been “I’m trusted, available, knowledgable and local”, which kinda sounds like a copout.

The other great part of the book was at the very end when they talked about how these techniques could be used for the “selling” of internal services (IT, HR, market research, R&D). I found that really interesting in the context of larger corporations where some of the functions aren’t valued for strategic insight, but rather are order takers from the business. I have in fact myself been an order taker. It’s easy, but not as fun as being part of the strategic conversation.

What is an MVP and why do you care?

I was recently published over on the Go Code Colorado blog. I wrote about what a minimum viable product (aka MVP) is. When I talked to teams at last years competition, one recurring theme was how much people wanted to spend time building rather than talking to users.

I have been there! I know it is much more fun to build something than it is to try to find people of whom to ask questions.

But it’s much better for the long term viability of your project to build something people want poorly than something no one wants perfectly.

More over at the Go Code Colorado blog.

Announcing: Letters to a New Developer

Blank paper, pencil, lightbulb, eraserI’ve been working on a new project that I’m excited to share here. It’s called Letters to a New Developer. It’s a blog with over forty posts full of advice for people who are just starting out in the field of development.

So much of development is not about code. It’s about teams and processes and organizations and questions. I feel like the traditional education system (whether four year college or bootcamp) does a good job of teaching folks coding fundamentals (what you need to be a programmer) but there is so much more to being a successful developer than coding. In my experience, delivering code is a necessary but not sufficient activity for success in a software company.

That’s why I’ve spent the last five months writing up some of my experiences and learnings.

The posts are mostly mine, but some are from guest posters who bring a different perspective. I also excerpt posts I find on the Internet that I find helpful, so that I can stand on the shoulders of some of the giants who have come before.

Here are some of my favorite Letters To a New Developer posts: Always Be Journaling from Brooke Kuhlmann, Get Used to Failure, and Learning to Read Code is More Important Than Learning to Write It.

I hope you find this project as fun to read as I’ve found it to write.

Ideas for marketing a dev centric product

I have a friend who has a company that produces a developer tool that provides a one stop shop for application authentication. It’s a good one and they’ve found some traction.

They are trying to follow the redhat/mongodb playbook–create a tool so good at solving developer problems that developers adopt it. Eventually some portion of enterprises will wake up one morning and realize that their developers are using this. The CIO will freak out and be happy to pay money to my friend’s company for support.

The question is, how do you get developers to find out about the solution and how it will make their lives better?

I am not a marketing guru, but I am a developer and have been involved in selling of software in the past, so I had some suggestions.

  • Read The New Kingmakers, by Stephen O’Grady, in particular “Courting the Developer Population” and “What to Do?”. You can get a PDF here. O’Grady has thought a lot about this problem and his blog is worth reading as well.
  • Find or create a community, and contribute to it. Depending on your audinence, this may be a reddit subforum, an old school php bbedit forum, a facebook group or even an IETF working group. An existing group is more likely to give you results, where a new group will give you more control. Aim for results.
  • Present case studies or testimonials of success using the software. How did a real person solve a real problem with your software?
  • If you can find analysts and/or bloggers focused in your problem space, contact them and offer to walk them through the solution. (To me, this seems more of a long shot, but could be a big hit if you find the right person.) Developer focused podcasts could be an option too, as long as you are talking about technology and the problem space, not your product.
  • Writing interesting content on your blog. Share it widely. Again, this doesn’t have to be about your product, in fact it shouldn’t. Instead, take topics you’ve learned by building your product, or in the communities of which you are part, or the problems developers have solved with your product, and highlight those topics.
  • Write talks for conferences. For developers, I’d look at conferences like gluecon and oscon. Meetups are good too–easier to get into but much less scalable. You attend virtual meetups as well as physical ones.
  • Set up a google alert for competitors’ names and keywords and see if you can add value to any discussions happening there.

Above all, don’t be salesy. Focus on making the developer’s life easy.