HACKER Q&A
📣 ctrlmeta

Which OSS codebase can I learn that'll remain relevant after 20 years?


I am a software developer for many yrs. I've written some opensource projects but they're not popular... only 10-20 stars, one or two bug reports in a year. I've made contributions to large OSS projects but I feel like small fish in large ocean there. There are much bigger fish and whales in OSS who understand the codebase so well and they can extend that code and help others in ways I can only dream of. For sometime I'm having an itch to learn some open source codebase really really well, go deep into it. I want the satisfaction of knowing one open source project deeply. But this takes time and focus. I get such satisfaction in my day job working on proprietary codebases. I want to find the same satisfaction in an OSS project. This could become my weekend hobby. I'm looking for suggestions. What I'm looking for:

* Very well established libre/opensource project

* Something that will still be relevant and still be around after 20 years

* Something that has a community of users around it (it is okay if it is a niche community)

The "still be around after 20 years" is important because if I'm going to spend many weekends learning some codebase it'd better be on some codebase that is going to be around after 20 years so what I learn does not go entirely waste. Thoughts? Suggestions?


  👤 _448 Accepted Answer ✓
Linux, Apache Webserver, PostgreSQL, LLVM, Clang, GCC, BSD(any flavour), Boost, Rust, GTK, KDE, Firefox, MySQL, MariaDB, Sqlite.

I suggested the above projects because a lot of people use them in commercial products. So they are not going to go away. And they are very well funded by mega corporations.


👤 tabbott
It's hard to know what codebases will last 20 years. But I think even if an open source software project becomes less relevant over time, hopefully the things one learns about software construction and building sustainable open source communities to other projects in the future.

One of my personal goals for Zulip (https://github.com/zulip/zulip/#readme) is for it to be a teaching-quality codebase. This entails a lot of decisions about how Zulip is designed and how we as a community collaborate on it. But above all, it entails a focus on constantly trying to debug and fix barriers to new contributors joining the project, in addition to investing in things like readability, well-designed test suites, documentation for contributors, etc.

I'd look for those attributes in a project.


👤 jonas-w
Some things that will be definitely relevant in 20 years would be: - git - linux kernel/firmware

Some things that may be relevant in 20 years: - chromium - Firefox - nginx - some apache software - android

I just thought about programs i use on a day to day basis. These projects are all huge, but that is what makes them be relevant in 20 years.


👤 minhmeoke
Just look at what stuff we were using in the 1990s and early 2000s and still use now, then extrapolate:

Command line tools and libraries: these are the building blocks which everyone uses (maybe indirectly) but nobody appreciates.

- bash, zsh

- rsync, tar

- openssh, putty

- opengpg

- git / svn / cvs (obsolete, but still in use)

- libreadline

- objdump and similar low-level tools

System software whose internals rarely change significantly and will probably still be around in 20 years:

- Filesystems like ext4 and zfs

- Package management tools and formats like: pacman, apt, rpm/yum

- Runtime environments like JVM, CLR, Blink/V8, LuaJIT, Beam, Haskell, and presumably WASM in the future

- Bootloaders like GRUB2

Larger software projects (the internals of these might change more quickly over time though):

- Linux kernel, FreeBSD, OpenBSD, OpenWRT, Haiku

- gtk3

- ffmpeg, mplayer, vlc, blender

- Wayland

- Sqlite, PostgreSQL

- LLVM

- Inkscape, Gimp, ImageMagick

- Wireshark, GNURadio

Other options to consider (less popular, but might need more help):

- Thunderbird (not everyone wants to use a webmail client)

- input methods like fcitx (these might change over time though)

- Fontforge

- CUPS and other printing and scanning utilities

- flashrom


👤 zaphar
That is hard to difficult to predict since so much of what makes a codebase/framework/tool stick is somewhat arbitrary. You can look for industries that move slower which basically means web development is probably out. The linux kernel is probably going to be around for a quite a long while so maybe that's an option.

I might suggest however that the focus on long lasting codebases is perhaps misplaced. You can't predict that very well. But you can help a codebase stay relevant if you get to know it deeply. Perhaps you should instead look for the project that looks interesting and relevant to you and perhaps your work to understand and develop that codebase will help it stay relevant for 20 years.


👤 Someone
I think you should look for very large projects. Small projects, however popular, can get replaced by new competitors in no time flat.

You also want ones that already are decades old. Those have proven to be able to live for decades, and (as far as we know) it’s not like projects can die of old age.

So, things like Linux, PostgreSQL, gcc, or LLVM (maybe, because it’s not yet 20 years old).


👤 Cesura
Recently I've been thinking about contributing to NetBSD (mainly porting some drivers from OpenBSD for M1 hardware). From everything I've seen, they have a very welcoming and relaxed community that encourages contributions.

I suppose it will be around in 20 years, but maybe only as a research/tinkering OS.


👤 endisneigh
Honestly the only thing I'd be willing to personally guarantee will be around 20 years from now would be Linux.

Even something like Postgresql, which I would also say would last 20 years, could be overtaken if there were some "perfect DB" as a result of some breakthrough on Database research.


👤 uraura
Spring. It is used by many enterprises and enterprises don't change tech stack that often. The project also adds new features regularly.

👤 rustqt6
Vim

👤 brudgers
Emacs?

👤 pestatije
wasm