We are pleased to announce that we have open sourced the code base of the community edition of Kezmo.
Kezmo is an enterprise collaboration tool, meant to offer a one stop place to host: conversations, tasks and content (docs, images, notes, links, etc) for work groups. It’s available in the cloud, but can be deployed on premises as well (for instance as a Docker image). The source code is available here. The web client is implemented as a React.js app, while the backend is a Java/Jersey 2.0 based development, that relies on REDIS and PostgreSQL.
The underlying platform, codenamed snowflake, is a customizable framework for implementing chat based collaboration solutions. It can be used to implement a wide range of systems, from custom & secure messaging apps, to project management solutions, to telehealth and virtual practice systems.
The snowflake framework
Snowflake relies in a very simple model of concepts, which are: the (work) space, the container, and the flow.
Kezmo Snowflake Conceptual Model
Spaces
Spaces group conversations and content around one topic. Spaces are pockets of context. One space can be linked to a project, a team, an initiative, a patient, anything as long as all information exchanged in that place belongs to that context.
They are also the granularity level for managing permissions. Users can be invited to spaces as: administrators, collaborators, or readers. Administrators can change the structure of a work space, meaning they can add new containers and flows. Collaborators can add & delete content, and participate in conversations but are not allowed to change structure or permissions. Readers well… they can only read.
Containers
Containers are lists of structured items, called container items. Each item follows a schema, so the structure of information that in can hold is customizable. Container items may have files attached. By default there are container types created for: documents, images, notes, links, issues, and tasks.
Flows
Flows are smart conversations, that can host structured messages, beyond text, such as: images, documents, polls, tasks, notes (actually any container item). One of our design goals was to enable spontaneous interactions, typical of chat based scenarios, while enabling structured content.
For instance, to enable scenarios where you could message something along the lines of … “X document must be reviewed”, only to realize later that that’s a task, edit that line in the conversation and make it a task. Structuring data has a number of benefits. In the case of a task it means you are later able to visualize it in a kanban, assign it to someone, define an expiration date, etc. Otherwise, if everything lives and dies as a text message you are left digging information across a wall of historical messages.
In order to structure a chat line you must type the > char at the end, and will be prompted with available container types options available. You can not only define the type, but load structured fields expected by a container type, such as: assigned to, and start date for tasks.
Kezmo structured chat message as task
Final thoughts
We believe opening snowflake to the community can enable others to build on top of it and come up with new use cases, as well as providing some actors, such as government institutions, and NGO’s an additional level of confidence in the product. If are interested in setting up a Kezmo/Snowflake server and customizing it let us know, we´d be happy to help you.
