Value Proposition
The Problem
Mass Collaboration is a proven accelerator for innovation and development. Tools such as Git and platforms such as GitHub and Kickstarter have initiated a convergence of worldwide citizen development that surpasses that of many large corporations.
The problem is that the most successful of these tools - Git - is incomprehensible to anyone outside of software development (and even to some within software development 
) creating a barrier to a broader coalition of stakeholders taking part in development.
GitHub as a platform makes Git marginally more user-friendly and has reaped the benefit with over 40 million active subscribers and 190 million projects (2021). Despite these impressive stats, however, it hasnât really broken out beyond software development.
Miro and other shared whiteboarding platforms appeal to a broader user-base but havenât yet (so far) adopted the open-source development model of Git which is holding them back from mass adoption.
If only there was a product that combined the best aspects of GitHub and Miro into a single product offeringâŚ
The Solution
Jamit.io: Frictionless, Mass Collaboration for Everybody.
Jamit - an easy-to-use, graphical, Git Client that can be used by non-technical people for mass collaboration.
Discussion
Jamit should be a cross between GitHub and Miro, two great platforms for mass collaboration that could be made even better.
GitHub is a mass collaboration platform for coders. It allows anyone, anywhere, and at anytime to contribute to a project and to experiment by taking existing projects in new directions. The system is free to use (for open source projects), offers access to both public and private projects, and allows for portability of core data to other platforms. Users can easily find projects and other users to collaborate with. It provides sophisticated, version control (via Git). It is mainly used for asynchronous collaboration. Furthermore, it appeals only to coders and confuses everyone else.
Miro is a mass collaboration platform for whiteboarding. It allows anyone to brainstorm by drawing pictures, writing notes, and attaching objects from the Web. It can be used for both synchronous and asynchronous collaboration and is fun to use. However, it can be expensive to use, doesnât allow for portability of data (vendor lock-in), and canât be integrated with existing repos (such as GitHub). It does not provide version control (as of this moment). Users cannot easily find open projects or other users to collaborate with, so it is primarily a private, enterprise platform.
Both platforms have a low barrier to entry by providing all their functionality in the Browser and not requiring the user to install any special software. That said, GitHub has a higher learning curve because it pre-supposes knowledge of Git, whereas Miro has a lower learning curve but is less open and extensible.
Github is adding community management tools, whereas Miro is doing very little in this regard. At GitHub, they have sponsorship programs - for projects and coders to get paid - and talent-sourcing / job hiring services.
Neither of these platforms address the collaborative process itself in any depth. Both provide various tools for communication but leave the actual collab methodology up to users to figure out for themselves.
Putting all of this together, here is what a hybrid tool would look like:
- Can be used by anybody for anything (not just by coders or illustrators)
- Runs entirely in the Browser (no install required)
- Free to use
- Fun to use
- Your data is yours (portable)
- Public and Private projects
- Version control
- Synchronous and Asynchronous Collaboration
- Can be used for live events (performant)
- Different workflows for different outcomes (can be community designed and shared)
- Community managed
- Public projects easily allow for branching, forking and experimentation that facilitate evolution towards a complex goal
Strategy
Technology - âIs it ODD?â
The future of the Web is Open, Decentralized, and Distributed. We should embrace these principles as critical to the architecture of our platform.
Open, Decentralized, Distributed⌠ODD.
Open - interoperable, transparent, unrestricted
Decentralized - independent, persistent, secure
Distributed - redundant, cost-effective, performant
Let us use this acronym as a checklist for evaluating new strategies and technologies: Can it be ODD?
2022 Milestones
Open Source
Nothing is more âopenâ than open-source. This is a good strategy for us to attract developers, attract customers, and build momentum. It also ensures that our efforts last beyond our own attention spans. It allows the kernel of our Idea to be taken to places that we couldnât imagine.
While we search for non-technical customers of Jamit, we should target software developers as they, themselves, are a good user-base - if not for the simple reason that they would be modifying the code for their own purposes. We should consider developers, therefore, as a class of âearly adopterâ customers.
We should focus our efforts on producing an open-source version of Jamit. Most likely this will be a self-contained, p2p tool that can be used without consuming additional services. When additional services are needed, we would provide those for a fee. This model is commonly used by other firms which produce an open-source tool while charging for Cloud services that support and enhance that tool.
In addition, we might consider contributing to other open-source projects that are in our interest, either by contributing code or by sponsoring new development that helps us to further our goals. For example, we might pay for 3-6 month open-source projects that add features or extend our tool (e.g. integration with GitHub).
By sponsoring and working alongside other developers in the open-source world, we evangelize our mission while building relationships that made for a more robust ecosystem. Consider this as a recruitment strategy.
Another benefit of open source is to have many eyes (and the brains attached to those eyes) on our projects, leading to cognitive diversity which will only enhance our own efforts. Think in terms of combating the downsides of Conwayâs Law - that designers of the code mirror their own communication structure - so that we need as much diversity as possible to make the solution as flexible as possible.
Git
Git ticks all the ODD boxes. Itâs open-source, can be used peer-to-peer without requiring a centralized repo, and has massive adoption. It gives us version control for free. It is the engine of mass collaboration.
GitHub as a platform has not only extended the functionality of Git for software development but is being used to extend the repo to other, third-party services (e.g. GitOps). By stitching together a string of different services in a CI/CD pipeline, GitHub becomes a chain of functions that results in a unique SaaS platform, tailor made by project managers. This is pretty powerful stuff. We should consider Jamit as a tool that can be snapped into those repo toolchains and leverage the enormous user base of GitHub.
As we aim to appeal to non-technical users, we will need to provide an easy alternative to GitHub. At first, we might provide a simple shared repo backup service. Over time we could use additional services to flesh out the distributed architecture. For example, Fleek allows developers to publish their GitHub repo as a React/Nodejs app onto the distributed file system, IPFS, with just a couple of clicks. We should aim to provide similar one-click integrations.
Another benefit of Git is that it is a Graph database at heart which allows us to capture the deltas between data, objects and users on our canvas. We can also use it to track user metrics, such as the quantity and velocity of contributions - useful for calculating royalties, etc.
I think we should look upon Git as both a repository and as a design discipline towards open, decentralized and distributed Jamming.
Serverless
More of a paradigm than a technology, Serverless pushes us to be as decentralized and distributed as we can be. Early on, it brings additional benefits in terms of cost-performance and security.
The history of the Web is an oscillation between centralization and decentralization but, ultimately, towards an Edge Computing model. Not having to run a server 24x7 but only running code-on-demand by using microservices, functions and/or fast containers makes our solutions performant, scalable, secure, and cost-effective.
Serverless fits into a GitOps strategy of running our Jams as close to the Edge as possible; ideally, peer-to-peer, even.
For now, the best approach is to run code on demand in small containers (e.g. GCP Cloud Run) but the future is coalescing around WebAssembly (WASM).
WebAssembly
To push ourselves into Serverless, we should get involved with WASM as early as possible. It is poised to eventually replace containers (such as Docker), altogether. It is highly portable (can be run natively in the browser, on servers, and as a microservice/function). It is only a few years old, so there is some growing up to do, but it is going to be the future of Web applications.
In many respects, it is Java for Web 3.0 (write once, run anywhere), except that it is developed in a decentralized and open manner, unlike Java (which was owned by Sun then by Oracle).
WASM bytecode is native to modern browsers, so applications compiled to WASM will perform consistently across vendors and it is getting faster all the time.
WASM is not meant to replace Javascript but to work alongside it, mainly being used for applications that require higher performance. This is because the Javascript VMs are different for every browser, resulting in the same code performing very differently from vendor to vendor. WASM does not suffer from this problem and is consistently fast across all browsers.
A bottleneck at present is when Javascript and WASM have to make calls to one another. This is being sped up with every new release of WASM but still represents a choke point, so back-and-forth calls should be minimized. Generally speaking, Javascript calls a WASM module to perform a complex, calculation or function. WASM is sandboxed and ultra-secure, so it must be wrapped by Javascript in a complete Web application in order to access file systems, etc.
The first WASM apps that came along were ports of existing C apps that could be easily re-compiled (via Emscripten, a POSIX emulator for the Browser). A notable example was AutoCad running entirely in the browser. Figma, also, has refactored much of their code into WASM and now hires C programmers to write new code for WASM.
WASM is compiled from a higher order language, such as (currently) Rust, Go, and C#. There is also a native language being developed for it called, AssemblyScript.
WASM will be highly decentralized and distributed because it can run anywhere. It is also being run on the Blockchain (e.g. DFinity) , as there are several firms working to make their smart contract systems WASM-native.
Given that we are a Javascript shop at present, we could consider using AssemblyScript. However, it doesnât seem to have much traction as of yet. Instead, we might consider using Rust or Go which are being adopted for smart contract coding as well giving them more utility in the long-run.
We should also consider using Cloudflare Workers to write short, performant apps that operate as micro services and can also be intergrated within the Cloudflare platform into Blockchains such as Ethereum. This could help jumpstart our Blockchain development.
Blockchain
Blockchain is really important to the future of ODD but I am not sure if thereâs any mission-critical use case for us in 2022. Still, we must be prepared and start priming our architecture for it.
Ultimately, if it could be used to move beyond private platforms (GitHub) towards ODD public platforms then our users could reap the benefits. I think for public jams and projects, Blockchain is a critical use case because it should make it easier for people to work with one another over long periods of time without the threat of interruption - something that is increasingly important when dealing with long-term, difficult to define projects with intractable solutions (e.g. climate change). It would also allow for people to share aspects of proprietary data with a community without exposing everything in its entirety (e.g. OCEAN Protocol) which might increase the range of participants.
When it comes to blockchain technologies, itâs hard to determine a clear leader except for Ethereum due to the sheer volume of dev support that it has and its persistence over time. This past year has been a bumper-crop for high-quality blockchain development. We should aim to keep our architecture as chain-agnostic as possible.
This might not be as difficult as it may seem. For instance, several blockchain developers are creating smart contract services in native WASM. This means that WASM code that we run in a Serverless fashion could be ported over to the blockchain and run from there as smart contracts. This will be important when it comes to transactions involving accounting, identity and finance.
Blockchain is, in effect, taking Edge Computing and Serverless to the next level by making the code itself both distributed and immutable, and therefore inherently trustworthy for secure and mission-critical transactions.
What we should do now, however, is take inspiration from the blockchain projects in order to figure out how to make our architecture more distributed. For example, we might use a P2P protocol between the Jammerâs browsers and use a distributed storage system, like IPFS, to store the files they generate and the shared repo.
On that note, Iâve been very intrigued by the Gun Database because it creates a (supposedly) performant graph db between peers in the browser (p2p). This ticks many of our boxes but I havenât spoken to anyone whoâs tried to use it to scale like we would like to. We should also mention YJS in this discussion, as it has some similar features.
Tactical
Jammit MVP
-
Jamming should be as easy as pointing your browser to a URL. No software to install, no registration required - just enter your email and a screen handle and youâre good to go.
-
If the Jammer is interrupted (e.g. their internet goes down or they have to quit and come back later), they can easily pick up where they left off by using the same URL as before.
-
Everything that a Jammer does is captured and shared with the other Jammers in order to be examined, compared or even merged into a final, coherent series of events.
-
A Jam can be re-jammed or re-worked, making it easy to build upon the work that came before or to backtrack and fork a Jam in a different direction.
Technical Overview
We should strive for Jams to be self-contained, peer-to-peer, browser-based applications that require little to no server interaction.
This means that we want to run as little as possible on servers at our end and push as much as possible to the Edge and to the usersâ browsers - serverless functions, daemons running on userâs machines, p2p protocols, etc.
In the end, our Jamit website acts more as a tracker (e.g. Bittorrent) to help Jammers find Jams, as well as providing community management services for match-making, team-sourcing, making payments, etc.
Jams as Git Graphs
We should use Git as a graph database to store (locally) every state-change or transmutation that a Jammer makes to objects on their canvas. If we think of objects as having attributes and Jammers as changing those attributes during the course of a Jam (e.g. moving cards, writing cards, transforming them, etc) we can commit those changes to the Git graph and then push them to a central repo, such as GitHub or its blockchain equivalent, perhaps with each Jammerâs graph as a separate branch.
For example, we can imagine that each object on the canvas, in the library, in the Jammerâs private hand, has a unique identifier and a set of attributes that can be expressed as JSON or YAML. Whenever there is a change to the environment by the creation of a new object or a state-change of an existing object, a commit can be written (in JSON or YAML) that captures the state-change. (note: we are using YAML at the moment, so letâs stick with that for the time being).
This series of commits then becomes a time-series graph of everything that the Jammer did in the course of the Jam in their local environment by recording the transmutations they make to every object. When the transmuted objects are on the shared canvas then the system or the Jam leader must decide which branch commit to merge (or rebase) to master.
The act of merging / rebasing can be automated - in accordance with the Jam builder rules - or manually by the Jam Leader or group consensus. Some Jam templates may not require a merge-to-master but to show all the branches at once.
When not automated, we use our graphical canvas interface to show what changes have occurred and make it easy to compare and contrast. Branch management is best automated when Jams are synchronous.
By taking this approach, we are essentially a new kind of Git Client that can piggy-back off of an existing shared repo (on GitHub), or create a new shared repo for the purpose of jamming. The data (aka repo) belongs to the jammers; they can take the data anywhere theyâd like.
We should offer our own shared repo service on Blockchain, as well as integrations with GitHub and GitLab. Iâd eventually like us to offer a distributed and decentralized shared repo service, such as the one that Fleek offers for performant storage on IPFS.
Git can be run in the browser thanks to several open-source projects. Take a look at my page, âGit Under the Hoodâ for resources - in particular, isometric-git which ports Git into Javascript and wasm-git which complies native git to Webassembly code.
Note: Git will probably work just fine for asynchronous collab whereas synchronous / real-time collaboration might be challenging. Even if we use a different system for dealing with real-time, I still think we should write the results to a Git repo so that the data is easily portable by the user. In other words, the Git repo becomes a serializer of the data from the Jam event that can be re-hydrated into a Jam again whenever necessary.
In terms of dealing with real-time communications, check out the p2p protocol YJS.