We do not have clear owners or well-defined processes or structures for a lot of important aspects of the Interledger project and community. This makes it hard for newcomers to figure out how to contribute and means that some key pieces of the project are not being properly maintained.
I would propose that we come up with some processes or structures for governing and maintaining:
- Protocol specs (Interledger RFCs repo)
- Interledger.org
- forum.interledger.org
- Interledger.js
- Hyperledger Quilt (Java implementation)
- Interledger.rs (Rust implementation)
- Community events and calls
A couple of specific problems I would highlight are:
- Without a clear process for proposing new protocols or updating old ones, some Pull Requests go for weeks or months without comment. Also, a few people (probably including @adrianhopebailie, @sharafian, @justmoon, and myself) seem to have an unofficial veto over protocol changes. This may or may not be desirable but either way it should be made explicit
- No one is responsible for Interledger.org and so the documentation is and stays out of date
- We don’t have real moderation guidelines for this forum
- Interledger.js doesn’t have clear maintainers
Each aspect of the project could probably use definition of:
- Who the maintainers are
- What the rights and obligations of the maintainers are
- A schedule for check-ins with the maintainers to see how things are going
- Some dispute resolution guidelines
- A roadmap
- A guide for contributing
What do you think? Ideas, suggestions, or interest in volunteering for a maintainer team?
PS For anyone that hasn’t read this essay before, I would highly recommend reading The Tyranny of Structurelessness.
7 Likes
Hi Evan,
Although I’m new to Interledger, I’d be keen to participate in the ongoing maintenance of the Interledger codebase and specification.
Best,
Sean
3 Likes
I think we can learn a lot from the existing Linux governance models, since users should be able to defect and fork open source projects. Fortunately, one of the core tenets of ILP is to connect all payment networks, so there would be arbitrageurs in the theoretical worst case of userbase forks. It’s certainly not perfect, but as demonstrated in various cryptocurrency projects, governance alone is enough for communities to fork.
For security and accountability, I would like to see code signing from the maintainers. Right now, it’s not much of an issue, but I think this will be a necessity as the community continues to grow. I think this will be especially important for package management via Homebrew, NPM, and Cargo.
For added transparency, I think it would be nice to have sponsors displayed in a repository, but this should be left up to the maintainer’s discretion. Ideally, sponsorships and donations would be routed over ILP. Maybe even including the option to tip upon certain git actions? Contributors could be rewarded for bounties, but it would still rely on a trust basis. h/t @emschwartz 
5 Likes
I will discuss this with my colleague who is well versed in OSS community.
2 Likes
Hi!
Yes, thanks for listing out where attention is required. Essay is interesting in skimming.
The web content/docs would have more contributions if in a simpler-than-html format. At komodo we moved from .rst format (readthedocs) to vuepress (markdown) which the tendermint/cosmos docs appear to be in as well.
Auto deploying to gh-pages definitely good for reducing tech-debt, but with a build pipeline readily available in travis, just as good.
Jekyll for instance is supported by gh-pages too.
The rust implementation will be great. Zcash and komodo use rust for some internals. Wasm benefits also on the radar of possibilities.
With ecosystems like komodo that provide blockchain enforced gateways and a 3rd iteration of their atomic swap DEX network, an ILP integration would be good for liquidity for all involved.
All the best with the upcoming conference
1 Like
Oh I see it is Jekyll. Jekyll supports markdown too…
Though this is a work in progress, I wrote a draft of discussion paper.
I will brush up some more by the summit.
Basically, there are so many themes to discuss, so we have to focus on some important ones.
If this helps, please use at the summit.
2 Likes
Great start! I’m looking forward to figuring out the TBD points!
JFYI, from Open Source Leadership Summit 2018, Maintaining maintainers
