Published on

Become the RAJA or RANI of Open Source


Rani of open source

Of course that is AI generated, what did you think?

Why Should You Even Care?

Everyone uses open source. If your company or organization doesn't use open source, it's probably due to legal regulations or specific business requirements keeping you under wraps from researchers.

Numbers don't lie, especially when they come from various researchers:

The majority harnesses open source for competitive advantage. You prototype faster. You ship features faster. You get all these great tools for free, right?

This is not yet another article about how bad corporations are for not paying for maintainer's work

Unfortunately, only 21% of open source maintainers are paid for their work. It's not fair, right?

You'll often encounter statements like:

  • "You should give back to the open-source community."
  • "Support open source because it's the right thing to do."
  • "Be a good open-source citizen and pay people for their work."

These arguments might not hold water in the capitalistic world of business. I'm aware of the movement called "socially responsible business," but that shouldn't be the primary motivation to support open source.

Your company should support open source not just because it's the right thing to do, but because it should secure its investment.

For example, if you strategically decide to start using PostgreSQL instead of Oracle, that's commendable; you've saved a lot of money in the short term. But have you considered a scenario where PostgreSQL could be abandoned in three years? It would be wise to set aside some of the money saved by not using Oracle and invest in the PostgreSQL community.

With commercial software, it's straightforward. You pay a hefty license fee, sign contracts, and indirectly secure your investment. Sometimes, you strike deals like paying smaller license fees by publicly sharing a case study with the software vendor.

In open source, it's different. There's no out-of-the-box fee. You simply take the code for free, allowing you to innovate, prototype, deliver new features, and enhance competitiveness in the short term, yielding quick, excellent results.

However, always think of the long-term plan.

Anyway, it's not just about money. Let's delve further into other ways you can support open source and invest in its sustainability.

The Raja or Rani of Open Source

For a better structure of the article, I've coined an acronym that encapsulates my thoughts into four sections.

The acronym I've crafted is RAJA, inspired by Indian culture. Why Indian?

My personal experience in AsyncAPI Initiative reveals a substantial number of contributors from India, steadily increasing each year. Many exceptional individuals. Even research and statistics support this; GitHub predicts that by 2027, India will surpass the United States as the largest developer community on GitHub. By choosing "RAJA," I wanted to pay tribute to this amazing open source community from India, because I'm surrounded by it.

While "Raja" represents a male king or prince, I couldn't figure out a way to be more inclusive for the significant female contributors from India. I'm open to suggestions, especially as you read about the content I've crafted to explain RAJA acronym; you might come up with a more neutral and fitting acronym. Please let me know.

So, choose your own path and become the Raja or Rani of open source!

Utilize open source like a King or a Queen. Be a superhero!

R - Recognize

Contributing can start small; nobody expects you to send rockets to the moon on your first day. Besides, code is just a fraction of open source work.

Let the maintainers of the projects you use know that you're using them and for what purpose. Recognize their efforts. Do so in GitHub issues if possible, or in their community communication channels.

It's as simple as that. You can't imagine the positive effect it has on people. It's like an espresso shot in the morning.

NASA using AsyncAPI

OMG NASA uses the project I maintain 🤯.

Don't get me wrong, it doesn't have to be NASA. Even if you're not allowed to disclose where you work, publicly appreciating people for their hard work can make a difference.

Simple thanks

Many maintainers have no idea who uses their tools. Let them know. Don't let them feel alone in their endeavors.

Take a moment and listen to this story from Fran Mendez, the founder of the AsyncAPI specification where he shares how alone he felt until a friend sent him a photo of a conference presentation from Slack, mentioning that they use AsyncAPI. You can continue with the whole story about the impact he felt when more people from other companies shared similar experiences.

A simple sentence crafted in a minute can have a major impact on a maintainer's life.

After reading this chapter, take a break and go to the projects you use and appreciated the hard work of its maintainers. It really isn't difficult.

A - Advocate

There are many more ways to support a project to ensure its sustainability, such as advocacy — spreading information about the project.

Yes, you heard me right; there are more opportunities for no-code contributions! It's not just developers who help grow projects.

Articles

Write an article. Some projects have their blogs, so ask them if they allow guest blogs. Sometimes, writing an article on your personal blog or blogging platforms can be beneficial. This approach helps spread information about the project across different domains, positively impacting SEO.

It doesn't have to be a lengthy story. It could be a simple introduction or a specific use case. It could be a short piece with some code samples that you might already be writing for your project.

I know some people might think, "No, it doesn't make sense. There are already many getting started articles about the project I use.".

But that doesn't matter. Everyone writes differently, and every human looks at things from a different perspective. The same goes for readers. Many might prefer and understand the project better thanks to your introduction, rather than the ten others they've already seen.

Don't overthink it. Don't make it complicated. Just write it! And once again, let the project maintainers know about it.

Some projects have ambassador programs, while smaller ones compile lists of articles related to the project in their README files.

Help them grow.

Help them reach more people.

Help them build the credibility they desperately need.

Conferences and Meetups

Don't like to write? Prefer to talk? I feel the same way. I dislike text communication; it lacks soul.

There are many events you can attend and talk about the project. I'm not saying you have to apply for KubeCon or Web Summit right away.

Start small, especially if it's your first time. Many companies have internal events, like Lunch Talks or Breakout Sessions, or whatever fancy name they use. Promoting the project internally is also helpful.

Of course, the best is public help, something that you can share with maintainers. Then they can also compile a list of talks, pointing to recordings or at least slides. Don't you have some tech meetup in your neighborhood?

The best content is where you talk about the project right from your context. The story about what problems you had and how you solved them with the given project.

But it is not only about the case studies. General education also makes a lot of sense.

Basically, share with others what you've learned. The more personal the presentation, the more credible.

That should be first on the list, that is an easy task.... oh really? You can't imagine how all these different companies are protective about their brands.

I, on my own, hate when something that seems easy is not. It's damn difficult.

I have a theory that all these websites and projects that share a bunch of logos of different companies that use the project, they fake it or at least do it without their consent.

My favorite motto is: "better beg for forgiveness than to ask for permission." I would probably take companies' logos without their consent as well, but only if I were in a single maintainer's project not caring about the health of the community around it.

So please, if you use a given project in your company, drop an email to management. If you are in a healthy environment, you can drop such an email to upper management, not going through the management ladder. These email fights can burn out, so brace yourself. Get proper approval and let maintainers know they can put your company logo in the README.

Logos add 10 points to credibility and for maintainers are like extra health pickups for a long journey. And once you combine official logo usage with official case studies, that works almost like an invincibility power-up.

J - Join

150 lines of markdown and I finally write about code.

But not only.

The best and most beneficial for your investment is to join the project.

What does it mean?

It doesn't mean that you drop some bug report once a year or contribute a feature that you need in your project.

I mean join for real. Share responsibility. Share workload.

This can mean code maintenance, docs maintenance, helping in the maintenance of deployment infrastructure, or the release automation.

Of course, start small by reporting the problems that you see. Start by contributing fixes. This is your investment. Don't behave like you are entitled and maintainers owe you something. Cause they don't.

But don't stop with helping small. Many open-source projects are very open to accepting maintainers - just let them know you are interested. Projects also have different contributor guides. Sometimes they model around a multilevel maintenance, where you can join first as a person that helps with the triage of issues and pull requests, then as a reviewer, and then as a core maintainer.

From the outside, it looks like becoming a maintainer is a super hard task. It's all about your commitment and relationship with existing maintainers.

If you are regularly involved in the project, you know exactly what's happening. You know upfront about the direction of the project, and you can better prepare your company investment for upcoming changes.

Just join them; don't let them pull your weight.

A - Award

Best award for a maintainer is if they are financially stable and can work on their project on regular basis, not during nights or weekends.

Many projects or maintainers individually already use GitHub Sponsors. Some are more advanced and host projects of great platforms like Open Collective.

Send them $5 or whatever you can, just as a starter. Then start discussion inside company, explain how critical the project is for you. Explain the costs of migrating to another tool if they one you invested in stops security releases, stops accepting PRs, is basiclaly dying.

From my own experience I know it is hard. In the past I worked in a corporation that invested in one open course project that had one maintainer. I went on a journey to get him some money and to make him aware his work is important. It took almost a year to pay $6k... The process was terrible, as nobody did it before. And all success was thanks to the fact that I found in management person that believed in open source and was willing to support. I still think it was worth it. For me for sure as this was my first open source contribution and I learned it is not only about code. Furtunately it is not only about code, as at the time I did it, like around nine years ago, I was very ashamed of my code. I should probably be ashamed of it even now 🥲 but I no longer care.

The good thing is that most of this cases internally go to upper management that talks only over emails, which makes things easier. Writing an email is easy, especially that it is not public request. Then you just sent a reminder for yourself to send another email, to followup multiple times - yes, this will happen. Sometimes they will block your account and fire you sometimes they will listen 😄.

The most important thing that you need to remember is that you are not begging for money for yourself. At least I can speak for myself, as person that fights for money in AsyncAPI Initiative. If I would have to ask sponsors for money for me, I would feel it is below my dignity. But when I ask for money for the project, for the community - things are different.

The best award though is when your company hires maintainers so they can simply continue doing what they were doing during spare time.

I know many maintainers that were hired by some company to work full time on open source, to basically continue work without doubts. I'm one of them. Believe me, the feeling is great.

Now it's time for your company to secure your investment and hire maintainer that will make sure the money you saved on using their project, will not cost you a fortune a year later.

Now go and collect all the letters from the acronym and become the RAJA or RANI of open source

Feel free to reach out to me via email at lpgornicki@gmail.com.