Nebulous Profit Meditations

One of the questions we’ve received the most has been: “How are you going to make money?”

tl;dr

• We are going to charge for private stuff.
• We will continue to invest in improving the free stuff.
• Free stuff stays free.
• We have a very small limited beta program.

Read on for lots of reasoning and squishy philosophical bits that inform our choices on specific features.

Technology vs Product

For any tech company, the related concepts of “technology” and “product” are of critical importance. It is vital to separate these two ideas.

A “technology” is an application of knowledge for practical purposes. A “product” is a good or service that is created for consumption.

It is possible for a technology to be a product. However, these two ideas focus on different aspects of a thing. For me personally, “Objective C”, “Gorilla Glass”, “A7 Processor”, “multi-touch”, and “iOS” are all technologies. But “iPhone” and “Bejeweled” are products.

A product is something you’d buy. If you get a product for free, you’re at least aware that you’re getting something for free, because it exists in the product-world where we trade value in exchange for value.

A key differentiator to me is: How much do I have to understand in order to get value out of something? If I need a deep understanding of it, then it might be an incredibly useful piece of technology. However, it is not a product, because it does not reduce cognitive load.

Obviously this rubric is exceedingly fuzzy and subjective. What one person calls a product, another might call a technology, and there is a lot of overlap. For me, “wifi access” is a product. For others, “wifi” is an implementation technical detail of the product called “internet”.

Productizing a technology makes it more valuable to more people, and thus is an existential requirement for any technology company. It’s what technology companies do.

Pay

Technologies can be either free, or proprietary, and there are varying degrees along that spectrum. As anyone involved in software knows, there are many sorts of “freedom”, ranging from the freedom to see how a thing works (“open source”) to the freedom (or lack thereof) to restrict the freedom of others (patents, copyright, copy-left, etc.)

In a similar way, a product can have a price tag attached, or it can be “free as in beer”. Rarely does it make sense to say that a product is “free as in speech”. That is a designation that applies more to technologies than products, indicating that you have the right to use, distribute, and/or repurpose the tech as you see fit.

If you are paying for a product, then you’re the customer.

If you’re not the customer, you’re the product. [1] [2]

Buy vs Be

I think of this as the “Buy vs Be” dichotomy. In other words, do you want to buy the product, or will you instead be the product.

Frequently this dichotomy is used to disparage free services. However, it’s not so simple to say that it’s always bad to be a product. If you are in a position where the “sale” benefits you, then being the product might be great.

When we buy a product, we get upset if the price is too high, or if the quality is low. If the buyer/seller relationship is ongoing, then the trustworthiness and reliability of the seller becomes relevant.

When we ARE a product, we get upset if the sale doesn’t serve our needs. If the seller’s interests are unclear, or if they’re working at cross-purposes to our own, then there’s a good chance we’re being misled. If it’s too good to be true, it’s probably a lie.

Whether we buy the product or are the product, it is important that we have a degree of trust in the seller. If I am the product, who am I being sold to, and for what end? If I am buying the product, then what assurances do I have that it will be delivered as advertised? The strongest form of trust comes from mutually assured greed: I want to know that you are enticed to do what you promise.

In general, I am happy to be the product when the outcome is a mutually beneficial social interaction, and the information I’m sharing is essentially public. I have many free git repos on GitHub. I’ve met some of my best friends on Twitter. I have met romantic partners on dating sites and employers on job boards, and none of it cost me a penny. Being the product can be great when you want to share data openly within a community.

When I want a company to act as my agent in some delicate manner, however, it’s important to me that I have a financial relationship with them. I very much want to pay my bank, my lawyer, and my insurance company. They are doing sensitive things on my behalf. I want to know how they’re making money, because I’m sure that they are, somehow.

The business relationship sets up a situation where we judge each other against an established set of rules with specific recourse for bad behavior. I want them working for me, so that I can hold them accountable if they misbehave.

Paying for Secrets

The cases where it is most hazardous to be the product is when a service is the custodian of your secrets.

This puts Facebook and Google (among many others) in tricky positions, and it’s why they get the side-eye from so many of us so much of the time. It’s clear that we’re “paying” for those services with our ad-attention, but at the same time, they tend to house very important secrets that we’d rather not share.

The idea that they’d use those secrets to show us more targeted advertisements is somehow… unseemly. Even if it’s a robot doing the targeting, it’s not much of a jump to see how an advertiser might want to be able to correlate my search history, map locations, and email subjects. If I’m not paying for that data, then who is?

When something is private, we are interested in controlling how it is shared (/cc @TautologyFacts). But, if I’m the product, I’m unlikely to have the bargaining power required to expect to control the service that is managing the access to that information.

Up to this point, everything in npm has been 100% open source and public. That makes our secret-handling mechanisms very straightforward: we don’t have any. If you publish a module, it’s public, and global, and everyone can see it. (The only exception to this is login credentials. But keeping that secret is relatively cheap, and it’s table stakes for a working community.)

In the relatively near future, we will be releasing options for you to put private non-OSS stuff into our hosted public registry. For the right to do such a thing, you’ll have to pay money.

I wouldn’t personally trust a company to host private data if I didn’t pay them to do so, for the reasons above. At best, they’ll be slimy or unpredictable. Information hosted by a free service should be treated as public information.

The npm Community

The core value that npm has produced is a vibrant community of module developers. This is the product that you’re “being” when you use it today. The existence of this actively engaged community indicates to investors, employers, and potential community members that this is a relevant and interesting thing to be attached to. That’s part of why we raised money so easily.

If we screw up this community, I’ll personally feel really terrible about it. But perhaps even more important, that value will be reduced.

We can’t have that. This community is the well from which any potential value springs. If we spoil the well, we all suffer. If we make it better, we all win.

New features we can add that will make the community more robust, stable, or exciting, will continue to be rolled out for free.

In this category, we have things like: signed packages, high-availability distributed infrastructure, bug fixes, basic support, and so on. It won’t make sense to ever ask people to pay for that. Yes, it costs money, but it’s also an investment in the community value-fountain. That’s a good investment.

Copping GitHub’s Style

I have been an avid GitHub user for a long time, and at times a very vocal critic of some of their features and policies that I disagree with.

But regarding business models, I’m all fanboy about GitHub. Excuse me while I gush.

GitHub seems to understand the buy-vs-be principle better than the vast majority of companies. Back in 2009 at Yahoo!, when I first heard about GitHub’s model in a talk by Tom Preston-Warner, I remember thinking that the “free for open, pay for secret” model was absolutely genius for this sort of thing. Not because it’s necessarily the best (or fastest) way to get rich, but because this kind of approach sets up incentives in a way that is actually sustainable, and tends towards good behavior on the part of the company.

The virtuous cycle is evident. Give it away for free so that people will use it. Empower users so that they like it. When they go to work, they’ll take it with them. Charge money for features that don’t promote the network effects, and where additional trust is required.

It’s a long view, and it’s the right way to turn a community value-fountain into a sustainable resource-fountain.

When I describe our plans to people, they often nod and say, “Oh, the GitHub model, ok.” I’m sure that “public for free, private costs money” isn’t new with GitHub. However, pursuing that kind of model, while at the same time acknowledging that coding is a social activity, really was a master stroke in the history of software development. I’m very thankful that they’ve helped pave the way for people to recognize this pattern.

The use cases between npm and GitHub are somewhat divergent (except for a vague notion of “share code and do the computer”), and GitHub is addressing a much larger problem-space than npm is. But the communities served are very similar, and using a proven business model just makes a ton of sense.

Advertising

Another way in which we frequently are products is when our attention is gathered via entertaining, useful, or otherwise util-increasing media, and then directed in ways that benefit those who are trying to sell other products.

Most Facebook or YouTube users are not going to buy anything that Facebook or YouTube has to sell. However, since they control a large amount of user-attention, they are a valuable platform for advertising. Since they also know a lot about those users, they can direct specific sorts of users at a given product, and increase the value further.

Unfortunately, this redirection of attention can be extremely distracting, greatly reducing the utility we gain from the core service. Since many people put private data into their Facebook or Google accounts, it may be surprising and offensive for it to be shared and used in the service of selling them crap, so those companies must walk a very fine line.

When you have a product of your own that you can sell directly to your user, it rarely makes sense to advertise for other products. At the very least, any advertisements must be structured so as to not reduce the value of the core product. They must be for products that complement the core product in some way.

In my opinion, a good example of advertising done very well is the hosting page on WordPress.org. The services offered are beneficial to WordPress users, and are offered in such a way as to avoid distracting from the core product. The focused curation increases the value, and provides a strong incentive for the advertised products to maintain their quality or risk losing their position.

We will be pursuing similarly focused and curated advertising partnerships on the npm website, in ways that benefit our users as well as our technology partners.

We are currently in the process of building the list of partners that we will recommend to Node users. I don’t expect that this will be a significant revenue generator, but you never know. Mainly, my hope is that some guidance from the npm project can help new users learn about services that can help them be successful with Node. If it turns out to not be useful to our users, we’ll ditch it.

You won’t see any dancing pigs, or one weird trick to lower your insurance bills.

Application to Reality

Applying these principles, here’s a rough list of things that we won’t ever charge for, and I don’t think users ought to expect to have to pay for:

1. Open source package hosting
2. Installing things from npm
3. Publishing things to npm
4. Author-signing of packages
5. Account management (password resetting, etc.)
6. SSH key authentication for publishing
7. Reliability of the public registry
8. Reasonable, best-effort technical support

Here’s a rough list of things that we would charge for, and which you should probably be at least a little bit suspicious of receiving for free:

1. Private modules
2. Anything secret
3. Deployment automation services
4. Hosting your website
5. Managed copies of the registry in your company’s network
6. Business relationship management stuff (ie, anything that ends in “you get paid”)
7. Guaranteed on-demand technical support

I’m not saying that we expect to deliver all of these things. But the future is very large. We’ll iterate in the directions that make the most sense when we get there.

[1]: Pretty sure Seth Godin was the first person to coin this phrase: . As so often happens with Seth Godin’s blog posts, it’s simple, insightful, and immediately became just a standard part of the lexicon. I didn’t make it up, so please do not give me credit for doing so. [back]

[2]: Thanks, Internet! Turns out Seth Godin definitely did not coin the sentiment, though may have been the first to put it in the extremely quotable formulation above. It dates back at least to 2010. See: http://blogs.law.harvard.edu/futureoftheinternet/2012/03/21/meme-patrol-when-something-online-is-free-youre-not-the-customer-youre-the-product/