April 12, 2019
Calls to Sustainability Action via package.jsona new proposal, schema, and tools
Late yesterday, I submitted a pull request to the npm package manager to add a new, official property to npm’s
package.json manifest files:
The proposal instructs maintainers to set that property to the URI of a JSON resources that conforms to a very simple schema. In a nutshell, the resource maps a project, by URI, to a list of objects about contributors to that project who need or want support. Contributors can identify themselves by name and homepage, indicate whether they’re a person, nonprofit, business, or government entity, and provide URIs for various ways to help, like donating, hiring, buying licenses, or buying services.
Since I’ve already written a number of tools that recurse
node_modules and report metadata, I went ahead and wrote a CLI application,
npm-sustainability that fetches, collects, and reports sustainability data referenced from
package.json files. The tool is similar to others I’ve written, including for License Zero, in that it combines reading data from disk with loading latest data via the Internet to produce an up-to-date report.
For a very simple example of a sustainability record, see the
sustainability.json file in the
npm-sustainability repo. Note that
sustainability.json is not included in the npm package tarball. Rather, the
"sustainability" property in
package.json points to the file as served via raw.githubusercontent.com. As I update
master, the information available to
npm-sustainability and other tools will update, even though
package.json doesn’t change.
Notice also that the
sustainability.json file for the project includes a URI pointer to a data file about me personally, https://kemitchell.com/sustainability.json. That single level of indirection allows individuals and organizations to drop pointers into the data files for projects they contribute to, and update their information without sending PRs to all those files.
Overall, this proposal fits neatly into the general category of creating new channels over which open software contributors can express their needs and wants to users. License Zero achieves the same effect primarily by tunneling through an existing channel: license terms. Projects like Open Collective use service-specific
package.json metadata to show messages on install, and to feed other tooling. I’d like to see npm throw its weight behind an “official” channel for this vital kind of communication, while still embracing experiment, competition, and diversity of approaches.
Having new data about who needs what won’t substitute for a innate drive to right what’s wrong in the dynamics of open source, for users’ as well as maintainers’ sake. But all that information will be mighty handy informing consciences already engaged with the problem. In short, I believe we need a richer environment of communication to get beyond merely talking about how bad it all is for maintainers on the producer side, and how bewildering it all is for users, on the consumer side.
Your thoughts and feedback are always welcome by e-mail.
back to top — edit on GitHub — revision history