Be transparent<\/strong>. Transparency is pretty simple to understand: make it so that the community can watch and understand what you\u2019re doing: use a publicly accessible source code repository that\u2019s easy to find, use public facing issue tracking software, post your release plans where the community can find them, and capture meeting minutes in public forums (e.g. mailing lists with archives).<\/p>\n\n\n\n Be open<\/strong>. For a lot of open source projects, \u201ctransparency\u201d and \u201copenness\u201d mean the same thing, but the terms really are quite different. Being open is more than just being \u201copen book\u201d (which is essentially the same thing as transparency). For many, the \u201copen\u201d in open source means open to new ideas, or open to participation. The rules for participating in an open source project should be the same for everybody (\u201clevel playing field\u201d): it\u2019s not enough to just accept a few patches, you have to be open to new ideas. In short, you have to let others in and give up absolute control of the project.<\/p>\n\n\n\n Keep the \u201cPlaying Field Level\u201d<\/strong>. This doesn\u2019t necessarily mean that you have to let just anybody join the project, but rather that you ensure that the same set of rules apply to everybody (the playing field may be level, but you still have to earn your way onto the field). Meritocracy is about earning your way in. Some projects implement meritocracy, for example, by requiring that developers make some number of contributions to demonstrate that they understand the code, rules, and culture of the project before inviting them to join the project team. Make sure that the process for adding new developers to your project are well known and that the process is operated transparently (e.g. a public vote).<\/p>\n\n\n\n Be vendor neutral<\/strong>. In order to be truly open, people need to feel welcome to contribute. This is easier if the project is vendor neutral. A vendor neutral project is not dominated by any organisation or organisations; meritocracy should be based on the contributions of an individual, not the goals or hiring practices of any specific organisation. Hosting at vendor neutral foundation is one way to achieve this.<\/p>\n\n\n\n Have well defined and documented standards<\/strong>. Be sure to document your project\u2019s code formatting rules (make code formatter preferences easily accessible), expectations with regard to test coverage, development methodology, software and tools required, channels to connect with the project team, and other important information for potential contributors. Capture all of this information and make it as easy as possible to find. It\u2019s a good practice to include a contribution guide in the root of your projects source code repositories (with DVCS, it\u2019s entirely possible that potential contributors will find a copy of a copy of a copy of your repository; having the contribution guide in the repository will make it easy for potential contributors to find their way home).<\/p>\n\n\n\n Ensure that the project code is always buildable<\/strong>. Include build scripts and instructions with the project code. Make it as easy as possible to successfully build and test the project code.<\/p>\n\n\n\n Connect with your user community<\/strong>. The user community is that group of people who use the products of your open source project. The user community rarely contributes anything directly to the project code, but does tend to ask a lot of questions. Make sure that those questions get answered. A healthy user community feeds an adopter community.<\/p>\n\n\n\n Connect with your adopter community<\/strong>. An obvious sign of success for an open source project is that other groups start to use your open source project in their own products, or build extensions. This community is more willing to give back to the project and will be the project\u2019s best source of contributions. Some number of those contributors will be great candidates to join your project\u2019s team. Development of an eco-system of adopters and extenders is a great way to ensure the longevity of your project.<\/p>\n\n\n\n Connect with your development community<\/strong>. The development community is comprised of your project\u2019s team members and contributors. Provide well-known channels for communication within this community. Having clear lines of communication will help developers collaborate.<\/p>\n\n\n\n Have a plan<\/strong>. It\u2019s easy to lapse into a pattern of just letting software development happen, but like any process (especially a software development process), having some method to the madness is critical. Make sure that your project employs a development methodology and make sure that somebody owns the process (e..g a project lead). Having a plan helps developers know where they can contribute the most value and makes it easier for adopters and extenders to implement their own plans (and thereby be successful). Treat your open source project like any other software development project.<\/p>\n\n\n\n Manage your brand<\/strong>. Your project will have a brand. The project\u2019s name is its identity; as is the project logo, along with the names of any products (it\u2019s typical that an the products of an open source project share the name of the project, but some projects produce more than one product). Claim the project\u2019s brand as a trademark and consider registering that trademark. Establish trademark usage guidelines so that adopters know how to use your brand. This is an area where working with an open source software foundation can add value. A foundation can hold and defend the project\u2019s trademarks on behalf of the community. This avoids letting any particular individual or organisation hold the project\u2019s name hostage (this happens).<\/p>\n\n\n\n Pick an OSI-approved open source licence<\/strong>. Don\u2019t create your own custom licence; that will just add legal hurdles for anybody who wants to use your code. Make sure that the licence that you choose is compatible with the manner in which you intend for the code to be used. Further, ensure that the licence is compatible with any third party content (e.g. libraries) that your project code needs. Include the SPDX code for your licence in the headers for all source files.<\/p>\n\n\n\n Manage Intellectual property and copyright<\/strong>. The code, documentation, and other artifacts contributed to the project is intellectual property. Who owns that intellectual property? Do the authors retain their ownership, or do they assign it to another entity? Make sure that the rights and responsibilities of contributors are understood by all contributors. Consider having contributors sign a developer certificate of origin (DCO) or a contributor licence agreement (CLA). Ensure that copyright notices are included with the source code and in notices.<\/p>\n\n\n\n Note that it is unlikely that the project itself is a legal entity that can hold copyrights. This is another way in which an open source foundation can provide a valuable service.<\/p>\n\n\n\n Care about security and mitigating vulnerabilities<\/strong>. Make sure that your builds are as secure as possible and that the software repositories that your builds pull content from are stable and secure. Enable private vulnerability reporting and create private channels that are to be used only for discussion of undisclosed vulnerabilities (be sure to summarise and\/or move information into public channels after vulnerabilities have been remediated and disclosed). Have a policy regarding disclosure. What do you do, for example, when a vulnerability is taking too long to resolve? Do you report unpatched vulnerabilities to your community or do you keep it to yourself until after a patch is available? There are different schools of thought on this topic.<\/p>\n\n\n\n Move your project to an open source foundation<\/strong>. We\u2019ve mentioned foundations a few times already. A foundation can first and foremost help you to keep your project vendor neutral, which will help adoption: a bit part of the appeal of open source software is that adopters can avoid being beholden to a particular organisation. A foundation can hold onto and defend the project\u2019s trademarks, establish a governance model, help you manage your brand, provide intellectual property management services, and just generally provide assistance and advice for operating a successful open source project. Being a part of an open source foundation provides a value feedback loop. The foundation provides credibility for your open source project which in turn provides credibility to the foundation.<\/p>\n\n\n\n Running an open source project is a lot of work. But, as we\u2019ve suggested, how much work it takes really depends on your definition of success. Fall back on the core principles of open source development: transparency, openness, and meritocracy. Everything else comes from that.<\/p>\n\n\n\n We presented this content as a talk at the OCX Webinar Week in November 2025:<\/p>\n\n\n\n We\u2019ve created this issue<\/a> as place to post comments and discuss this article. If you have questions about Eclipse Project Governance, contact emo@eclipse-foundation.org<\/a>.<\/p>\n","protected":false},"featured_media":5740,"template":"","meta":{"_acf_changed":true},"tags":[],"class_list":["post-3943","blogs","type-blogs","status-publish","has-post-thumbnail","hentry"],"acf":[],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\t
\n\n\n\n![\"Video](\"https:\/\/img.youtube.com\/vi\/ltbYK4JhgRY\/hqdefault.jpg\")
<\/a><\/figure>\n\n\n\n
\n\n\n\n