Redechecklist

RDChecklist

Ok, you launched/contribute to a free/open source decentralized project, congrats! Surely you are concerned about it being solid technically. However, that is not enough for the project to be successful and resilient in the mid-term. We suggest here some questions you might want to ask yourselves, and ensure you have covered:

• Who provides long-term maintenance? It'd be convenient e.g. the backup of an organization or institution interested in the project, at least to provide a low-level maintenance.
• Who provides short-term documentation? "It's self-documented" is not a good enough answer. The README should provide a clear description, a quick HOWTO to set it up, and where to find a demo, a tutorial and documentation with additional details. Scanning it in 30 seconds should provide an idea, and spending 30min should be enough to work out how to install/deploy and do it. Providing just in-line code comments is definitely not enough.
• Who provides short-term updates? i.e. not nightly builds but stable releases. "The community" is not a good enough answer: do you have a procedure to do so? who is responsible, in which cases, with which approx. periodicity?
• How can users get short-term support? "Github issues" is not a good enough answer. Is there a contact email? (a list is fine) Do you have a procedure to handle replies? Who is responsible of replying, in which cases? You guessed: "The community" is not a good enough answer.
• Where is essential code and data mirrored? An automatic read-only public mirror is easy to set up, especially if you have everything in Github as you can use GIT for mirroring. Preferably use any other repository to maximize access to your code (some countries don't have access to Github). Mirroring code is not enough: mirroring data is important. Shit happens, and putting all your eggs in one basket is not a good idea. This goes also for anything you may have in cloud storage (including web services and data, taking into account user privacy).
• Where should third-parties (e.g. institutions) trace their usage? "Github" is not a good enough answer. Public metrics would benefit to visibilize the adoption. Some decentralized software may not allow monitoring of all instances (which is good), but still you may inform of those that you know (and are public).
• How are you making sure the developer community is growing?
• How are you welcoming newcomer developers to your community?
• How are you facilitating early-adopter users?
• Have you done user-testing interviews?
• How are you communicating your project to non-techies? (i.e. a Github page is not enough)
• How are you ensuring a healthy community? Recommendation, adopt http://contributor-covenant.org/
• How are you managing the contributor license agreement? Recommendation, adopt https://www.clahub.com/
• Have you contacted the most similar/complementary projects?
• What would happen with the project if the main developer gets bored/burned out/cannot continue? Is there a Plan B?
• Are there quick and clear available materials for communicating the project easily? If the materials strictly need one of the developers to present, then they are not clear enough. Having them allows the emergence of motivated early-adopters act as "ambassadors" of the project.