Probably I have discussed the topic in many ways already, but I’m a “child” of open source communities and the significant role of those is not crystal clear to all.

It’s not a secret that developers love open source driven tools and development. About 65% of professional developers on Stack Overflow contribute to open source projects once a year or more. You can find dozens of academic papers to back up this. Just use google scholar. The APIs driven companies with ot without libraries have embraced the love of tools development among the developers. Developers use different programming languages and frameworks; new appear and old fade in the background. Situation changes all the time.

Developing and maintaining for example software libraries for your APIs driven platform does not happen without costs. Libraries need to be updated and documentation maintained. Rare companies have the resources to maintain multiple libraries. You have to choose where to invest based on your customer bases requirements and preferences.

Community support

But if the platform/service you provide becomes popular, then the community can chip in. Chip in is probably an under statement because community developers build and maintain huge amount of “unofficial” libraries and tools for your platform. The monetary value alone is huge. As a company you should push the community efforts forward. That can simply be done by promoting the tools in your developer portal and blog posts and events.

NPM and pip

Just take a look at NPM and Github. You’ll find several tools and projects which help you to develop solutions faster on top of some open source or closed source platforms.

For example search for “sendgrid” in npmjs results to 172 packages. Some of them are “official” packages, but only a small fraction.

Python is another popular programming language among developers, and it has pypi registry. If you search for “sendgrid” in there, you get 72 results

If you search for “stripe” in the same npmjs service, you get 503 packages. Do you really think they are all developed and maintained by Stripe?

From python registry pypi you can find 144 projects for Stripe

The above are just two examples, but you should get the picture now. You should understand how open source projects start, what is the typical evolution and characteristics of it. Without such understanding you can not support the efforts. Without the understanding you are losing huge additional support for your service. In short, you are letting money pass your fingers. Embrace the community and you’ll perform better and gain the love of the tool loving developers.

From outside in

If the open source tools originally developed by community is really usefull, you should discuss with the maintainers about the possibility to include it in your official tools. If mutual understanding is found, you should provide resources in the maintenance and development while respecting the position and rights of the original developers. I call this model “outside in”. The initial development is done outside the company, with or without knowing about it.

Often in the beginning you have no glue about it due to reason that it is developed in cathedral model (discussed below). Eventually the tool becomes either really popular (even more than your official tools) or provides additional business value of opportunities otherwise. Then the only sensible thing to do is, is to find a tighter cooperation model with the community.

From inside out

Other option is that you start the development inside the company. You might start with proprietary mode. You have no reason to use open source license. Later you want to open source the tool since it does not reveal any business secrets, it becomes popolar and you are not taking any fees to use it, community wants to make forks and improvements to it. You can release the tool as is and hope that someone starts to maintain it. That is most likely doomed.

You maintain what really interests you, provides you value or is close to your heart. Often such interest is found more easily in the “outside in” cases. Most likely you need to invest resources to maintain the open source code version. You would have to do it anyway - closed source or open source. Eventually you might be lucky and someone from the community commits to maintain the code.

When you open source components, you should be ready to accept that you have lost control on what happens in thee future. If the community has no voice on decisions, they will not participate. Why would they? Of course you can keep the source open and still make 100% of the decisions, but that does not bring any benefits compared to proprietary approach. If you keep on walking over the needs and opinions of the community, they will ditch you. They will find a similar project and contribute to it. You just lost eye balls for bugs and probably good ideas and even code commits.

Typical open source development starts with cathedral model

It can be seen that the initial phase of free software projects possesses all the characteristics of cathedral style development in sharp contrast to the later bazaar phase. The initial phase to develop an initial implementation is carried out by an individual or a small team working in isolation from the community. (Bergquist & Jan Ljungberg)

This is what happens in “inside out” style as well. The tool might be an experiment and found useful and bring value to the internal and/or external developers (customers).

Enter bazaar style

Free software projects employ decentralised peer-review by allowing anyone full access to their code. While only a limited number of developers can actually work on the implementation of a program, there is no limit to the number of people who can inspect the code and search for defects.

The bazaar style (illustrated above) makes source code publicly available and contributions are actively encouraged, particularly from users. Contributions can come in many different forms and at any time. It must be noted that just releasing code under open license in Github hardly ever results to community contributions. That takes effort known as community management.

The ‘debugging process’ of a free software project is synonymous with the maintenance phase of a traditional software lifecycle. Maintenance costs of between 50% - 1300% of development costs on a project have been reported. This is one of the reason API driven companies limit the amount of tools and libraries they maintain. Costs and required human resources. Free software projects, once they reach the maintenance phase and can access a community of co-developers, are much more productive than traditional projects with limited maintenance resources.

Companies have started open source programs to formalise the open source driven development as part of the company strategy.

Don’t just blindly jump, get familiar

The above is just a glimpse to open source communities and practices. You should read more about it just like you should get familiar with the life of the developers (consumers). Luckily the two items are intertwined.

Some more to read from 100 Days DX