JS Ng

The Software Ecosystem

•

So you’ve put in your couple hundred hours of programming, you’ve built your neat little app, heck you’ve even rewritten it three times when you realized it was a mess and needed better organization. You’re feeling pretty good about your code, and about yourself, with good reason! And now you want to enjoy a little treat, you want to share it with the world — maybe put it on GitHub, post it on Reddit or even Hacker News.

You’ve just stepped into the software ecosystem.

The Software Distribution Ecosystem

The first question your users will ask is: “How do I download and run your program?” The second question your users will ask is: “How do I download and run your program?” The third question your users will ask—Look, there’s a reason every software project has a text file that everybody reads first, there’s a reason the standard name for that file is “README”, and there’s a reason every README file has a section called “Getting Started” or “Quickstart” or “Installation”.

Historically this section had a five-step process, something like:

  1. Download the source code from this URL
  2. Install dependencies needme, otherlib, and funnyname from their respective websites
  3. Compile the code using make install
  4. Set environment variables SECRET="your_api_key" and MODE="production"
  5. Run the program with ./start.sh

Programmers, being programmers, automated this step as well. Instead of having to download dependencies manually, they set up package repositories to host their code and its dependencies. Instead of having to compile the code manually and put it in the right places, they wrote installation scripts that would do it for you. Instead of having to figure out dependencies and versions, they created package managers and requirements files that would specify exactly what versions of what packages you needed.

So these days the Quickstart section might look more like:

  1. Install the package manager npm (if you don’t have it already)
  2. Run npm install my-cool-app to download and install the app and its dependencies
  3. Run my-cool-app to start the program

pip for Python, npm for JavaScript, cargo for Rust, apt for the Ubuntu flavor of Linux, pacman for the Arch flavor of Linux, … Each community has its own distribution system, maybe even more than one. This distribution system pre-dates modern app stores like the Apple App Store or Google Play Store, and probably inspired them as well.

So who actually runs these systems?

The Supporting Cast

The moment you release your program, it becomes part of an ecosystem that is continually evolving, changing, and growing. Your dependencies get updated, your users find bugs, your contributors want to add features; the repository’s publishing process may add security requirements, the package manager may change the way you specify dependencies, and other packages that depend on your program may break when you update your code.

Someone has to keep an eye on all this, and that someone is you—at least, until you gather enough contributors. With luck, some of these contributors stay; they use your program, they like it, they become dependent on it, they are happy to help make it better. Sometimes they are not even users, just enthusiasts with a big heart. The large majority of them do this for free; they are maintainers, the unsung heroes of the software community. They help review contributions from other developers, update dependencies, write documentation, answer questions from users, and even fix bugs. They are the caretakers of the codebase, the stewards of its health and longevity. Without them, the duty of keeping the software ecosystem running smoothly would fall on the original author alone, which is often an impossible task.

As an example, Python’s package repository PyPI (Python Package Index) hosts over 500,000 packages and is maintained by a small team of volunteers who ensure the infrastructure runs smoothly, moderate packages, and respond to security issues—all while the Python language itself is maintained by a core team of developers who guide its evolution.

Taking Care Of Your Users

Despite all the challenges of programming on your own, writing code for yourself is the easiest part of being a programmer. You run the code, it works; you’re done!

Once you distribute your code and other people start using it, you eventually start getting bug reports. “I’m getting an error when I try to run your program.” “The program crashes when I click this button.” “It says ImportError: No module named ‘funnyname’.” You’re at a loss, because you didn’t face those problems—”It worked fine”. Now you have to ask each user: “What operating system are you using? What version of Python do you have installed? Did you install the dependencies? Which versions? Can you show me the full error message?” Suddenly, you’re not just a programmer; you’re also a support technician.

Perhaps you’ll have a little more sympathy the next time IT support staff ask you myriad, seemingly trivial questions about your computer setup when they try to help you with a problem.

Handling Contributions

If you’re lucky, you’ll suffer even more success. Your program catches the attention of other users who are also developers. They get impatient with a bug or want a new feature, so they fork your codebase (despite the name, that just means they create a personal copy of it), make some changes, and now they want to contribute their changes back to your project.

Great—you’ve just become a maintainer and taken on your first code review. You compile and run their code, and as luck would have it, it crashes. Obviously, “it worked fine on their machine”. Now you not only have to figure out how to get your code running on users’ machines, you also have to figure out how to help other contributors set up a development environment that matches yours.

This is why there’s another section of the README file called “Development Setup” or “Contributing”; if your project is old enough, CONTRIBUTING might even be its own multi-hundred-line document. It explains how to set up the development environment, what dependencies and versions to use, how to run tests, and how to submit contributions using git, the version control system used by developers worldwide.

Nevertheless, congratulations! You are now firmly a part of the software ecosystem.

The Software Ecosystem

Programs depending on other programs, humans depending on other humans, code depending on other code—all these dependencies create a complex web of relationships that we call the software ecosystem. You thought it was just about you, your computer, and the code. But the first time you submit a pull request—a request to merge your changes into someone else’s codebase—you realize that programming is a social activity, and that the ecosystem is as real as the code itself. You’re working not just with systems of code, but with systems of trust.

Each project has a history. Each codebase has developed its conventions. Each community has decided on their norms. Navigating this ecosystem requires more than just technical skill; it requires empathy, communication, and collaboration. Your integrated development environment (IDE)—the program you use to write all your code—is a project with its own contributors and maintainers. The platform where you host your code—another project with its own contributors and maintainers. The libraries you use—each with their own contributors and maintainers. The package managers, the version control systems, the continuous integration pipelines—all these tools are part of the ecosystem, and they all have their own communities.

Writing For Humans

You look at your codebase again and realize: that code isn’t just for computers to compile. It’s for humans to read, understand, and build upon. You have actual users, actual contributors, and actual maintainers reading it, trying to make sense of it, and then contributing to it. You didn’t write a book, you created a living, breathing document that is simultaneously a record of the past, a blueprint for running the present, and a frame for the future.

With a renewed sense of responsibility, you start to think about how to make your code more accessible. You add documentation explaining the purpose of code. You add annotations specifying the datatypes you are dealing with. You add code comments giving context to seemingly obscure decisions and logic. You adopt established conventions and patterns that make your project more legible to would-be contributors.

You’re not a beginner anymore; you’re becoming a responsible member of the software ecosystem.

Conclusion

Programming is not just about writing code that works; it’s about writing code that others can use, understand, and build upon. The software ecosystem is a complex web of relationships between code, developers, users, and maintainers. Navigating this ecosystem requires more than just technical skill; it requires empathy, communication, and collaboration.

You started wanting to share your code, and you learned you have to share your thinking as well.