# Foss and obsidian _Updated_: 2024-04-12 **Disclaimer:** As a full disclosure, I am still working for [Obsidian](https://obsidian.md). However, these opinions of mine have existed long before I joined the team. --- In the beginning, there was no Obsidian. On the first day, Shida and Erica created Obsidian, and it was good. On the second day, [a hoard of people clamoring for the open sourcing](https://forum.obsidian.md/t/open-sourcing-of-obsidian/1515) of Obsidian flooded the gates, and it was not so good. :( Open Source Software (OSS) is a lovely thing. Much like how books have disseminated knowledge, open-source software has propelled the software industry forward. I passionately support this movement, and am actively involved with the [Commonhaus Foundation](https://www.commonhaus.org/) to further its initiatives. However, open sourcing, especially under the Free Open Source Software (FOSS) model, is not universally applicable or beneficial, particularly when going from closed source. This ongoing essay explores common arguments for making Obsidian open source and examines the nuances of each position and why its just not applicable for us. For additional insights, I recommend reading Steph Ango's (@Kepano) thoughtful piece on [why companies that develop software deserve your financial support](https://stephango.com/quality-software). ## Help A common rationale for transitioning Obsidian to FOSS is the expected influx of community help in its development. However, the belief that FOSS inherently guarantees substantial community assistance is misleading and overlooks a crucial phenomenon: survivorship bias. For every FOSS project that succeeds and becomes well-known, there are numerous others that falter and fade into obscurity. Numbers of people are not enough, as I'll address here and in [[#Longevity]]. **A reliance on community contributions** Community contributions are voluntary and unpredictable. While popular projects may attract a large number of contributors, many OSS projects struggle to garner sufficient active participation for significant development help. This is a key reason why organizations like the [Commonhaus Foundation](https://www.commonhaus.org/) and [Apache](https://apache.org/) exist—to mitigate the real risks of OSS projects floundering and dying without administrative support. **The quality of those contributions** Not all contributions are beneficial. Some may not align with the project's direction or may be of poor quality, requiring oversight and revision by maintainers. For instance, the [Obsidian Importer](https://github.com/obsidianmd/obsidian-importer), a plugin developed by the Obsidian team, accepts contributions through PRs and even offers bounties on select issues. Although these contributions have been helpful, the time spent on code reviews and integrating these PRs often detracts from main development efforts, showing that internal handling can be more efficient. **Dependency on community skillsets** The assumption that a capable, skilled community is ready to contribute to a project does not always hold, especially for specialized or niche software. Obsidian, for example, is built on Electron (Capacitor on mobile) and maintains [many custom forks](https://help.obsidian.md/Obsidian/Credits) that deviate significantly from their origins. New developers must learn these codebase from scratch, as evidenced by my coworker Tony, who, after a considerable period, is still familiarizing himself with core aspects of the Obsidian code. ## Longevity One common argument for transitioning Obsidian to FOSS is enhanced longevity: "Having more people available to help will keep it going, right?" However, as previously discussed, not all help is beneficial. An extra pair of hands is only as useful as the expertise behind them. For tasks that are merely busywork, the go-to is not more hands but automation. Even more radical, the best fix is to try to [[Stop fixing all the problems]]. In addition to these, here are some other reasons why FOSS can work against overall longevity. **Economic sustainability** Developing and maintaining software requires substantial financial resources on behalf of the developer team. It's not like money rains down from the heavens as soon as you go FOSS. Unlike proprietary software, which generates revenue through commercial licenses and subscriptions (such as Sync and Publish), FOSS projects often struggle with funding. This financial shortfall restricts development and user support efforts, reducing the software's lifespan by increasing the chance of staff turnover. > [!question]- What happened to Standard Notes? > In the initial discussions and the associated Meta Thread, [Standard Notes](https://github.com/standardnotes/web), a FOSS product, was cited as a model for Obsidian to emulate. However, it's noteworthy that Standard Notes has just been [acquired by Proton](https://techcrunch.com/2024/04/10/proton-standard-notes/) this week. **Fragmentation** The inherent flexibility of FOSS that allows for forking of the codebase, also can result in fragmentation due to that forking. Multiple versions of the software can confuse users and dilute community efforts, hampering the development of a unified, robust product. Obsidian even sees this issue even within the community plugins review process. Although it's sometimes inevitable that maintainers will take the same plugin in different directions, the team does strive to limit the number of forks available on the community store to mitigate this problem. ## Security The [xz Utils debacle](https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/), where a critical backdoor was discovered prompted the following reaction from many-a-user in multiple Discords I am in, "Thank goodness it was OSS so someone could find it!" However, the reality is more nuanced, as [discussed here](https://securityboulevard.com/2024/04/xz-trojan-highlights-software-supply-chain-risk-posed-by-sock-puppets/) and [here](https://www.cisa.gov/news-events/news/lessons-xz-utils-achieving-more-sustainable-open-source-ecosystem) Social engineering has been and continues to be a significant threat in cybersecurity, and it operates independently of whether software is open source or not. In my role managing Obsidian's support, I encounter numerous attempts to extract sensitive information in what should be normal emails asking about enterprise licenses. It shouldn't be that way, but it is. Thus, the vulnerability often lies not in the software, but in human error—as a single lapse from any team member could be catastrophic if given time. Thus, as always, [[the human element remains our greatest vulnerability]]. The team does act upon security concerns sent to us directly via email or direct message. However, 98/100 of them end up being non-issues, or not applicable to the software. For example, a javascript exploit that could happen... if the user was already exploited against via social engineering. Similarly, a javascript exploit that could happen... if the user never upgraded past 0.15.0. 🙈 But, there are real issues in all software that should be tested against. To mitigate some of these concerns, Obsidian is currently undergoing another round of security audits by [cure53](https://cure53.de/#services), and the results will soon be available on the [Obsidian security page](https://obsidian.md/security). While cure53's pricing is not publicly listed, these audits are not inexpensive. The costs for these reviews show the substantial investment required for maintaining robust security measures. This initiative is part of our broader effort to ensure long-term security and viability, as highlighted in the section on [[#Longevity]], emphasizing that effective security is a costly but crucial investment. ## What is this really about? It's all about the _Trust_; plain and simple. Combine a lack of trust in software, and I mean this next party kindly, an overestimation of one's own programmatic skillset, and a person will think everything should be FOSS. However, I think this is more showing about our greater [[distrust in society as our tribes fragment]]. That's for another set of musings. Keeping it simple, let me ask: Do you trust yourself not to get hit when crossing a street beside a line of stopped cars? Do you trust that the fruit you buy at the store hasn't been warming someone's pocket all morning? How about trusting your cat to wait until you're gone before jumping on your desk? (Maybe not, but let's lighten the mood a bit). Society operates on a bedrock of implicit trust; if you can navigate these everyday acts without a second thought, you're already practicing the art of trust. It's understandable to feel wary, though. Many software companies have eroded trust through making people the product. Plus, if you combine an endless desire to make profit at the expense of the user, it soon becomes synonymous that [[#Morality|profit = evil]]. That's entirely justified. > [!warning] If you can suggest how I make the next section not sound like I am shilling for my own employer, please assist! In response to this, and the team's own disagreement with how 90's and 2000's tech firms operate, Obsidian has remained committed to transparency and innovation, and has been delivering a quality product for the past four years. The company has faced its share of challenges and celebrated numerous triumphs, most of which were before my arrival. Yet, these experiences are not a result of shunning FOSS in the approach, but rather, they stem from dedication to maintaining and enhancing the future trust that you might place in the team. ### Morality > [!quote] Whenever "open source = always good" comes up in my seminars, I prompt my students to consider the case of Android: contributing to Android means giving away your labor for free to one of the richest companies in history. \- [Pseudometa](https://chris-grieser.de/) #in-progress