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).

I try to make my working on open source sustainable with building actual paid products and having nice GitHub sponsors rewards.

I do think the future is everything being open core. As it makes sense. If there are 2 nearly identical products but one has open code and another doesn't, it makes sense that one that's with open code wins as the contribution/ideas flow is unbounded on open source project. If managed well.

My goal is to make every tool/app I use be open core with fastest and most intuitive interfaces available.

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

Inlang & Cal.com are nice open source companies. Cal.com Handbook is nice read.

Like seeing overviews of OSS releases of a person in a page like this. I use GitHub bio for 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.

Genomics

Immunology

Startups

AWS

Serverless computing

Build systems

Computer vision

Algorithms

Formal verification

Blockchain

Figma

Message queue

Remote Procedure Calls

Psychedelics

Lysergamides

Tryptamines

Renewable energy

CSS

Game development

Game engines

CPU

Nutrition

Drinks

2018

2019

2020

2021

2022

Alfred

Keyboard Maestro

Xcode

Neural networks

Linear algebra

Logic

Automated theorem proving

Mathematical optimization

Statistics

Type Theory

Diseases

Music production

GraphQL

Internet of things

Peer to peer

VPN

GitHub

Containers

Kubernetes

iOS

Linux

Nix

Electrical engineering

Quantum physics

Functional programming

Interactive computing

Software testing

Version control

C

Clojure

C++

Dart

Elixir

Elm

Go

Go libraries

Java

JavaScript

JS libraries

React

Julia

Kotlin

Lisp

Nim

Objective C

OCaml

Processing

Prolog

Python

Python libraries

R language

ReasonML