My history with Rust goes back a long way. But it was when I really started to understand its enabling potential, its capacity to empower whole groups of people to do things they couldn’t do before, that I just had to find a more direct way to get involved with making that promise a reality.
…And I Mean a Wide Range
My dream is to make Neon:
- Stable: Once we start approaching 1.0, Neon should get on a regular release cycle, with strong commitment to semantic versioning and backwards compatibility.
Just to give you a sense of the many varied kinds of contributions we could use, here’s a taste:
Project management. We should keep on top of issues and PRs. I would love to set up a regular meeting with anyone who’s willing to help out with this! I could also use help setting up a simple RFC process similar to Rust RFCs, especially for having community discussions around API and workflow design.
Technical writing. The guides are shaping up, but they’re incomplete and one of the most important tools for on-boarding new users. The API docs are pretty rudimentary and would benefit from many more examples—we should strive for a high-quality, illustrative example for every single API.
Testing. The test suite has a decent structure but is not at all complete. We should aim for complete test coverage of the API!
Teaching. I would love to get some good thinking into how to teach Neon to various audiences, especially people who are new to Rust and systems programming. We could use this to drive the way we structure the guides, tutorial videos, etc.
Windows development. My primary development machine is Windows these days, but I’m not an expert. I recently broke our Appveyor builds just to prove it! 😝 We’ve also seen some intermittent hangs in Appveyor builds and I’d love a Windows expert to do some investigating!
Web development. The Neon web site is currently a static page. It certainly would be fun to set it up as a Node page using Neon itself! One of the nice dynamic things we could do would be to create a roadmap page like the one Helix has, with automatic tracking of milestone progress using GitHub APIs. We should also set up a Neon project blog with Jekyll and style it consistently with the rest of neon-bindings.com.
Ops and automation. I’ve started an automation label in the issues. A fantastic contribution would be an automated publication script to make releases one-touch. (This is realistically achievable now thanks to some project reorganization.)
Node plugins. We should explore the possibility of supporting using the new N-API as an alternative backend for the implementation. We wouldn’t be able to move to this as the default backend right away, but it could pave the way for supporting Node on ChakraCore, and eventually might replace the current backend entirely.
Scope API less awkward, if possible.
Cargo extensions. So far, the neon-cli workflow has been reasonably successful at abstracting away the painful configuration details required to build native Node modules correctly. But the ideal situation would be to allow programmers to just use
cargo run, and the like to build their Neon crates like any other Rust project. The recent discussions around making Cargo extensible open up some exciting possibilities to push in this direction. One of the ways you can indirectly help with Neon is to help that effort.
Systems programming. One of the biggest challenges we have to tackle is making the process of shipping Neon libraries practical, especially for shipping prebuilt binaries. One technique we can explore is to create an ABI-stable middle layer so that Neon binaries don’t need to be rebuilt for different versions of Node.
Lock API), and running a background
Task as part of the libuv thread pool. There’s more we can do both on the computation side (for example, supporting attaching to different threads than libuv’s pool) and the data side (for example, supporting
Does any of these sound like something you’d be interested in? Or maybe you have other ideas! If you want to help, come talk to me (@dherman) in the
#neon community Slack channel (make sure to get an automatic invite first).
A Note About Community
As the original creator of this project, I’m responsible not only for the software but for the community I foster. I deeply love this part of open source, and I don’t take the responsibility lightly.
Neon has a ton of cool tech inside of it, and if that’s the only aspect you’re interested in, that’s totally OK. Not everyone needs to be passionate about community-building. Still, not unlike Rust, this whole project’s purpose is to widen the circle of tech and empower new systems programmers. So I ask of everyone who participates in the Neon project to strive to act in ways that will encourage and motivate as many people as possible to participate.
Concretely, Neon uses the Contributor Covenant to frame the expectations and standards of how we treat people in our community. Behind the policies is a simple goal: to make our community a place that welcomes, trusts, supports, and empowers one another.
If that sounds good to you, wanna come join us?