The choice of words might be unfortunate, but the point is that you don't have to change it any more the PostgreSQL/Nginx in order to use and develop apis with it.
In my experience, most such people just solve this problem by either:
1. submitting an issue to the project's issue tracker, and waiting;
2. submitting an issue to the project's issue tracker, and becoming a project sponsor to expedite;
3. customizing the software using a scripting language it exposes;
4. using a third-party "plugin" for the project that someone else already developed to solve the problem;
5. developing such a plugin yourself, using the software's C FFI API to write your plugin library in your language of choice, rather than the language the software itself is written in;
6. wrapping the software in a single-purpose gateway that decorates or mutates its wire protocol/API with the new features.
In practice, actually modifying the server software itself is very rare. Needlessly rare, even. Some great, clean codebases (Postgres itself; Nginx) get strategies #3-#6 applied so often that there exists a whole ecosystem of features "around" them that really should be in their cores, because everyone was too afraid to touch them even when they're written in common languages.