The global economy is changing to promote sharing, and free
software is an important part of that. How do we run a business
when important products are abundant and even free?
Long ago as cofounder of the shareware business model
for software, and then an engineer at a public supercomputing
center, I was lucky enough to be a part of this trend in its early
days. Then as a Microsoft executive, I worked on strictly
pay-to-use software, some of which that company now provides for
free. As CEO of FP Complete, I now spend large amounts of costly
staff time creating open-source code and free learning
How can companies like FP Complete give away work, and
still be a business?
The good news is we’re not crazy, nor are companies like Google,
Microsoft, IBM, Red Hat, and Amazon—all of whom give away software.
The Information Technology industry is moving to a model in which
plenty of core software is free, and companies make their living
with add-on software and services.
Functional Programming, Blockchain, FinTech, Cloud DevOps, and
Data Operations (DataOps): in each of our main lines of business,
companies are eager to adopt free open-source software like Haskell
or Docker for enormous productivity benefits. While some components
like Linux are very mature, others like Kubernetes are
cutting-edge, with serious changes showing up every few months.
Others like Rust or Haskell are in between: reasonably stable but
with a significant learning rate. The newer a technology is, the
more companies want help understanding it, getting around its
weaker spots, and getting the most out of its compelling
That’s where we do business. As an engineering consulting
company, FP Complete looks at the world as a series of chances to
help other companies—ideally giving away work that has mass appeal,
but selling work that’s focused and customized for paying clients.
The paid work subsidizes the free work, which we give away to
further grow the community, generating new adopters, a fraction of
whom will buy something. When it works, it’s a virtuous cycle.
How much to give away / open source?
Often our hardest decisions are on the border: what tools or
components do we reserve for our paying clients, and what do we
give away? A compelling example happened a few years ago, when our
Haskell engineering clients reported difficulty using a tool called
cabal. This multifaceted tool is maintained by volunteers
in the community, who had many different concerns in
mind—understandably not making a top priority of our clients’
needs, in the timeframe our clients required. So our clients paid
us to build another shared tool, called stack, which
suited their needs better and let them get their projects done on
At this point our clients had their solution, and we owned some
pretty attractive IP. Now should a tool like this be limited to our
clients, or licensed widely as a paid product, or given away?
Fortunately we had conducted (and published) a large-scale
survey of Haskell users worldwide, focusing on their practical
needs. By far their top complaint was the same one our commercial
users were facing, which they were calling “cabal hell.” (I’ve
learned that unlike free beer users, free software users are as
demanding and blunt as those who pay.)
We reasoned that fixing a top obstacle for all comers would let
more companies deploy Haskell, increasing our pool of potential
clients. Open-sourcing might also attract collaborators who could
improve the tool. So with our clients’ blessing we decided to spend
more, polish stack, and give it away as an open-source
contribution to the community.
This went better than expected. Far from being a niche
workaround, this tool was adopted by many commercial and
non-commercial Haskell users, and the complaints about “cabal hell”
reduced dramatically. The growth rate of commercial Haskell usage
increased, including some companies who have gone on to buy
training and engineering services from us. The cabal team
saw that users were finding this sort of thing handy, and they were
able to make big improvements to cabal, while other
volunteers have been adding to the stack project.
Now users have two productive open-source solutions to choose from,
another good sign of community growth, and between these various
efforts the lives of users were dramatically improved.
Helping the community and enhancing the free tools is good
for business, because it gets companies past their old
problems and lets them focus on getting work done—sometimes work
that we can help with. We need to be careful not to overdo it,
supporting the community wherever it’s willing to pick up the ball
and run forward, yet being there for our clients when they need
focused progress. That’s a constant balancing act, and we’re still
What to charge for?
The rule of the sharing economy is: the larger the audience, the
less you have to charge per user:
- If everyone needs a piece of work, try to give it
- If a few people/companies need a piece of work, try to
charge for it.
- If one company needs personalized or custom work,
definitely charge for it.
After all the free IP they can download, most engineering teams
still benefit from personalized, customized help. It speeds up the
work, and is cheaper than building an in-house expert on every
technology from scratch. Of course the more help they find
valuable, the more we can earn. The price reflects the amount of
custom help they get:
- Free - online information and code
- Cheap - One-on-one mentoring, getting them past the learning
- Moderate - Hands-on engineering assistance, implementing
- Midrange - Comprehensive code review, audit, QA
- Substantial - Implement parts of their code or DevOps,
augmenting their team
- Largest - Design and build a whole solution
We charge for high-value time focused directly on problems of
the client’s own choosing. Even though an hour of our time costs
more than an hour of their staff time, it’s backed by hundreds of
thousands of hours of cumulative experience and know-how, which
clients are willing to pay for.
A corollary to the sharing economy: you can charge for
specialized cases while you give away the base technology. For
every user that pays for enhancements or assistance, you might
expect 10 or 100 users to take and use just the free code or free
learning materials. If you can make the numbers work financially,
this can be a win for everyone.
A second corollary: by doing good work on free things, you earn
the respect to work on paid things. We have spent little on
marketing, because we build our reputation through our open-source
code, our free learning materials, and happy users referring
The sharing economy is here to stay
Sharing lets companies build their business through earned
respect, rather than just by making noise. That’s better for
the world, because it’s a true win-win.
We find that sharing is also better for our company culture.
People like to work at FP Complete because they can focus on
actually solving problems, every day. And new clients hear about
our work, and can even use our tools and lessons, before they
contact us. They know we focus on fast-moving, smart, practical
solutions, because we share our work.
My advice to any would-be open-source entrepreneur is this: jump
in, but be prepared. Open-source users are technically savvy, and
they expect excellent work. Don’t plan to be coddled just because
you come bearing gifts. Do expect to spend a lot on
serious, valuable community contributions. Remember it takes time
to build a reputation and the respect of a technical community.
This year marks the 34th anniversary of my entry into the
shareware industry, and this month marks the 7th anniversary of FP
Complete’s founding. The sharing approach works. Dozens of
companies have chosen to pay for our services, including over two
dozen in 2018 alone. We are grateful to them, and to the thousands
of engineers who use our code and our learning materials for free,
and to the tens of thousands of engineers whose open-source code we
use every day. We move forward together.
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.
Do you like this blog post and need help with DevOps, Rust or functional programming? Contact us.