ABOUT
ABOUT
Why should open source support always be free?
We never found a good answer to this question.
We never found a good answer to this question.
Logically one would think that giving away the code for free, gives even more reason for at least having the support paid. Fortunately, from our experience, more and more developers see it the same way.
That’s why we started Githelp with a simple aim - to make the easiest and best suited support tool for open source projects - and let projects decide for themselves whether they want accept payments for support.
Logically one would think that giving away the code for free, gives even more reason for at least having the support paid. Fortunately, from our experience, more and more developers see it the same way.
That’s why we started Githelp with a simple aim - to make the easiest and best suited support tool for open source projects - and let projects decide for themselves whether they want accept payments for support.
Open Source and the funding situation today
Open Source and the funding situation today
Open Source (OS) is in many ways one of the most powerful innovation enablers out there. However the increased reliance, as well as the volume and size of commercial projects who have opened their eyes for OS over the last 20 years, has made it exponentially harder to maintain OS projects in a healthy manner. On Reddit, HackerNews, StackOverflow and various blogs, one can read about how open source founders with “overnight” success or longterm grinding are struggling to scramble together a source of income. This surely inhibits the projects from growing, and affects the softwares´ overall robustness, as well as the number and quality of implemented features.
In fact, only 14% of those who contribute to OS see any form of payment, a lot fewer a payment they can live off. This is somehow ironical as it is estimated that OS projects contribute with an estimated economic value of 8 800 billion USD annually to the world economy. To put it in perspective, that is 50% more than the annual oil and gas market.
So why have we ended up here. Why is it that people who create so much value to the world are left with so little?
Open Source (OS) is in many ways one of the most powerful innovation enablers out there. However the increased reliance, as well as the volume and size of commercial projects who have opened their eyes for OS over the last 20 years, has made it exponentially harder to maintain OS projects in a healthy manner. On Reddit, HackerNews, StackOverflow and various blogs, one can read about how open source founders with “overnight” success or longterm grinding are struggling to scramble together a source of income. This surely inhibits the projects from growing, and affects the softwares´ overall robustness, as well as the number and quality of implemented features.
In fact, only 14% of those who contribute to OS see any form of payment, a lot fewer a payment they can live off. This is somehow ironical as it is estimated that OS projects contribute with an estimated economic value of 8 800 billion USD annually to the world economy. To put it in perspective, that is 50% more than the annual oil and gas market.
So why have we ended up here. Why is it that people who create so much value to the world are left with so little?
Maintainer's perspective
Maintainer's perspective
Cultural challenges - A shift is on the rise
Cultural challenges - A shift is on the rise
Some of the answer is likely related to cultural challenges. OS has always been free, and is by many expected to remain that way in a complete manner for all future. Despite support not being a part of the majority of licensing models.
As most OS projects start out as passion projects, many take for granted that developers will lend them their time without any compensation. Helping out for free is of course a beautiful feature of the open source community spirit, but most of the people in need of help are asking on behalf of commercial projects, where the answer will benefit their employer or their own startup. It is just fair that those who provide the support in these cases get some sort of compensation beyond politeness and gratitude. Doing support and assisting users can be time-consuming for both solo- and foundation level projects, and it is hard to make a living on “high-fives” and “happy-face emojis”.
Thankfully, the majority would likely agree that charging users for support is not in conflict with the open source philosophy or licensing models. Many OS vendors already make a substantial part of their revenue from support and services, where, charging for support has become more accepted in recent years. Several larger OS projects hire consulting companies to provide support on their behalf, as they do not have the tools or capacity to handle it themselves. As Red Hat early on proved, there are a real willingness to pay for support within open source, especially among enterprise level users. So why can’t the projects to a larger extent own the support themselves, or at least share it with the consulting company? Why completely outsource this revenue potential to other actors, or plain out dissmiss it as an opportunity?
Some of the answer is likely related to cultural challenges. OS has always been free, and is by many expected to remain that way in a complete manner for all future. Despite support not being a part of the majority of licensing models.
As most OS projects start out as passion projects, many take for granted that developers will lend them their time without any compensation. Helping out for free is of course a beautiful feature of the open source community spirit, but most of the people in need of help are asking on behalf of commercial projects, where the answer will benefit their employer or their own startup. It is just fair that those who provide the support in these cases get some sort of compensation beyond politeness and gratitude. Doing support and assisting users can be time-consuming for both solo- and foundation level projects, and it is hard to make a living on “high-fives” and “happy-face emojis”.
Thankfully, the majority would likely agree that charging users for support is not in conflict with the open source philosophy or licensing models. Many OS vendors already make a substantial part of their revenue from support and services, where, charging for support has become more accepted in recent years. Several larger OS projects hire consulting companies to provide support on their behalf, as they do not have the tools or capacity to handle it themselves. As Red Hat early on proved, there are a real willingness to pay for support within open source, especially among enterprise level users. So why can’t the projects to a larger extent own the support themselves, or at least share it with the consulting company? Why completely outsource this revenue potential to other actors, or plain out dissmiss it as an opportunity?
Today’s support solutions were never made for OS
Today’s support solutions were never made for OS
Today's support solutions, with greater or lesser shares of AI, are primarily developed for: 1. Online stores or 2. Business customers, and preferably enterprise (as it provides the best income potential). The former group is customer service without code support, with inquiries about product information, product returns, or shipments. The latter group is support solutions where the purpose is to assist existing customers who need help with software or code bases they have purchased access to. This type of support is normally always free, as a transaction has already taken place. It is further handled primarily by in-house employees.
None of these solutions are particularly well suited for OS-projects.
Most OS teams are by nature hybrid and distributed, consisting of contributors with various levels of engagement - Core team, External team, and community members. All representing different levels of management, different needs for incentives, and different levels of engagement.
As OS software is free, no purchase or transaction have found place, and as a result, there are no support commitment there. Today’s support systems do not provide an easy and integrated way to accept payments, making it is easier for OS projects to just skip it, and keep it free.
Today's support solutions, with greater or lesser shares of AI, are primarily developed for: 1. Online stores or 2. Business customers, and preferably enterprise (as it provides the best income potential). The former group is customer service without code support, with inquiries about product information, product returns, or shipments. The latter group is support solutions where the purpose is to assist existing customers who need help with software or code bases they have purchased access to. This type of support is normally always free, as a transaction has already taken place. It is further handled primarily by in-house employees.
None of these solutions are particularly well suited for OS-projects.
Most OS teams are by nature hybrid and distributed, consisting of contributors with various levels of engagement - Core team, External team, and community members. All representing different levels of management, different needs for incentives, and different levels of engagement.
As OS software is free, no purchase or transaction have found place, and as a result, there are no support commitment there. Today’s support systems do not provide an easy and integrated way to accept payments, making it is easier for OS projects to just skip it, and keep it free.
Paid support can help project sustainabaility
Paid support can help project sustainabaility
For most OS projects today, their only source of revenue is donations. Donations are great, but rarely give any real contribution to long term project sustainability.
Having the option to offer paid support could help the situation.
Not only can it be an extra source of funding, it can also offer some valuable side effects, such as increased availability among the projects contributors. From the OS maintaners we have been talking to, availability among team members and others in the community are - maybe not surprisingly - listed as a top challenge when it comes to providing support. Not having sufficient time to allocate for helping, and not being available when the person that needs help is online. That said, almost every contributor we have been talking to (+95%), said they would to a “notable degree” have allocated more time towards support and help, if there was some kind of payment involved.
For most OS projects today, their only source of revenue is donations. Donations are great, but rarely give any real contribution to long term project sustainability.
Having the option to offer paid support could help the situation.
Not only can it be an extra source of funding, it can also offer some valuable side effects, such as increased availability among the projects contributors. From the OS maintaners we have been talking to, availability among team members and others in the community are - maybe not surprisingly - listed as a top challenge when it comes to providing support. Not having sufficient time to allocate for helping, and not being available when the person that needs help is online. That said, almost every contributor we have been talking to (+95%), said they would to a “notable degree” have allocated more time towards support and help, if there was some kind of payment involved.
Users’ perspective
Users’ perspective
Can I rely on this project?
Can I rely on this project?
What if I suddenly get stuck and need help. Are there any established and streamlined ways to reach out? Sometimes the answer is found on Google, Discord or by using AI. But had it always been that simple, support wouldn´t have been a factor many businesses actually emphasized when they were considering to use a project.
You can of course find help on freelance platforms such as Upwork or Fiverr. We have used these platforms a lot ourselves. But we know how much time you have to put in, in order to find a suitable candidate. Shortlisting, screening and interviews. And besides - who knows better how to help than those who actually wrote the code in the first place?
For many users support becomes important, because being stuck equals longer release cycles and more resources put in to each feature. Or sometimes, even breaking code.
What if I suddenly get stuck and need help. Are there any established and streamlined ways to reach out? Sometimes the answer is found on Google, Discord or by using AI. But had it always been that simple, support wouldn´t have been a factor many businesses actually emphasized when they were considering to use a project.
You can of course find help on freelance platforms such as Upwork or Fiverr. We have used these platforms a lot ourselves. But we know how much time you have to put in, in order to find a suitable candidate. Shortlisting, screening and interviews. And besides - who knows better how to help than those who actually wrote the code in the first place?
For many users support becomes important, because being stuck equals longer release cycles and more resources put in to each feature. Or sometimes, even breaking code.
A low barrier way to reach out
A low barrier way to reach out
Today many developers don’t know where to ask for help. Do I ask this question on Discord, get in touch via email, or post it as an issue on GitHub. Is it a bug or is just me that is “stupid”? Many developers further hesitate to post issues in public issue channels, listing reasons such as the channels feeling too formal or they have received negative responses in the past when posting in public. Some also say that they don’t like to take advantage of others. While many also just like figuring out problems themselves. Regardless of reason, it is reasonable to assume that if the barrier for reaching out had been lower, more people would have done so, and been ok with paying for help.
Today many developers don’t know where to ask for help. Do I ask this question on Discord, get in touch via email, or post it as an issue on GitHub. Is it a bug or is just me that is “stupid”? Many developers further hesitate to post issues in public issue channels, listing reasons such as the channels feeling too formal or they have received negative responses in the past when posting in public. Some also say that they don’t like to take advantage of others. While many also just like figuring out problems themselves. Regardless of reason, it is reasonable to assume that if the barrier for reaching out had been lower, more people would have done so, and been ok with paying for help.
Many are glad to pay if the option is there
Many are glad to pay if the option is there
From our experience many are glad to pay for help if the option is there. Free support is of course great and admirable of those who take their time to provide it, but as it is free, it often also comes with long response times, short answers, and require asking in public - something many, as mentioned, are not necessarily a big fan of. Often it also yields no answer at all.
And if deciding to go outside the core team and the community, engaging consultants can take time, result in low quality help, and become expensive. Paid support can also be seen as a funding option that makes more sense for many businesses as they get something in return, making it easier to explain the spending for any finance department.
From our experience many are glad to pay for help if the option is there. Free support is of course great and admirable of those who take their time to provide it, but as it is free, it often also comes with long response times, short answers, and require asking in public - something many, as mentioned, are not necessarily a big fan of. Often it also yields no answer at all.
And if deciding to go outside the core team and the community, engaging consultants can take time, result in low quality help, and become expensive. Paid support can also be seen as a funding option that makes more sense for many businesses as they get something in return, making it easier to explain the spending for any finance department.
Our answer
Our answer
The Githelp platform
The Githelp platform
With Githelp we are offering a way to streamline support and offload some of the project expenses by introducing paid support to users and compensation to helpers.
We believe paid support can be a part of the funding solution for OS projects, if done properly. This means putting the maintainers in charge, facilitating for full transparency, and lowering the barrier to reach out and get help for users to a minimum. Through paid support and good tools to administer hybrid teams, we also believe it is possible to accomodate for even more community engagement. Putting support into system can make it more relevant to train experts from your community, letting you easier discover new talent, and giving you better tools for monitoring the quality of support given by the community or team members.
These beliefs led ut to build Githelp. Githelp is the first support platform tailored for OS support, where projects are given the possibility to:
Easily engage and manage your own community and build hybrid support teams - No per seat cost.
Introduce payments as an integrated part of support. Pay per minute, set a division share, and let the system automatically distribute the payment to the project and helpers.
Set up your own support landing page to your users - set resources and support rates, and make it your own.
The solution will also have other functionality that you would normally expect from a support service.
With Githelp we are offering a way to streamline support and offload some of the project expenses by introducing paid support to users and compensation to helpers.
We believe paid support can be a part of the funding solution for OS projects, if done properly. This means putting the maintainers in charge, facilitating for full transparency, and lowering the barrier to reach out and get help for users to a minimum. Through paid support and good tools to administer hybrid teams, we also believe it is possible to accomodate for even more community engagement. Putting support into system can make it more relevant to train experts from your community, letting you easier discover new talent, and giving you better tools for monitoring the quality of support given by the community or team members.
These beliefs led ut to build Githelp. Githelp is the first support platform tailored for OS support, where projects are given the possibility to:
Easily engage and manage your own community and build hybrid support teams - No per seat cost.
Introduce payments as an integrated part of support. Pay per minute, set a division share, and let the system automatically distribute the payment to the project and helpers.
Set up your own support landing page to your users - set resources and support rates, and make it your own.
The solution will also have other functionality that you would normally expect from a support service.
When to consider Githelp
When to consider Githelp
From our perspective, you should consider using Githelp if you:
Want an additional source of income or want to be compensated for support efforts.
Want to make it easier to engage your community in support activities
See the value in setting up a personal support landing page for your users - paid or free.
Registering and making the platform accessible to your users are free. As Githelp only takes a commission of any transation, you don’t pay anything if you don’t have any activity. Without any support activity, a system for paid support only makes your project appear a bit more safe to use, and maybe make more people choose it. And if you have support activity, well, great, Githelp will help you handle any request in the best possible way.
From our perspective, you should consider using Githelp if you:
Want an additional source of income or want to be compensated for support efforts.
Want to make it easier to engage your community in support activities
See the value in setting up a personal support landing page for your users - paid or free.
Registering and making the platform accessible to your users are free. As Githelp only takes a commission of any transation, you don’t pay anything if you don’t have any activity. Without any support activity, a system for paid support only makes your project appear a bit more safe to use, and maybe make more people choose it. And if you have support activity, well, great, Githelp will help you handle any request in the best possible way.
Our vision
Our vision
Make open source more sustainable by giving maintainers tools to monetize support, without getting in conflict with the open source philosophy or licensing models. And at the same time, making it easier for developers to access and compensate support.
With Githelp, we want to make support more rewarding for both the project, helper and the user.
Make open source more sustainable by giving maintainers tools to monetize support, without getting in conflict with the open source philosophy or licensing models. And at the same time, making it easier for developers to access and compensate support.
With Githelp, we want to make support more rewarding for both the project, helper and the user.
FREE FOR BETA USERS FIRST 12 MONTHS
Elevate your support efforts
And become a favorite among your users.
FREE FOR BETA USERS FIRST 12 MONTHS
Elevate your support efforts
And become a favorite among your users.