How do you fund and sustain your open-source software project in the long term?

OSS projects are not made public for a clear reason of getting a funding, it is a way to sustain a project for a long-term which is receiving contributions. Receiving funding for a project, also counts as a way for contributors showing an appreciation to your project.

You need to have a clear a history of releasing something usable and momentum of contributions. Having a documented mission is nice. A track record of successful activity creating software gets you funding.

Permissions/Terms for Users, Developers, and Contributors: Envision from the start the terms & conditions (Licenses - permissive/copyleft, notices, liability, etc.) that you intend for the project with respect to Users, Developers, and Contributors. This will set out clear expectations for all. Approaching investors with clarity is a key step to successfully seeking funding, and is helpful in driving the commercials of your OSS project.

Other than funding, sustaining an open-source software project long-term entails defining clear goals and values, fostering openness, choosing suitable licenses, exploring diverse funding models, engaging supporters, offering value-added services, establishing governance, and investing in community building efforts.

This is partly true. Finding funding for any project is difficult and a long term problem if you are simply a few developers working on a software project. Creating value out of open source software usually means selling a commercial product. The other funding sources stated are options. However, the ethereum community is also friendly towards public good OSS through grants.

Communicating a common goal and getting people to keep showing up is difficult for a corporation in today’s work climate. Having a strong community manager personally along with some development management skills will help considerably. Common tools that just work make all the difference.

Creating the community is the hardest, but most important, part of OSS projects. Focus on recruiting people passionate to build and use your projects. Ensure they have sufficient time to contribute to your project on a reasonable cadence. Your job as a project maintainer is to ensure your projects have sustained development momentum.

The most important thing for any long-lived open source project is finding and onboarding new contributors. The only way to keep your project going is to find new folks interested in working on the project, and willing to help you govern the project. More tips and links about funding open source on this sustainability site: https://fosssustainability.com/

SBOMs (software bill of materials) are security-relevant: Vulnerability Management - SBOMs provide transparency into the components used in a project, making it easier to identify known vulnerabilities in those components. This can help maintainers prioritize security fixes and patch issues quickly. License Compliance - SBOMs can list the licenses of included components, making it easier to ensure compliance. This can be crucial for avoiding legal issues and fostering community trust. Dependency Management - SBOMs can improve dependency management by providing a detailed snapshot of all dependencies and their versions. This can help developers track changes, identify deprecated dependencies, and update them with compatible versions.

Security is a difficult task for anyone developing software and we generally rely on CI test suites and peer code reviews. This paragraph reads like a college text book. I would eliminate it or have a software developer rewrite it.

You could have suggested to reuse other open-source projects to avoid rewriting the existing “hardened” solution and introducing new bugs. That’s relevant both for the complex problems (like encryption) and just repetitive ones (like handling timezones). However depending on the third-party components requires that you keep them up-to-date to prevent their known vulnerabilities impacting you.

I find the quality aspect the most difficult to wrangle, and the most visible to the end users. I have found that it is near immediately when a user determines their like, need, and perception of the software they're looking at, whether for rational reasons or not. Documentation will come to the rescue both for the users on the fence wondering if they're doing it right, and for the users that are getting things out of the software and looking to stretch.

In this paragraph it’s especially clear that the article is generated. The topic is important and the suggestions seem relevant. However here they look like another “corp speak” and repeating the obvious. There is no point in simply listing all the possible things you can do one by one. Instead you should have only 1-2 approach(es) in a sentence explaining the benefits or sharing some examples.

This article reads like it was written by code. It has a very specific form. I am not sure if people will like it or even notice. It bothered me. I went back reviewed the introduction. Written by AI.

Consider alternative contributions people can offer besides money. For instance: * If you want to hold a community meetup, an organisation might provide a their auditorium or a room free of charge, and even provide light refreshments like drinks, nibbles, or pizza. * Some organisations offer free web hosting to open source projects. * Recruiting ambassadors can help advocate for and promote your project.