title	Open Source

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.

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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Open Source

Nice contributing pages

Notes

Links

FilesExpand file tree

open-source.md

Latest commit

History

open-source.md

File metadata and controls

Open Source

Nice contributing pages

Notes

Links