So you just started your Open Source project. The traction is decent, hobbyists like it and even a few commercial actors are adopting your code. You feel like you have wind in your sails, although a manageable amount of requests are piling up in periods. Is it any reason to think about getting a support system in place this early?

Before trying to answer the question, let's look at a quick classification of different OSS categories, and see what it means to be a solo project, even though the designation may seem quite obvious.

Project categories - What am I?

There are a few ways to categorize open source projects, but in this text I've chosen to lean on the quite telling categorization of long time open-sourcer Josh Berkus. Most other categorizations I've seen only come with minor deviations from this one. What's interesting to remark is that almost all projects seem to go through the exact same path in their lifetime. Usually, either you start at number 1 or 4, where starting at number 1, can eventually move you to 3 (or 2) and then 4 or 5. 

1. Solo
   By far the numerical majority of projects (90% or more), Solo projects have only one or two developers who are responsible for 100% of the code, decisions, and support of the project. Some Solo projects are forks of other projects where one developer who disagreed with the rest of the project decided to strike out on his own.
   
   

2. Monarchist
   Usually a Solo project which "succeeded" and developed a large community. While these projects can involve large numbers of contributors, all decisions are made by the project lead and a small number of "lieutenants" whom he/she appoints. 
   
   

3. Community
   Community projects have a significant number of contributors who run the project democratically as peers. While occasional majority votes may be taken, most decisions are made by a combination of volunteerocracy and consensus. 
   
   

4. Corporate
   Corporate projects generally consist of code which was open sourced by a private company but not completely alienated from them. The majority of programmers are company employees and the company's marketing department determines strategic direction for the project.
   
   

5. Foundation
   A non-profit foundation can be thought of as the end point in formal organization of open source projects. Such projects are incorporated with officers and directors and all decision-making formalized by the necessities of corporate structure. Often this is done in response to the project being critical to several large companies, who use the formal structure to protect their mutual interests and ensure themselves a voice.

Categorizations and descriptions are retrieved here.  

Overkill or smart planning?

So let's say you reside within the first category, “Solo”, or even the second or third, “Monarchist” or “Community”, your spinal reflex would easily be, “Let’s focus on the code, and skip the admin and planning. I'll pick up on that down the road, when I really need it”. In many cases this might work out perfectly well, but here are a few reasons to still consider it early on. 

How good is my documentation?

Starting up, it may be easier to plan for support than having extensive documentation in the first period. It also makes sense in order to learn what kind of documentation your users are actually seeking. Are their questions related to integrations, frontend, or dependencies. 

How complex is my code?

Projects differ by nature. Some projects do naturally have more complex code bases than others. This may lead to a greater need for a convenient and direct line to the core team, when questions arise. 

How well does my code go with AI?

As written about in another article, certain languages perform way better with AI than others. If you are applying code written with COBOL, Haskell or Elixir in high complexity contexts, the productivity gain from AI can actually be negative. In such contexts support might be a much better approach to increase efficiency and solve tasks faster.

How advanced is my code relative to my core users' likely competence?

Some projects may consist of more obscure code bases, applied by its users together with more traditional code bases written in popular languages such as Python or Java. In such situations, there might be a discrepancy between the task types and languages they are normally working with, and the task type and language required to implement your OS code into their project.

How are my users using my code?

To what extent do they normally modify and adjust the code, and how mission critical for their solution is the code coming from my project? These are questions that are likely to affect users´ need for assistance in implementation. Also factors related to dependencies, integrations, and risk of breaking changes, may affect the need for support. As well as how easy it is to document these risks.

What are my project ambitions?

Not everyone dreams of having a large and widely adopted project, which is understandable. But if an increased adoption rate is a goal, support can contribute to this, either marginally or substantially, depending on the nature of your project. Also, having a support structure in place early, helps you have a scalable setup if the project should take off. In addition, it may be easier to attract new team members to your project, if they get a good impression of how things are structured, and have the ability to have some form of income on the project as well. 

Do I need or prefer an extra source of funding?

Not all projects are in need of funding in order to operate in a sustainable way. But many could benefit from an additional source of funding in order to deliver the highest quality code and create more value for its users. Having a support system in place, may act as an extra stream of revenue, making it easier to devote more time to the project. 

Code snippet from LuaJIT, an OS solo project that took off.

What is the downside?

Even though there may be several reasons to consider setting up support, there are also some legitimate downsides to take into account. 

Due to cultural expectations, some users might be turned off by paid support. However, this sentiment seems to be changing. From our own experience and research, there is a willingness to pay for help if it exists. 70% out of 46 developers we asked, all working for various companies, said they would be willing to pay for OS support if it was low-barrier. You also see more and more high-profile OS developers such as Jacob Kaplan-Moss in his text “Paying people to work on Open Source is actually good”, combating the notion that all aspects of OS have to be free. With a changing sentiment, as well as clear and transparent communication from the project’s part, cultural aspects should be manageable. 

Another potential pitfall with paid support, is that you may attract contributors to your project that are more motivated by money than actually creating great code. But as with culture, this should be possible to address. Solid interviews in combination with reviewing their Github profile and history, should mitigate some risk. Also communicating that contributions are expected if handling paid support tickets, would probably help. With solutions such as Githelp, access to give support can be turned on and off in a second, if not complying with the guidelines. 

Some may also be afraid that lowering the bar will result in more support tickets. In some cases this may result in people getting lazier and asking for help with problems they previously could have researched their way out of. On the other hand, lowering the bar decreases the friction for adopting a project for the user, as well as generating an extra source of funding for the project. In particular, many commercial actors want to take on as little risk as possible, and may adopt one project over another, for the support availability of the core team. 

Final thoughts

There are both clear benefits and a few risks with implementing paid support early on. Yes, you should probably think about how you communicate it to your users and community, but the understanding for paid services such as support has, from our perspective, increased. Also, you should be clear about your expectations to new project contributors. However, with explicit communication to both groups, we see the downside as limited. Practically it may take a couple of hours to establish a good support structure and inform your users and make the support option visible. But when it's done, it's done. So, unless you really don’t see any reason to grow and have satisfied users, we will argue that establishing a support system is likely to benefit you.