In the last month I was looking for a Node.js library for authenticating with APIs that use OAuth 1.0a or OAuth 2.0, and found a pretty good library: node-oauth. It was great but it would have been nicer if it had promises instead of callbacks, and maybe if the OAuth 2 class implemented more methods. I started to worry that the library didn’t seem maintained, there were lots of issues and pull requests that are still waiting for a response or to be merged into the code.
I’ve also been reading Free as in Freedom and The Cathedral and The Bazaar and the hackers of each book, Richard M. Stallman and Eric S. Raymond, both took other projects and improved them and contributed back their changes and improvements to the community. With their maintenance, the projects (Emacs and fetchmail) had vibrant developer and user communities.
So I have decided to basically adopt the node-oauth project under the new name node-oauth-libre. This blog post is the announcement that I’m doing this and yes that means I’ve really forked the code. The node-oauth-libre project uses the GPL version 3, with the original code and patches to the original project licensed under the MIT license.
The goal is to add features that people have wanted and to merge in any pull requests from the original project that can be applied, and more importantly, that bring an advantage to users of the library.
Typically forks only happen when there is a serious disagreement around the design or direction of the project, but sometimes they happen for orphaned projects. In this case there’s not much of a choice: the code is unmaintained and I’m changing to a copyleft license.
Why the GPL? I want to promote free/libre software and have it associated with high quality projects, GPL should be synonymous with technical excellence. I’m betting the new features and patches to this library will be worthwhile that any reservations about the GPL will be ignored.
The GPL should pose no problem to any developers using node-oauth who want to switch to node-oauth-libre. I assume that most people will be using this library on the server side which means that changes and modifications can be kept to themselves (the FAQ says so) . If we were using the Affero GPL that wouldn’t be possible. My intention with the GPL is to encourage developers who distribute their code (such as for client side plugins) to promote software freedom for users. That means if you write a twitter bot using node-oauth-libre and distribute the code then you must distribute the source code under the GPL version 3 or later.
The road map I have planned is for three versions: 0.9.15, 0.9.16, and 10.0.0. What you see below is the current plan as of 29 March 2016 which may change as I find more open issues and open pull requests on the original project which are worthwhile to fix or merge in.
0.9.15: The first things I’m doing are making sure the examples all work, and that the code in the readme works and is fit for copying and pasting into a project. I’m also adding support for promises using the Bluebird library. It’ll be a separate module for version 9.15.0 to ensure backwards compatibility. In 10.0.0 promises should be standard.
0.9.16: I’m planning on adding code that uses the requests library, either as a separate module (since someone has already submitted a patch) or by monkey-patching the existing prototype classes in the same way that’s being done for promises support. The choice is based on need: if developers really want this I’ll merge in the existing patch tomorrow. If it’s not heavily needed I’ll take the time to write code to allow the choice of HTTP request backend as either native or requests. Refactoring of tests will also happen, along with code style cleanup. The idea is to make it easier to contribute to the project.
10.0.0: the promises API should be standard and which hopefully alleviates the need for a sensible API but I doubt it. When I mean sensible API I mean adding or removing methods or renaming existing methods so it’s clearer as to what they do. Most importantly there should be a credentials object that’s passed to the OAuth client, right now it’s a bunch of parameters which are unclear. Tied in with this is documenting the code with JSDoc to generate an API reference, and writing a manual on how to use the libraries with annotated examples. The ability to choose an HTTP backend should also be defaulting to requests in this version.
I really hope my efforts revive the project and make it stable for many hundreds of developers to use.
Want to help? Check out the list of issues and start writing some code or documentation.
Happy hacking!
The post node-oauth-libre appeared first on NeverFriday Software Expertise.