This article rests on the shoulders of giants that have come before it. Richard Stallman, Linus Torvalds, Eric Raymond, and Bruce Perens are some of the countless notable activists fiercely fighting for mainstream adoption of the open source ethos in all its glory.
On the non-technical side, we have activists like Andy Hunt, Alistair Cockburn, Jim Highsmith, Mike Beedle (rest in peace) supplementing on open source development by providing The Agile Manifesto, which outlines a concise strategic framework that anyone can use to best engage in the dynamic environment that is open source.
I am not here to imitate their work. I am here to do my best to expand on this existing work in a way that is universal for all of open source - namely by sharing specific practical ways to manage the open source project lifecycle and outlining what I believe are relevant modern-day philosophies applicable to open source & beyond.
The intention of this article is to serve as an easy reference sheet for those embarking on the open source journey. It is designed to be applicable by all open source practitioners – from rookies to experts. There will be items that will not be relevant to you until different phases of the project and/or different stages in your own personal development. There may be some that you may never use. There will be many items that spark fierce controversy and this is intentional. Vigilance and ongoing critical public discourse are crucial to mainstreaming open source outside niche “techie” circles. The success of open source relies on winning the hearts and minds of the public as well as practitioners through the unadulterated truth.
Walking the path of being an open source advocate is not easy and not for the faint of heart. To struggle is a pre-requisite and let this cheat sheet serve as a guide on how to struggle smarter. Many will fail and many more will succeed.
Without further ado, let’s get right into it.
5 Guiding Philosophies of Open Source
Absolute transparency always takes precedent above all else. Transparency means all technical artifacts, as well as all business & social artifacts are always publicly accessible without a gatekeeper. Never trust, only acknowledge & verify afterwards via due diligence.
Evil exists and will always exist. Malicious actors of all backgrounds will always actively try to eradicate open source entirely. Fence-sitters who deny or doubt the existence of evil pose a greater threat to the destruction of open source than malicious actors.
Stakeholders are always more important than shareholders. In the complex paradoxical duality of the relationship between stakeholders & shareholders, solving stakeholder needs must always be prioritized to resolve disputes.
Open source will never eradicate corruption and evil. To the contrary, open source is more susceptible to malicious attacks. The power of open source lays with the ability for anyone to audit the project on their own without a gatekeeper censoring information. This serves as a powerful deterrent and is a feature closed source projects can never provide.
The possibilities and use cases for open source will always be limitless. All open source projects cost money and their advantage is in their agility over closed source solutions.
The "Dos" of Open Source
Use the same social etiquette normally expected in a professional job environment. Remember that all correspondence is public and will be logged for all eternity.
Make all project commits and social correspondence succinct and short. Each message shared should stand on its own and you should never expect someone else to decipher what you intended to communicate. No one is a mind reader.
Do start, expect failure, and learn to embrace it. Next to malicious actors, the worst thing you can do is to never start a project.
Instead of relying on others to backlog & capture your feedback, do it yourself. Priorities fluctuate, your ideas/contributions may never make it to production but that does NOT mean you should never bother to log said feedback. It is always better to log all information than not. Most times, countless others have the same feedback but never bothered to share it.
Market and sell the project as well as yourself every chance it is appropriate to do so. People genuinely do not know about you or your project, therefore you must be a good steward in pitching yourself & your project to help people understand.
All activity regarding the open source project must absolutely be exclusively on service accounts. Exercise serious consideration on who the trusted contributors will be, make the process of being a trusted contributor publicly transparent for all to see, and diversify their privileges as much as reasonably possible. This process of instituting thought-out general controls is exactly the same as setting up general controls in the corporate sector. This step is arguably more important than getting funding and development. Service account creation also pertains to social media accounts belonging to the project. Use modern-day best practices on service account creation, including Privilege Access Management (PAM) platforms to manage service account operations.
Leverage social media to sell yourself and the project. The beautiful advantage of open source projects is the freedom & flexibility to use social media to effectively engage stakeholders on a whim, which is an area that traditional corporate closed-source projects fail to leverage. Podcasts, live streams, short videos, long-form articles and videos are all invaluable assets to guaranteeing project success.
Do reach out to other people to ask for help & market what needs your project currently has. At first, you will fail to effectively communicate these needs and it will only get better with consistent practice. People want to see the progression and the failure adds authenticity & legitimacy to you as an individual and to the project.
Adopt a “less is more” approach to documentation during the early period of the project. Specifically, select a singular project management platform to conduct all correspondence at first. Create just the 5 following tabs when you are starting out & remember that you can always expand as time goes on: Backlog, Work in Progress (WIP), Issues/Bugs Log, User Feedback, How To Get Involved/Volunteer Opportunities
All content formats are equally important to the success of your project. How-to manuals for installing/hosting the project, icons legend, video introductions, etc. Learn to make use of all the various talents that interested volunteers may have. Not everyone needs to be a pro-tier programmer to aid in the project’s success.
Learn to be socially lively & engaging with your project’s community. Like it or not, entertainment is just as important as development. Treat the development & sustainability of the project & community just like writing for a TV show. Behind every project & community are people and people love to be entertained. Learn how to tailor & adapt entertainment to engage the current audience as well as potential new audiences that you have yet to reach.
Be extremely specific & clear in the project’s scope and mission. Always start off small. Scale will come with future iterations and user feedback.
Build and/or get involved with a project that is personally interesting & relatable to you. The more personable the project, the better you will understand the needs of stakeholders and you will be better equipped to successfully solving them.
Default all communications to be one-to-many unless absolutely necessary & appropriate to use one-to-one.
Be absolutely transparent with all sponsorships and incentives (implied or otherwise) received. Sponsorships are great and a normal part of a project’s lifecycle. Be a good steward and publicly share everything involved with said sponsorships/incentives. This means explaining every facet of the incentives/sponsorships in an easily digestible way in addition to showing all the “receipts” in their raw original form.
Do record team meetings relating to the project & make it publicly accessible. If recording is not feasible, always publicly provide meeting minutes in a reasonable timeframe from the time the meeting ends. Learn best practices on capturing effective meeting minutes to understand what data should be captured as a minimum. This typically includes date/time, attendee roster, agenda, summary of discussion, action items, and any future meeting dates.
Do use failed open source projects & communities as examples of what to avoid. Smart people learn from their mistakes, wise ones learn from the mistakes of others.
Do educate the audience what your architectural decisions are and rationale for why. Design patterns and tech stack architectural decisions are important, do your best to provide visuals showcasing such details.
Do learn project management methodologies and be fluid in adapting such techniques to your unique circumstances. Understanding interpersonal relationship dynamics, group psychology, relational aggression, and models of the lifecycle of groups as offered by scientific research like the Tuckman model are just as important to project success as technical development.
The "Don'ts" of Open Source
Don’t tolerate gatekeeping behavior. Open source projects fundamentally have no singular individual more important than any other and gatekeeping behavior should absolutely not be tolerated.
Don’t recklessly spend money on menial software tools like videoconferencing and appointment booking. Free and open source options exist that do much of this functionality at high quality & securely & have full support for service accounts.
Do not burden the public with deciphering the terms of sponsorships/incentives your project receives during its lifecycle. You owe it to the project and its community to show all the receipts as well as providing summarized information that is easily understood by all.
Do not try to convince everyone. You will have drama, conflict, and strong personalities in your project. Stay true to the mission and resort to the path that solves stakeholder needs when a stalemate has been reached.
Do not throw responsibilities over the fence and expect the community to resolve it. Learn to be an advocate for yourself and for the project by taking the initiative to raise concerns as well as proposing solutions with no expectations on whether it is followed.
Never trust any commit or claims made by trusted and non-trusted contributors. Acknowledge their work and always verify for yourself.
Do not let fear, uncertainty, and doubt take over the project and community. Ignorance thrives in secrecy. Use analogies of similar failings with commercial closed-source counterparts to show the complexity & persistence of similar roadblocks encountered in your project. Explain to the audience that the open source advantage is flexibility in building additional functionality without a middleman and the freedom to host it as you please.
Don’t be shy about fundraising and sponsorships. Everything costs money, even open source projects.
Don’t try to reinvent the wheel. Leverage existing open source projects as the default to build your open source project. Use closed-source technology in limited niche areas after careful review of alternatives.
Don’t be rigid and inflexible with your tech stack architectural choices and design patterns. Various phases of development & iterations of the project will require different architectural choices to meet different needs. More important is to explain why you made the choices you did.
Don’t get wrapped up with technical standards. Many have been created without feedback from stakeholders who are practitioners trying to implement and/or fix issues the technical standard imposes.
Self-help resources you can use to learn group dynamics, project management, and software systems architecture. I have no affiliations with any of these resources, I do not get any incentives (implied or otherwise) for sharing them. I have personally used these and can vouch for their effectiveness & legitimacy.
Resources On Learning About Group Dynamics
The Audio PMP Exam Prep – Conversations on Passing the PMP Exam by Carl Pritchard and Bruce Falk
Designing Data Intensive Applications by Martin Kleppmann
The Chimpanzees of Gombee: Patterns of Behavior by Jane Goodall
The many works of Dr. Harville Hendrix and Dr. John Gottman on individual & group relationships
Two very long YouTube videos I made called “The Science of Working in Groups” and “IIoT World Follow-up – Societal Impacts of Digital Transformation and IIoT”
Thanks for your time and consideration. You could have been anywhere and you chose to be here with me. For that, I am forever grateful. I will see you in the next one.
Follow me
› Linktree: https://linktr.ee/opensourceadvocate
› LinkedIn: https://www.linkedin.com/in/enrimarini
› Substack: https://enrimarini.substack.com/
› Twitter: https://twitter.com/@RealEnriMarini
› Medium: https://medium.com/@TheEthicalEngineer
› YouTube: https://www.youtube.com/@EthicsAndEngineering
› DEV Community: https://dev.to/@opensourceadvocate
› TikTok:https://www.tiktok.com/@opensourceadvocate
—
DISCLAIMER: I am not sponsored or influenced in any way, shape, or form by the companies and products mentioned. This is my own original content, with image credits given as appropriate and necessary.
Top comments (4)
Great article! 👏 thank you! 🙏
Thanks for your support, hope you found it helpful! I'm still getting used to the unique markdown stylistics of DEV, so hopefully I can format the section nicer to be easier on the eyes.
Incrível artigo, como uma pessoa que não está no dia a dia dos projetos de código aberto foi muito esclarecedor!!!
Obrigado pelo seu apoio!