I've had numerous, fantastic opportunities over my career to work at great companies with super smart people on all kinds of interesting projects. A little over a year ago, I was wondering if I was 'done' and started a form of retirement. I never lost my desire to create software, and in the process of working on some code, it became abundantly clear to me that a problem which I had observed over the last several years was both very real and predominately unsolved.
Using open source software, especially trying to do development using it, is still too hard.
I'm not saying that "open source sucks." On the contrary, it is very good and popular projects evolve rapidly. The speed of change is what makes it so challenging, combined with documentation which is often not as good as the software itself.
When you run into an issue using open source software, what do you do? I know my behavior typically goes like this:
- I assume I've done something stupid, so I keep checking and rechecking my work.
- I do a lot of internet searches, which leads me to...
- ...reading a lot of blogs, Stack Overflow posting, mailing list archives, public JIRA tickets, etc.
- I attempt to decipher what I've read and apply it to my problem.
- If still unsuccessful, I at least try to narrow down the scope of the problem. Am I even sure which open source project is the root of my problem? Is it Project X, or does it look like the problem is in X but really a result of my usage of X with Project Y?
- Do more searches to find out how to engage with the open source project team. Mailing list? Slack channel? Stack Overflow? Post a GitHub issue?
- Work had to post a complete description of my problem, perhaps linking some auxiliary materials such as a stack trace or a log file dump.
- Wait and basically beg for free help.
I could have jumped right to step 7, but the fact that I'm essentially asking for free help is what stops me. I do not want to be a burden, and I want to make sure I've done my homework before my problem becomes our problem.
Yes, it's true sometimes I can offer payment. For example, some open source maintainers are available on Patreon. As, when it's me as an individual asking for help, I think that's a fine idea. Moreover, I'm a big believer in open source communities. Maybe I need to ask for help from Project X, but hopefully I can pay it forward by my contributions to Project Y. (And almost every project will gladly welcome documentation contributions.) This is a model which has worked for decades, and it's a great one.
But something has changed
The rise in adoption of open source in enterprises, and particular the use of open source to develop custom applications, has introduced new tensions to the traditional open source community model. Enterprise developers face some specific challenges.
- They may not be sure if they are allowed to contribute back to the project. They may even be explicitly prohibited from doing so.
- Many enterprise developers are simply not familiar with the community model.
- Enterprise developers may feel that they are not yet skilled enough to provide meaningful contribution.
- Even if they wanted to make a financial contribution or even pay for some help, most enterprise developers have no way to do so. Even if there is a means for the company to make some kind of payment, the amount of time and paperwork required is simply not worth the effort.
A consequence of this is that enterprises are doing a lot of "taking" from open source, but not nearly enough giving back. This, in turn, is starting to cause dissatisfaction within communities. Surely, with all of their resources, these enterprises can find some way to support the community?
There must be a better way
As I thought more and more about all of these challenges, I started to craft a solution. I consulted with key open source visionaries to understand their concerns and needs. I spoke with development leaders in enterprises. And, with that knowledge in hand, Lyfevest was born.
Sustainable open source
Lyfevest's vision is to make open source sustainable. The first challenge we wish to address is how to improve the relationship between enterprises and open source communities. It's predicated upon a few tenets:
- Reduce friction. It should be easy for an enterprise developer sitting at their desk to ask for help without dealing with "red tape."
- Inclusiveness. Whereas most open source funding solutions benefit the project maintainers, true sustainability requires sharing the wealth with all contributors.
- Fair wages. Contributors, regardless of their location, should consider the payments for service to be fair and reasonable. Competing systems which offer work to the lowest bidder effectively discriminate against contributors in developed countries.
- Demonstrable expertise. Rather than relying on someone saying "I'm good and X and Y," analyze their actual open source contributions to make an unbiased determination of their capabilities.
Towards these goals, today I am announcing the Lyfevest "Contributor Beta." As the name suggests, this beta is only for open source contributors. Participants in the beta will be offered 'fake' jobs. The good news is that you don't actually have to do any work. The bad news is that you don't actually get paid (even if the job claims to be a paid opportunity.) It's really to help us work out the bugs in the contributor system before we advance to the next major beta which will involve real, paid work.
This beta is by invitation only. Participants may receive invitation codes that they may use to invite others into the beta. The goal is to scale up slowly and ensure that everything is working a-okay. You can follow @lyfevest on Twitter for the occasional up-for-grabs invitation code.
I could not be more excited to have reached this important phase for this project. I welcome your ideas and feedback, and I hope to see you as a member of our community!