我来自中欧。我从 14 岁开始编程，试图用 x86 汇编程序构建下一个大操作系统。事实证明这太难了，所以我写了一个简单的 EXE / COM 病毒，感染了我的整个计算机（但没有别的，当时我没有互联网）。

如今，我是静态/富类型系统、不变性和函数式编程的粉丝。从主流语言来看，Kotlin 是我的最爱。从非主流语言来看，我对 Idris 及其依赖类型感到兴奋，并希望其中一些最终会渗透到主流中。在开发 Trilium Notes 的过程中，我加深了对现代 JavaScript 的掌握。它是一种非常符合人体工程学的脚本语言，尽管它缺乏静态类型意味着它不能扩展到少数人之外。

不完全是编程，但我坚信微服务架构对于绝大多数项目来说都是一个很大的矫枉过正，它的广泛采用基本上是一种货物崇拜和简历驱动的开发。将网络放入业务逻辑交互中会产生巨大的成本（可靠性、性能、缺乏事务、重构难度、“弱类型”），但您通常不会得到任何回报（有更好的方法来实现模块化）。

IntelliJ IDEA. 我最喜欢的两个领域是自动静态分析和高级重构功能。我花了很多时间在 IntelliJ 上工作和空闲时间，我很幸运能够使用我真正喜欢的工具。

10 万美元既很多，也不是很多钱，所以我会寻找你能获得最大收益的地方。

在我看来，像 GIMP，Kdenlive 或 Audacity 这样的项目资金不足，但“足够简单”，几个全职的奉献者可以产生很大的不同。这些应用程序对于公众将 Linux（BSDs...）视为一个完整的用户平台至关重要，但它们缺乏必要的企业支持。

早在 2017 年，笔记软件并没有太多选择。我曾经使用 Notecase Pro 专有软件。我喜欢它基于自由格式树的结构、所见即所得编辑器和其他一些功能，但它只有基本的同步功能，所以我决定构建一个可以在工作中使用的 Web 应用程序，我所有的笔记都会在家里与 Notecase Pro 同步。

但是相对较早的时候，我发现保持与这个应用程序的兼容性对于它带来的好处来说太困难了（有很多“阻抗不匹配”，例如，像斜体这样的简单格式是使用一些自定义二进制标记完成的，并且从/到 HTML 的翻译是痛苦的），所以我决定为我的需求制作一个单独的应用程序会更容易。我最初分配了 3 个月来开发它，现在已经 6 年了......

没有什么特别令人兴奋的。这是一个客户端-服务器应用程序。 前端 JavaScript，后端 JavaScript（node.js），SQLite 用于持久性。原生它是一个可以部署在 Linux 服务器上的 Web 应用程序，对于桌面，有 Electron 包装器。单个实例（例如桌面、服务器）可以在彼此之间同步。

人们有时会批评 Trilium 使用 Electron，他们更喜欢原生应用程序。但这是一个错误的二分法——如果 Electron 不存在，根本就没有桌面 Trilium。

命名事物很困难，尤其是取名之后，几乎不可能再改名。当我开始这个项目时，我住在加拿大安大略省。延龄草（Trillium grandiflorum）是安大略省的“省花”（我知道这听起来有点荒谬），因此出现在许多机构和公司的名称中。所以我到处都能看到它。我喜欢它的发音，自然风格，以及与“树”的关联——“树”是 Trilium 的核心数据结构。

如上所述，该项目最初是 Notecase Pro 的 Web 应用程序开始的。我记得当时给我留下深刻印象的是创建和操作笔记树结构是多么容易 - 例如，向上或向下移动层次结构中的笔记，只需一个快捷键。与许多其他笔记工具不同，它不会强迫您进入特定的结构，而是将其留给您。

在开发的早期，我还阅读了“Tinderbox Way”，描述了知识库构建的一些哲学以及同名应用程序的一些功能背后的思想。这为 Trilium 中一些更高级的功能/概念（例如提升的属性）提供了灵感。

如今，灵感主要来自用户的反馈/想法。

我想到的一个目标是将长期可持续性作为一个爱好项目。即使是相当突出的开源项目，也有令人惊讶的比例在很大程度上是由一个人驱动的，这也适用于 Trilium。所以我试图保护自己免受倦怠，确保我做了很多有趣的事情，并将无聊（或完全令人沮丧）的工作限制在最低限度。

例如，Trilium 是纯英文应用程序，起初可能会令人惊讶。添加本地化并不难，它增加的是维护开销，管理翻译/字符串，确保所有对话框的大小足够灵活以支持各种语言等。你可能会说我是一种歧视，基本上排除了非英语人士，但对我来说，这是专注于保持 Trilium 开发的反倦怠预防之一。

我可以提到的另一个权衡是在桌面和移动设备之间取得平衡。如今，拥有良好的移动支持被认为是必要的，但这会导致一些妥协，通常会降低功能/界面，使其适用于移动和桌面。

我正在做出不同的权衡，对我来说，Trilium Notes 是一个桌面优先的应用程序，移动应用程序（实际上只是移动网站）只是“尽力而为”，一些更复杂的功能完全无法访问。就个人而言，我实际上根本不会在智能手机上使用 Trilium —— 如果我需要注意某些内容，我会使用像 Google Keep 这样的应用程序，然后回到计算机时再引入 Trilium（具有适当的分类等）。

这是一个笔记应用程序，所以它不是火箭科学:-D 没有花哨的算法或类似的东西。

也许一个具有挑战性的工程问题是如何使事情变得快速 - Trilium 的一些高级功能（例如属性继承，由用户设置的属性驱动的逻辑/表示）意味着应用程序必须为某些操作查询大量数据。要快速完成此操作，您需要最大程度地减少 IO/数据库交互的数量。

多年来，它进行了几次迭代，但最终它收敛到一种设计，其中大多数业务逻辑完全在内存中执行，无需数据库访问。后端进程具有注释元数据（树结构，标签，关系）的完整数据模型，而前端具有类似数据模型的延迟加载子集 - 您可以在 UI 中看到的注释，所有引用的注释，显示注释的所有祖先（例如，正确评估属性继承）。

因此，其中一个挑战是保持所有这些不同的数据模型（前端、后端、数据库 + 来自远程服务器的同步数据）同步。

早在 2017 年，这个领域就没有太多选择，我相信从那时起这个领域经历了明显的繁荣。很有可能，如果在 2017 年有这样的选择，我会成为某个现有应用程序的快乐用户（也许是贡献者），而不是开始我自己的项目。但那艘船已经航行了。

之所以有许多应用程序似乎在做同样的事情，是因为每个应用程序及其作者都有特定的愿景。然后，这迫使一些特定的权衡，从而使其他一些想法（不是原始愿景的一部分）难以执行。例如，许多应用程序以仅使用文件系统（而不是数据库）而自豪，但这极大地限制了应用程序的功能（或使其难以实现）。一个例子 - 我从 Notecase Pro 得到的一个基本想法是，为了记笔记，文件夹和文件的二分法（文件夹不能有自己的文本内容，文件不能有子文件）正在破坏“内容重构”，例如，你想要将较长的段落提取到单独的子笔记中。但是基于一个简单的文件系统迫使你这样做（你可以解决这个问题，但它必然是丑陋的，不再忠于文件系统的精神）。

大多数用户都很友好，礼貌和感恩。你经常可以读到关于愤怒用户的恐怖故事，但我很高兴地说，我的经历多数都是正面积极的。我只记得只拉黑过两个用户（在 GitHub 上）。

最重要的是能够重现缺陷。在这样一个从根本上由数据驱动的应用程序中，这有时具有挑战性，甚至行为通常也由用户数据（属性）决定。因此，提供良好的描述至关重要，文件问题差异很大，从没有上下文的非常模糊的描述到超级详细的分析，有时还附加了拉取请求。

对我来说，发布软件的实际行为是简单和自动化的，这一点非常重要。在大多数情况下，它执行一个具有单个参数（版本）的脚本，该脚本在我的 Linux 系统上本地构建所有桌面二进制文件并将它们上传到 GitHub。然后使用 GitHub Actions、Flatpak 在 FlatHub 上构建 Docker 镜像。

这限制了我能够为其发布二进制文件的平台数量 - 例如，Apple M1 的构建无法从 Linux 自动化。

不，从来没有计划将 Trilium 商业化。我认为在个人笔记/知识库工具领域谋生非常困难，基本上不可能“做大”。

唯一的途径是通过构建多用户支持、各种身份验证方法、细粒度 ACL 和其他企业功能来瞄准公司，但我相信这从根本上是一种不同的产品，它迫使个人笔记做出一些妥协。

我在 GitHub 和 PayPal 上收到捐款，这些捐款提供“啤酒钱”。很高兴看到用户看到了我的工作的价值，并愿意真正支持它。

日常工作实际上非常简单。我每周工作 40 小时，所以工作时间和其他时间之间有非常明显的区别。

我也有明确的时间分配给家庭和个人关系，他们优先。

具有挑战性的部分是平衡 Trilium 的工作与阅读等其他智力追求。一方面，我对用户负有一定的责任，并尝试尽可能多地进行错误修复/功能实现。我尝试保留一些时间，例如阅读，有些日子我根本不打开 GitHub / IDE 等。

避免倦怠是我在谈论长期项目可持续性时概述的思想/策略的重要组成部分。基本上，我试图做一些有趣的事情，避免无聊的事情（除非真的有必要），即使以更广泛的用户采用为代价。我认为另一个重要的方面是范围管理 - 我试图始终牢记项目可实现的范围，这样就不会觉得我为自己设定了一个不可能的目标。

构建开源软件的最大优势是可以按照自己的节奏做自己的事情，使用它的人“只是”一个不错的奖励。您通常没有与商业产品相同的自由，您的存在取决于产品的成功/采用。

我想最好的方法是使用该应用程序，查找一些错误或识别缺少但适合项目任务的功能。

人们有时也会贡献主题和脚本/扩展。一位用户创建了一个 Awesome Trilium 的此类贡献集合。

我不希望 Trilium 再经历巨大的变化，从概念上讲，它或多或少已经完成。但是，还有无休止的小功能和改进等待着发生。

为了给出一些具体的东西 - 在下一个版本中，我想实现一个应用程序内离线文档，我还想花时间提供更好的开箱即用的数据可视化（基本统计，以及“笔记地图”功能的改进）。

这是一个令人惊讶的困难问题。我开始这个项目是为了挠自己的痒，但该应用程序早已满足了我的个人需求。我想现在这是一件有趣的事情，对现有用户负有某种责任感和普遍的完美主义的结合。我听说 OSS 项目在作者的羞耻中蓬勃发展，我想这其中有一些道理。

并不像看起来那么令人兴奋。有一个由乌克兰志愿者运营的网站“出售炮弹”——你有点捐钱为乌克兰军队购买炮弹，作为“虚荣奖励”，他们会在上面写下你选择的文字（据我了解，在发射前不久）。你可以以不同的价格选择不同类型的贝壳等，这有点超现实。

我承认把它放在 GitHub 上是挑衅性的，本质上是题外话。但我认为，作为一名作者，我可以就我关心的事业发表个人信息，这是公平的。我的信息基本上是，支持乌克兰及其主权必然意味着提供武器（有很多人口头上支持乌克兰，但拒绝提供武器，在我看来这是一个不一致的立场）。是的，武器会杀人，但这正是您必须做的，以保护自己免受入侵者的侵害。

很明显，人工智能将改变这个领域，只是目前还不清楚具体如何。非常简单的工作（如简单的网站）可能会在很大程度上“外包”给人工智能。我们将拥有经过领域培训和项目培训的人工智能编码助手、静态分析和质量门。这只是当前最先进的技术（工业需要几年时间才能赶上）。我曾经是一个人工智能怀疑论者很长一段时间，但即使是这些技术含量相对较低的 LLM，也被证明足以满足许多用例。

话虽如此，如果在强大的通用人工智能方面有所突破，那么所有的赌注都落空了。

我担心的一个长期趋势是，开源越来越被企业贡献所主导。一方面，许多公司将贡献开源代码视为“新常态”是件好事，另一方面，似乎许多项目/领域的复杂性对于社区来说已经遥不可及（不受商业利益的约束）。

社区开源最适合可以由一个人或一小群人处理的项目。让社区开放源码软件更大规模地工作是相当困难的。KDE 将是一个值得注意的例外，因为它相当大，相当成功，但仍然主要是社区运行。

不过，一些企业驱动的项目运行得很好，值得注意的例子是 Linux 内核或 Postgres。在光谱的另一边，我们有例如眨眼，你有一个公司主导项目（即使它是开源的），并对网络平台的发展有不成比例的影响。

最好的动力是挠自己的痒。如果为现有项目做出贡献，请尝试从小事开始。如果你想贡献一个更大的东西，请先咨询维护者。现实情况是，项目不会接受任何功能，即使它设计得很好。

如果你正在开始一个新项目，不要试图让它变得完美。采用迭代方法，第一个版本可能真的很糟糕，这很好。我认为有些人可能会有某种怯场，因为他们的代码是开放的，每个人都可以看到，因此可以接受批评。不要太担心。

最初，我以“快速行动，打破常规”的心态开始了这个项目。我迭代得非常快，不关心错误或代码质量。当时，我是主要用户，项目只是半公开的，所以没那么重要。

后来，随着时间的推移，代码质量和错误率显著提高，这很重要，因为我已经有一些用户。但有一件事从未真正得到改进，那就是自动化测试代码覆盖率。我从未回去为现有功能编写测试，只有应用程序的少数部分有测试。

我仍然认为在项目的基本 POC 阶段不编写测试是可以的。但是，重要的是要抓住它开始变得重要的正确时刻。

Trilium Notes Logo
Trilium Notes is a hierarchical note taking application with focus on building large personal knowledge bases.

language: JS
stars: 22,233
last commit: 4 days
repo: github.com/zadam/trilium

I’m from Central Europe. I started programming when I was 14 years old, trying to build the next big OS in x86 assembler. That proved to be too hard, so I wrote a simple EXE/COM virus instead, infecting my whole computer (but nothing else, I had no internet back then).

Nowadays, I’m a fan of static/rich type systems, immutability and functional programming. From the mainstream languages, Kotlin is my favorite. From the non-mainstream languages, I’m excited about Idris and its dependent types and hope some of that will be eventually trickle down into mainstream. In the process of developing Trilium Notes, modern JavaScript grew onto me. It’s a quite ergonomic scripting language, although its lack of static types means it doesn’t scale well beyond a few people.

Not exactly programming, but I strongly believe that microservice architecture is a big overkill for a great majority of projects and its wide adoption is basically a cargo cult and resume-driven-development. Putting network into your business logic interactions has significant costs (reliability, performance, lack of transactions, refactoring difficulty, “weak typing”), but you often don’t get anything in return (there are better ways to achieve modularization).

IntelliJ IDEA. The two areas I love the most are the automatic static analysis and the advanced refactoring features. I spend a lot of my time at work and my free time with IntelliJ and I feel lucky that I get to use a tool I really like.

$10 million is both a lot and not a lot of money, so I’d look for places where you get the most bang for the buck.

In my mind, projects like GIMP, Kdenlive or Audacity are underfunded, but “simple enough” that a couple of full time dedicated contributors could make a big difference. These apps are critical for the public perception of Linux (BSDs …) as a complete en user platform, but they lack the necessary corporate backing.

Back in 2017 there wasn’t a lot of choice in note-taking software. I used to use proprietary software called Notecase Pro. I like its free-form tree based structure, WYSIWYG editor and some other features, but it had only rudimentary sync capabilities, so I decided to build a web app which I could use at work and all my notes would sync with Notecase Pro at home.

But relatively early on I found out that keeping the compatibility with this app was just too difficult for the benefit it brought (there was a lot of “impedance mismatch”, e.g. simple formatting like italics was done using some custom binary markup and translation from/to HTML was painful), so I decided it will be easier to make a separate app for my needs instead. I initially allocated 3 months to develop it, instead it’s been 6 years now …

Hardly exciting stuff. It’s a client-server app. Frontend JavaScript, backend JavaScript (node.js), SQLite used for persistence. Natively it’s a web app which can be deployed on a Linux server, for desktop there’s Electron wrapper. Individual instances (e.g. desktop, server) can sync between each other.

People sometimes criticize that Trilium uses Electron, and that they would prefer a native application instead. But this is a false dichotomy - if Electron did not exist, there would simply be no desktop Trilium at all.

Naming things is hard, especially if the name is there to stay, and you can’t easily refactor later. When I started the project, I lived in Ontario, Canada. Trillium grandiflorum is Ontario’s “official flower” (sounds kind of absurd, I know), and as a consequence appears in the names of many institutions and companies. So I kept seeing it all the time just by walking around. I liked the sound of it, the natural theme, and it kinda alludes to “tree” which is the central data structure in Trilium.

As mentioned above, the project originally started as a web app for a commercial application called Notecase Pro. I remember what impressed me back then was how easy it is to create and manipulate the note tree structure - e.g. moving the note in the hierarchy upwards or downwards is just one keyboard shortcut. Unlike many other note-taking tools, it didn’t force you into a particular structure and left it up to you.

Early in the development, I also read “The Tinderbox Way” describing some of the philosophy of knowledge base building and the thinking behind some of the features of the eponymous application. That provided inspiration for some of the more advanced features/concepts in Trilium (e.g. promoted attributes).

These days, inspiration mostly comes from the user feedback/ideas.

One goal which comes to my mind is the long term sustainability as a hobby project. A surprising share of even quite prominent open source projects are largely driven by a single person, and that applies to Trilium as well. So I try to protect myself against burnout, by making sure I do a lot of the fun stuff and limit the boring (or outright frustrating) work to a minimum.

As an example, Trilium is English-only application which might be surprising at first. Adding localization is not that hard, what it adds is the maintenance overhead down the line, managing the translations/strings, making sure all the dialogs are sized flexibly enough to support all kinds of languages etc. You might call me a discriminating a……hole to basically exclude non-English speakers, but for me, it’s one of the anti-burnout preventions focused on keeping the development of Trilium viable.

A different trade-off I can mention is balancing between desktop and mobile. Having a good mobile support is these days considered a necessity, but that drives some compromises, often dumbing down the functionality/interface so that it works for both mobile and desktop.

I’m making a different trade-off, for me the Trilium Notes is a desktop first application, with mobile app (actually just mobile website) being just “best effort” with some of the more complicated functionality completely inaccessible. Personally, I don’t actually use Trilium on a smartphone at all - if I need to note something, I will use an app like Google Keep and then put it to Trilium once on a computer (with proper categorizing etc.).

It’s a note-taking app, so it’s no rocket science :-D There are no fancy algorithms or anything like that.

Perhaps one challenging engineering problem is how to make things fast - some of the Trilium’s advanced features (such as attribute inheritance, logic/presentation driven by user-set attributes) mean that the application has to consult a non-trivial amount of data for some operations. To do that fast, you need to minimize the amount of IO/database interactions.

It took several iterations over the years, but in the end it converged to a design where most business logic is executed completely in memory without database access. The backend process has a complete data model of the notes’ metadata (tree structure, labels, relations), while frontend has a lazy loaded subset of a similar data model - notes which you can see in the UI, all the referenced notes, all the ancestors of displayed notes (e.g. to correctly evaluate the attribute inheritance).

One of the challenges there is then to keep all these distinct data models (frontend, backend, database + synced data from remote servers) in sync.

Back in 2017 there wasn’t a lot of choice in this area, I believe since then this area experienced a significant boom. It’s quite possible that if there was such a selection back in 2017, I would become a happy user (and perhaps contributor) of some existing application instead of starting my own project. But that ship has sailed.

The reason why there are some many applications seemingly doing the same is that each application and their authors have a specific vision. This then forces some specific trade-offs which then make some other ideas (which are not part of the original vision) difficult to execute. For example, many apps pride themselves to use only a file system (as opposed to a database), but that significantly limits the capabilities of the application (or makes it very difficult to implement). An example - one basic idea I got from Notecase Pro is that for the purpose of note-taking, having a dichotomy of folder and file (folder can’t have text content of its own, files can’t have children) is breaking the “content refactoring” where you want to e.g. extract longer paragraphs into a separate sub-note. But being based on a simple file system forces you to do exactly that (you can work around that, but it will necessarily be ugly and not true to the file system spirit anymore).

Perhaps that most users are actually pretty nice, polite and thankful. You can often read horror stories about entitled angry users, but I’m glad to report I had a mostly positive experience. I can remember only two users who I had to block (on GitHub).

The most important thing is to be able to reproduce the defect. That is sometimes challenging in such a fundamentally data-driven application, where even behavior is often determined by user data (attributes). Providing a good description is therefore crucial, and the file issues differ greatly, from very vague descriptions without context, to a super detailed analysis, sometimes with a pull request attached.

It’s very important for me that the actual act of releasing the software is simple and automated. For the most part it’s executing one script with a single parameter (version) which builds all the desktop binaries locally on my Linux system and uploads them to GitHub. Docker images are then built with GitHub Actions, Flatpak on FlatHub.

This limits the number of platforms I’m able to release binaries for - e.g. the build for Apple M1 can’t be automated from Linux.

No, there’s never been a plan to monetize Trilium. I think it’s very difficult to make a living in this segment of personal note-taking / knowledge base tools and basically impossible to “make it big”.

The only path to that is targeting companies by building in multi-user support, various authentication methods, fine-grained ACL and other enterprise features, but I believe that’s fundamentally a different product which forces some compromises for personal note-taking.

I get donations on GitHub and PayPal which provide “beer money”. It’s also very nice to see that users are seeing value in my work and are willing to support it in real terms.

The day job is actually pretty simple. I work the standard 40 hours a week, so there’s a very clear divide between what is work time and the rest.

I also have clear time allocated for family and personal relationships, and they take precedence.

The part which is challenging is balancing the work on Trilium with other intellectual pursuits like reading. On one side I feel certain responsibility towards users and try to do as much bug fixing / feature implementation as possible. I try to reserve some time for e.g. reading, some days I don’t open the GitHub / IDE at all etc.

Avoiding burnout is the big part of my thinking / strategy outlined above in talking about the long term project sustainability. Basically I’m trying to work on fun things and avoid the boring things (unless really necessary), even at the cost of a wider user adoption. Another aspect I think is important is scope management - I try to always have an achievable scope of the project in mind, so that it doesn’t feel like I’ve set an impossible goal for myself.

The great advantage of building an open source software is that can just do your own thing at your own pace, people using it is “just” a nice bonus. You usually don’t have the same freedom with commercial products where your existence depends on the product success/adoption.

I guess the best way is to use the app, find some bug or identify a feature which is missing, but fits into the project mission.

People also sometimes contribute themes and scripts / extensions. One user created an Awesome Trilium collection of such contributions.

I don’t expect Trilium to undergo huge changes anymore, conceptually it’s more or less finished. But there’s an unending tail of smaller features and refinements waiting to happen.

To give something specific - in the next version I’d like to implement an in-app offline documentation, I also want to spend time on providing better out-of-the-box data visualizations (basic statistics, but also refinement of “note map” feature).

That’s a surprisingly difficult question. I started the project to scratch my own itch, but the app has long already fulfilled my personal needs. I guess now it’s a combination of being a fun thing to do, feeling some kind of responsibility towards the existing users and a general perfectionism. I heard that OSS projects thrive on shame of their authors and I guess there’s some truth in it.

Not as exciting as it might seem. There’s a website run by Ukrainian volunteers which “sells shells” - you kinda donate money to buy an artillery shell for the Ukrainian army and as a “vanity reward” they will write text of your choosing on it (as I understand, not long before firing it). You can choose different kind of shells for different prices etc., it’s kind of surreal.

I admit that putting it on GitHub is provocative and essentially off-topic. But I think it’s fair that I as an author can put a personal message about a cause I care about. My message is basically that supporting Ukraine and its sovereignty necessarily means providing weapons (there are many people who vocally support Ukraine, but reject providing weapons, which is in my view an inconsistent position). And yes, weapons kill people, but that’s just what you have to do to defend yourself from invaders.

It’s becoming quite obvious that AI will change the field, it’s just not yet clear how exactly. Very simple jobs (like simple websites) will likely be “outsourced” to AIs to a considerable degree. We’ll have domain-trained and project-trained AI coding assistants, static analysis and quality gates. And that’s just with the current state of the art (industry will need a few years to catch up). I used to be an AI skeptic for a long time, but even these relatively low tech LLMs are proving to be powerful enough for a lot of use cases.

Having said that, if there’s some breakthrough towards strong general AI, all bets are off.

One long term trend I worry about is that open source is getting more dominated by corporate contributions. On one hand it’s good that many corporations see contributing open source code as a “new normal”, on the other hand it seems that the complexity of many projects / areas are getting out of reach for the community (which isn’t bound by commercial interests).

Community open source works best with projects which can be handled by a single person or a small group of people. Getting community OSS work on a bigger scale is quite difficult. KDE would be a notable exception since it’s quite big, quite successful, yet still largely community run.

Some corporate driven projects are pretty well run, though, notable examples would be Linux kernel or Postgres. On the opposite side of the spectrum we have e.g. blink where you have one company dominating the project (even though it’s open source) and having a disproportionate influence on the web platform evolution.

The best motivation is scratching your own itch. If contributing to an existing project, try to start with something small. If you want to contribute a bigger thing, check with the maintainers first. The reality is that projects won’t accept any feature, even if it’s well engineered.

If you’re starting a new project, don’t try to make it perfect. Embrace the iterative approach, the first versions may be really crappy and that’s just fine. I think some people may have a sort of stage fright with their code being open, visible to everyone and thus open to critique. Don’t worry about it too much.

I started the project with the “move fast and break things” mentality. I iterated very quickly, not caring about bugs or code quality. Back then, I was the main user and the project was only semi-public, so it didn’t matter that much.

With time the code quality and bug rate improved significantly, which was important given that I had some users already. But one thing which was never really improved is the automated test code coverage. I never went back to write tests for the existing functionality, and only few parts of the application have tests.

I still think that it’s fine to not write tests in basically POC stage of the project. But then it’s important to catch the right moment where it starts being important. (END)