Two ways to scale

Scaling is the goal of many businesses -- grow revenue, serve more people, sell more devices, grow the product line, etc.

There are two ways to scale:

1. Increase volume with a small number of direct customers. You might be making an integrated circuit that is sold to a company making consumer devices, or you might be making a consumer product that is sold through a few outlets like Amazon and Walmart. Although you might have thousands of end customers, you only have a few direct customers.

2. Increase the number of direct customers. Many of these customers may be low volume, but the aggregate can be large, sometimes described as the long tail.

(For this discussion, we'll assume you already have a product or technology that meets a real need).

With approach #1, you can brute force about anything. As long as the product is something people want, you can dedicate application engineers to help your customers make it happen. Sometimes the design/development team interacts directly with customers. This is expensive, and the reason many industrial products are costly is that they rely on direct support.

However, this does not scale past a handful of customers. Direct application engineering support is expensive. If you want to scale the number of customers, you need to do something different.

Open-source projects are an interesting study in this regard. They address well the needs of many users. How do they do this?

There are two primary aspects: A) Quality, and B) Community.

For any complex technology to scale without a lot of hand-holding, the quality needs to be high. There has to be good documentation. The source code or design needs to be readable. The architecture needs to be simple and solid so it can be understood. You need consistency (data structures, code organization, etc.). Testing needs to be automated and robust so there are not a lot of unexpected problems.

The second thing that is needed is community. A community is the only way to support a large number of users or customers of a complex technology. With complex systems, the problems you run into are often things you have never seen before. If all of these problems need to be solved from scratch with direct one-on-one support, you will quickly become buried. Additionally, you'll find that experienced users are often better at solving user problems than technology creators. If this support is done in a public place, you soon build up a knowledge base that can be reused.

Quality and Community are the ways to scale the number of direct customers or users, and OSS-style workflows and communities are the best way to accomplish this.

If you want to address the long tail, the days of NDAs with every customer are past. The future is open. Not necessarily 100% open source, but certainly open documentation and support. And "open" provides feedback that increases quality -- it all works together.