How maintaining an Open Source project looks like

Sandro Maglione

Sandro Maglione

Mobile development

Full sprint on Open Source this week for fpdart v2 ๐Ÿš€

fpdart at a glance:

  • Flutter Favorite
  • Nearly 500 โญ๏ธ on Github and 750 ๐Ÿ‘ on pub.dev
  • Nearly 3'000 "used by" on Github

fpdart is used by nearly 3000 other open source repositories on Github, and also many more private projects in productionfpdart is used by nearly 3000 other open source repositories on Github, and also many more private projects in production

This is what it takes to be an Open Source maintainer (my perspective ๐Ÿ’๐Ÿผโ€โ™‚๏ธ)


Choose carefully

First warning for people interested in publishing their own open source project: choose carefully ๐Ÿ˜…

I don't think many developers realize how stressful being an open-source maintainer can be. You provide countless hours of work and support, for *free*. And devs will still complain and unfairly criticize your work. But the ones that are appreciative keep us going.

652
Reply

My rule before publishing:

Am I seeing myself working and maintaining this project long-term (years) [for free]?

Go ahead only if the answer is absolutely yes ๐Ÿ”ฅ

How fpdart came to be

This is how the stars aligned:

  • I was working on Flutter a lot
  • I was learning functional programming
  • I was using dartz and reading its internal code quite a lot

๐Ÿ‘‰ Will I use Flutter years from now? That's the intention.

๐Ÿ‘‰ Will I use functional programming years from now? Absolutely.

How can I combine these 2 interests? Easy, let's write my own functional programming library in dart ๐Ÿช„

You can read the full story in The History of fpdart

There is more.

Every week I build a new open source project, with a new language or library, and teach you how I did it, what I learned, and how you can do the same. Join me and other 600+ readers.

Where to start

The best tool for an open source maintainer is called prerelease (dev, alpha, beta).

Start by sketching something that works, and push out with a "prerelease" warning ๐Ÿ’๐Ÿผโ€โ™‚๏ธ

This is where you are allowed to make mistakes, break things, refactor everything (basically the best part of the job ๐Ÿ˜Ž).

How to continue

Code is only the first (rather small) step. What's next:

  • Documentation
  • Testing
  • Tutorials
  • User feedback

Important: These are not secondary considerations, these are the core of maintaining and open source project ๐Ÿ› ๏ธ

These steps will take more time than coding itself:

  • Make sure people know how to use the library (documentation)
  • Make sure the library works as expected (testing)

How to end

When the following happens:

  • Everything (nearly) is tested
  • Everything (hopefully) is documented
  • People are using the library with success

Only then it's time to remove the "prerelease" and push out as "stable".

Once in "stable" there is less room for changes: people are using the library in production systems, less time to address breaking changes ๐Ÿ’๐Ÿผโ€โ™‚๏ธ

And back again

The work continues. More documentation, more tests, more support (issues and user feedback).

Example: fpdart

  • First release 28 May 2021 (3 years ago): just an "experiment"
  • Initial interest: "this looks like a good alternative to dartz" ๐Ÿค”
  • Documentation: tutorial articles and API reference
  • More interest and initial external contributors
  • v1 release: first "stable"
  • Flutter Favorite (2.5 years later)
  • v2 ๐Ÿ”œ

Check out the PR preview for fpdart v2


It's not just coding at the end. It looks more like being an entrepreneur ๐Ÿ’ก

The path is long, but it can be super rewarding and it will teach you way more than just being a consumer of other packages.

Give it a try (or contribute to existing projects ๐Ÿš€)

See you next ๐Ÿ‘‹

Start here.

Every week I build a new open source project, with a new language or library, and teach you how I did it, what I learned, and how you can do the same. Join me and other 600+ readers.