Hello!
I feel like deno is an opportunity to effect change in the JavaScript eco-system, so I'd like to propose, early on, a clear strategy to do that.
I'd like to describe how Free Software communities currently maintain software and how to be friendly with them so that the software is guaranteed a long, useful life of great quality.
How software gets created?
- Developer gets an idea
- Writes software
- Creates and push a package to NPM
- Receives issues on their bug tracker and eventually solves them
How software gets used by developers?
- Developer seeks for a package on NPM
- Developer edits their package.json to use the package
- Write software using the package
- Publish to NPM
Developers expect their package to install anywhere their development environment is, so they often include pre-compiled binaries in their packages for system dependencies for portability. That's "good" for developers, but we'll see later, actually not for anyone else, not users, not sysadmins, and that's whom you develop software for in the first place right?
How software gets used by desktop users?
- User seeks for a package in their GNU/Linux distribution
- User installs package and enjoys it being maintained, updated and integrated with their system
Users care about integration, and continued maintenance so they can depend on it for their tasks. Software doesnt exist in a vacuum, software exists in a system, tools need coherency between each other, they need to take advantage of each other, to form a beautiful system that users enjoy using.
Users learn how to use software and once they learned how some software works they want to be able to never have to learn using something else again unless they absolutely need to.
How software gets used by system administrators who maintain production environnements?
- System administrators are often not many in number compared to the number of users
- They favor low effort maintenance so they can do their work still
What's NPM dependencies for system administrators:
- A complicated burden that doesnt allow them to adapt software to their use case
- Comply with security policies that are their own (and different for each environment because the context changes, e.g. sensitive high security environments vs not sensitive at all enviroments that host no important data)
What system administrators like:
- Software that:
- doesnt change much
- that can be configured enough to fit their use case
- that has a clear maintenance procedure and upgrade path
- is included in the GNU/Linux or BSD distribution they use, and maintained alongside it rather than in a third party repo where it is never tested for their precise environment
What is a GNU/Linux or BSD distribution?
- A maintenance philosophy: rolling release (Arch Linux, GNU Guix, ..), frequent releases (Fedora, Ubuntu, ..), long term maintenance releases (Ubuntu, Debian, CentOS, ..)
- A package manager
- An authority that choses what software is good to include or not based on various criteria
- A place where there is strong icentive for maintainers to continue ensuring software works in the long term (unlike for most developers)
What is a micro-dependency?
- A package that does one single thing and does it well and does only that
- A reusable piece of code
- Often an effort of a single developer that may disappear at any point of time and therefor end maintenance forever
Micro-dependencies are often left unmaintained, and there's no clear way to fork and ensure all software that depended on that dependency gets the now maintained fork because NPM doesnt rule as an authority that makes decisions for package publishers
What are communities and consensus in software development?
- A place where developers socialize and debate how to best write software for the benefit of their users and their own sanity
- A place where there'll always be at least a few developers to maintain the software commonly created by that community
Example of software development (or maintenance) communities are: The GNOME Project, KDE, GNU, each GNU/Linux or BSD distro..
Communities and consensus are needed for long term maintenance rather than atomicity of small reusable packages owned by lone individuals
How to satisfy everyone without changing much of their habits?
Provide mechanism for people to adapt and use software according to their own use case without knowing much about the software itself
For developers:
-
An easy way to share and portably use software from other developers around the world without policies or bureaucracy
-
An easy way to propose software to communities with long term maintenance bureaucracy and policies (like a standard library or other featureful swiss-army knife libraries for a certain topic like boost, glib, ...)
-
Developers like to be able to share and use software freely
-
But developers also like to be able to depend on coherent well maintained software from software communities as well as include their succesful software into these to guarantee them a long and happy future
For GNU/Linux / BSD distros:
- Make it easy to patch software altogether with their dependencies to make integration related changes or other changes related to complying with distro specific policies like patching security vulnerabilities, backporting fixes to old versions of software that doesnt change, etc.. without having to know much or modify, fork, the software you're patching at all. Forking increases maintenance cost for the package maintainer a lot.
For system administrators and users:
- Make both GNU/Linux / BSD distros and developers happy and the rest will function smoothly
- Provide configuration mechanisms to alter behavior and make software adaptable to the different use cases
Software needs happy users to create incentive for long term maintenance and an happy life for the Free Software, if you don't satisfy all involved people, including users, between you and the users, it is detrimental to software being useful for actual users and people
How does this translate in deno?
- Keep dependency management easy for developers using remote URLs
- Create configuration mechanisms to override the URLs with local files or distro packages (e.g. as found by pkg-config) without knowing much about the software at all, without forking repos, and without making any code changes to anything in the dependency tree
- Create an organization that maintains several generally useful software libraries that group together a lot of atomic small packages (most likely by copying code rather than using the actual packages) and maintain them together to provide coherent interfaces and experiences for developers, as well as form a community for continued maintenance of all these little packages together as a group
- Favor consensus and debate towards quality and usefulness rather than isolated experiments that fragment an eco system
- Isolated experiments can happen but they must not be used by developers of software meant for actual use before they get included in the coherent library maintained by the community and get through the quality, debate process, to satisfy all parties and make software the most useful as well as profit from long term maintenance
Other people who more or less say the same thing with maybe different scope: