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

materials.

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

strengths.

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

time.

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

learning.

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 away.

• 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 curve

• Moderate - Hands-on engineering assistance, implementing specific bits

• 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

us.

 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.