Open Source

The key to success in open source lies in understanding that it's not just about software, it's about the people (great and clear communication with proper documentation).

Dan has great tips on what it means to be high quality software maintainers. Anthony Fu's contribution guide is great.

Whilst I try to release everything I work on in the open, I make sure not to ever rely solely on OSS funding for my projects as it's just not sustainable. You need to build actual products and sell them be it via free to pro conversion or just paid product outright. I think though more products should be open source and still make a business like what cal.com is doing amongst many more. Opening up contribution to the product is valuable and has little if any drawbacks in my opinion.

Like seeing overviews of OSS releases of a person in a page like this.

Nice contributing pages

Notes

It’s very hard to make open source work for products. multiple problems:
1. How is it funded? could still make money from services, but makes it harder to integrate and sell. as a user, you should want this app to be around for the long run, and the best way to ensure that is to fund it directly.
2. Open source doesn’t guarantee long-term viability. it’s extremely common in OSS that maintainers burn out, things start breaking, and there is a lot of churn (until it dies).
3. While it’s true that development might go quicker, a lot of the time the overhead of managing the open source workflow negates the wins. And sometimes the problem just takes a while to think about, no amount of throwing devs at it will help (this is the case for what I’ve been doing in the past several months. Actual’s architecture for local data + syncing is unique and required careful thought). Open source works best for libraries in my experience. I think the best thing I could do is open-source parts of the apps as libraries, which would share the work and allow people to contribute back, while still allowing Actual itself to be carefully integrated.
Over in Node.js we found that without explicit moderation guidelines a Code of Conduct can actually be harmful 😅... especially if folks are spending time debating out how to enforce the code of conduct in the midst of a time sensitive matter.
Even if your product’s entire source code gets leaked, it won’t be catastrophic. Code is past. Ability is present. Vision is future. Majority of value lies in your and team’s collective ability to not fuck up in the present and iterate into the future.
This is what leads to burnout, abandoned projects, and churn. When we prioritize OSS availability/quality over the well being of their maintainers, it doesn't necessarily lead to the optimal outcome. We are putting code before people.
Want to become a contributor to a project but don't know where to start? Subscribe to the project's notifications! By reading notifications for issues and PRs, you'll gain valuable context about the project, code, and maintainer views that helps build your mental model.
Popularity != Quality. Especially for choosing project dependencies.
When opening an open source issue or pull request, don't make the maintainers do homework. Explain what you want/what you're doing, include relevant info, and offer to make changes. Don't make a maintainer to seek out other references or throw stuff over the wall and run.
Always credit the work from which you copied or got inspired greatly from in readme. Lets users of your project that it's a fork and ideally keep the previous git history of forked project too.
Release Early, Release Often
Ember's successful oss project management: 1. RFCs for design. 2. Canary, beta, and release stability branches. 3. LTS releases for community coordination and cadence management. 4. Major releases that don't add new features by design. 5. Backwards-compatible editions to consolidate changes for documentation and communication.
Tip for open source maintainers: you can often convert questions about your library into documentation. It usually goes like this: 1. Someone opens an issue/asks a question. 2. I address this by updating the docs. 3. Link the update to the person, ask them for feedback. Also works for internal projects.
Trick maintainers into actually looking at your issues by posting super easy repros.
You always have the right to patch and fork. Open source makes no sense without it. Fork it, and use your people skills to try to persuade people with commit access that it should be the way you want. People skills being at a deficit in our field, many choose option C: hurl abuse at any available target.

Open Source

Nice contributing pages​

Notes​

Links​

Nice contributing pages

Notes

Links