• GITocracy FAQ

last modified May 17 by strypey

Frequently Asked Questions


Q: Why not just use Google Docs, GITHub, or Authorea for collaboration on documents?

A: Both depend on a number of proprietary components, and any data edited or stored on the system could be... anywhere, in any datacentre they decide to host it in. They are both for-profit companies headquartered in the US, and their loyalty is to their shareholders. GITocracy will be built from 100% free code components, and our instance (which will be called something like ' PolicyHub ', 'PolicyFork', or 'LivingPolicy') will be hosted on a server physically located in Aotearoa, or another country which offers significantly better privacy and data protection laws, managed by an independent, not-for-profit, stewardship entity.

Q: Why not just use Etherpad software?

A: Etherpads, like PiratePad.net, work best for temporary use as a kind of online white board, or the digital equivalent of the huge sheets of paper used for taking notes or brainstorming at community group meetings and conferences, and Open Space Technology or World Cafe style events. Spamming or vandalism are always risks of keeping a living document in ongoing development using Etherpad. Although all changes to the contents of a pad are logged, with different colours used for different users, a new colour is introduced every time a user returns to the same pad . There is no built-in way to limit a pad to specific group of authenticated users, whose changes are attributed to a consistent identity (whether real name or pseudonym).  A user can roll a pad it back to a previous version - as they can in a wiki -  but this could be anyone, including a vandal rolling back genuine progress on a document. There's no way to fork the contents of a pad, to try out changes and propose them back for potential merging into the main document, or failing that, maintain a dissenting version as a 'minority report'.

Q: Why not just use CryptPad software?

A: Unlike Etherpads, CryptPabs can be limited to a specific groups of contributors and the in-browser encryption can even be used to make them non-public, while still just as easy as Etherpads to edit from any web browser if you have the pad URL. However, the CPU and RAM demands on the user's computer are very high. It's likely that using a more traditional authentication system to limit edits to a pre-approved group would put less strain on users' computers. Also, it's not clear that Cryptpad documents can be forked and merged as text documents stored in Git can.

Q: Why not just use GITLab?

A: The GITLab user interface is clearly designed for writing code, not text, and learning to use it involves a steep learning curve. Obviously, GITLab is based on GIT, and does offers a free code stack which you can set up on your own server, but like GITHub, this does not contain the source code used for all the features used in the proprietary Enterprise Edition. GITocracy could be built as a new user interface on top of the GITLab back-end, but this would tie us into using Ruby, and it would be a lot of work, possibly not much less than building from scratch on top of GIT in our language/ framework of choice. If there is a GIT-based stack that was designed to be used by non-geeks writing text, it would probably be a better choice to build on.

Q: Why not just use PenFlip?

A: This is designed for writing text not code, which makes it a better candidate in that ways than GITLab, and it is based on GIT. However, source code does not appear to be available under a free code license at this time. Even if it it was released under an appropriate license, the kind of interface that would make sense for policy development would be different to for writing papers or books. Rather than a linear flow of sections or chapters, policy documents could be organised more like software, sets of files, modules that can be re-used and even  co-curated by like-minded groups), grouped into platforms in different ways in the repositories of different groups, and so on.

Q: Why not just use FLOSSManuals?

A: FLOSSManuals, as suggested by the name, is intended for writings books on free code software, not for policy development. BookType, the software behind FLOSSManuals, could be forked, or a policy-specific user interface built on top of it could be an option. It's built in Python/ Django, which is a solid base for long-term development, and source code is available under the GNU AGPL, but it uses SQL databases instead of GIT. Testing will be needed to see if the forking and merging of texts, and other features planned for GITocracy, can be implemented using BookType.

Q: Why not just use ownCloud/ NextCloud?

A: It would be possible to share policy files, whether in progress or completed, using a public-facing, web-based version of one of the many file-sync applications. But since we are only talking about text files, this would offer no major advantage over just putting them on a website as static HTML, or in a standard CMS. A policy hub user interface could be built on top of a file-sync application, but this would not have all the features of GIT, nor the robustness of GIT, nor the fact that GIT can be relied on to stay in active development long into the future, whereas the web is lettered with the corpses of free code file-sync apps that are still foaming in and out of existence because it's such a new area of development.

Q: Why not just use SyncThing?

A: SyncThing is capable of synchronizing files across multiple devices, using versioning. The software engine running behind SyncThing could be useful in building the back-end of Gitocracy. However, it's not clear that it can support forking and merging of different versions of a text. Plus, a very different UI would be needed.