In part one we looked at some of the simple steps that you can take to help your enterprise support open source projects. Now let's look at some options to give more by investing company resources.

Sponsoring an open source project

Depending on your company, this one may be even easier than contributing to code, support and documentation. Many open source projects ask for sponsorship to help the core team dedicate more time to working on the project. There are now several platforms available for you to easily sponsor the projects including GitHub Sponsors and Open Collective.

How does it work?

Typically, projects who are serious about sponsorship offer several levels, from basic to advanced with different advantages. Quite often these are called Gold, Silver and Bronze level memberships.

An example from one of my favourite projects, NestJS https://nestjs.com/:

• Backers ($2 USD per month): Support us with a monthly donation and help us continue our activities.
• Bronze ($100 USD per month): Become a bronze sponsor and get your logo on our README on GitHub as well as a small logo on the official page with a link to your site.
• Silver ($250 USD per month): Become a silver sponsor and get your logo on our README on GitHub as well as on the official page with a link to your site.
• Gold $500 USD per month: Become a gold sponsor and get your logo on our README on GitHub as well as on the official page and the official documentation with a link to your site.
• Base ($1000 USD per month): Become a base sponsor and get your logo on our README on GitHub as well as on the official page and the official documentation with a link to your site (as a main project sponsor).

Some projects also offer priority support for higher level sponsorships, and some even have a specific corporate support model, for example Vuetify (another one of my favourites!) https://vuetifyjs.com/en/introduction/enterprise/.

Make your motivation clear

My personal motivation for sponsoring projects, is that I want things to be 'fair'. I believe that if large companies are making use of open source software, it shouldn't be completely free. They have the means, and therefore a social responsibility (as well as a mutual interest) to help that project continue to evolve.

Whenever I suggest sponsoring a new project, I'm very transparent about my personal motivation, but I'm also careful to put together a well-structured case about why it is the right business decision. Depending on whom you discuss this with, each of these points will be more or less important.

Choose your projects strategically

We touched on this in part one - you might not be in a position to offer sponsorship to many projects. Establishing a standard tech stack certainly helps with this by limiting the number of open source projects you use, allowing you to focus sponsorship on only a few. Here are some other things you might consider:

• How hard will it be to switch to another technology if the project is no longer maintained?
• How well-supported is the project by other sponsors? If it already has heavy investment then perhaps your sponsorship will count more elsewhere

Invest time to educate your finance/procurement teams about open source, and the sponsorship model

Your procurement team is likely to be highly trained in the art of negotiation. The reality is that this skill isn't usually required in the sponsorship model - you can decide what you pay and in most cases (unless there is a premium support model) it doesn't make any difference to the final cost. Often the sponsorship cost of the project is also relatively low compared to the type of licence agreement or service contract that negotiations are usually designed for. Make sure you spend time with your contacts in this team to explain the philosophy and make sure they are on-board with your idea.

Financials

Not everybody will have the same motivation, and this is a very important part to prepare properly. As I mentioned you will most likely need to discuss this with finance or procurement colleagues used to an entirely different licensing model. The idea of paying what you want may be an alien concept, and you need to show them why it is a good idea. Also, if this is the start of your sponsorship journey, it's likely that you'll want to sponsor additional projects in the future.

Do your calculations including the following:

• Ongoing costs of continued sponsorship.
• Estimate how much you would pay in licence fees and maintenance costs if you were purchasing a commercial product to do the same thing. Often there isn't actually an equivalent commercial product. In that case just get whatever costs you can for alternative options if you chose to buy instead of build your project.
• List of benefits (improved support, project continuity, in some cases publicity, ...).
• Compare sponsorship cost to developer daily rate, and estimate how much development cost time is saved by using the open source solution.
• List of future expenditure as you sponsor additional projects.
• Have everything projected as monthly and yearly costs.

Be patient

You may, from time to time, become frustrated with this process of trying to get financial approval for something which seems low cost. Don't let this de-motivate you. Remind yourself that what you're doing is for the good of the project community and your company, as well as being personally rewarding.

Make a big thing about the community support

Assuming you followed my advice about choosing well-supported projects with an active community for the most critical components of your tech stack, you should be very confident in advertising this fact when discussing with procurement teams. That active open source community is essentially replacing a paid maintenance and support plan. Again, as with licence fees be ready with estimated savings for maintenance and support agreements.

Logo or not?

Often procurement teams will have a clause built into the contract about whether a vendor can use your company logo on their website to show that you are a customer. The example sponsorship model I showed focuses heavily on showing your company logo in different places of the project documentation depending on how much you decide to sponsor them.

If your company logo is shown, it's a great feeling of pride, and can be a badge of honour for the developers using that technology.

If you're not sure what your company rules are about showing the logo, don't let it delay your sponsorship - just ask the project owners not to display your logo as you still have some things to check internally.

How to pay

This one may seem frustrating, but if you've made it this far you're nearly there. This is the final red tape to cut through!

GitHub sponsors and Open Collective are wired up to take payment via credit card or PayPal. Some large companies don't like paying in this way, accepting only payments by PO - in this case reach out to the project owner and ask them to create an invoice. If your company only allows you to purchase from a list of pre-approved vendors they probably have a partner that you can use who will handle payments like this for a small fee.

The cherry on the cake

Congratulations! You've successfully navigated the internal red tape, educated your colleagues and have just sponsored your first open source project. If you've made a significant contribution, why not reach out to the project sponsor and ask them to record a short video to say thanks to your team? Hopefully they are grateful for your support and will be happy to do this for you. Trust me - this is a great way to announce the sponsorship internally and will be a great motivation to your developers.

Launching an open source project

If you have an internal project which you think could be useful for others, then this option is for you. It generally requires the highest effort, but you can start with a small library if you think that you have something which is useful to share. You'll be publicly releasing something under your company name and depending on the company there are likely a few official stamps that you'll need before releasing it.

List the benefits

Start by making a bullet pointed list of the benefits of releasing your project. You may or may not present this as a slide to people involved in the approval. You should do it even if you won't present it, because it helps you to ensure you have a succinct explanation of what you aim to do and why. Here are some which come to mind:

• Motivate the team by working together on a project visible to the outside world.
• Attract talent when recruiting thanks to your visible open source activities.
• Great publicity for your company.
• Depending on your project making it open source may help to improve architecture because of the thought process required to ensure the design will be useful for the community (I had this experience with whispr: https://github.com/Sanofi-IADC/whispr/).

Licence review by legal team

Larger corporations most likely have a legal team who should be involved in the approval process for releasing a project. Check if your contact has experience with open source software. If not, spend some time explaining the concept to them and why you want to launch a project. Once you have educated them in the open source philosophy, have them review and approve the specific open source licence that you intend to use to release your project.

Communications/marketing team

You might also have an internal communications or marketing team. Again, spend some time with them to educate them about open source and explain your project. You might need their blessing to release a project stamped with your company name, and if all goes well you might be able to get their help with publicising the launch of your project either internally or externally.

Wrap-up

That's it! In the first part of this series I tried to give you some suggestions on how to get started with open source in your enterprise. In this second part we looked at how to go about sponsoring an open source project, and the importance of educating your non techy colleagues to help you do this. Finally we looked at launching your own project. Large or small I know that you and your team will find this incredibly satisfying.

I hope that this series has given you some ideas and inspiration for promoting open source within your enterprise. Thanks for reading!