Zenodys journey into Open Source

6 min readJun 6, 2018

Summary

This document describes how Zenodys will open source the visual platform and defines the Zenodys Github project structure.

Before you start

Zenodys is marketplace to collect, build and monetize digital assets.

This post does not intend to describe the platform from scratch. You can refer to the Technical Whitepaper and Zenodys Open Protocol specification for more information.

Basic terms are:

Digital asset: any kind of product in digital form (data, file, digital twin, code, algorithm, user interface, application, dApp, etc.)
Zenodys Platform: a framework for collecting and developing digital assets and runtime to execute them
Visual Development Tool: IDE (as a part of the Platform) that runs in browser where projects are created by a visual drag’n’drop approach.
Elements: visual blocks, microservices used for creating application logic inside Visual Development Tool. They provide connections (to machines, devices, api’s, databases…), AI and other data processing algorithms, creations of UI’s…
Computing Engine: orchestrating engine that execute workflows made in Visual Development Tool
Component: Code used to implement the Element.

Intro

Our digital world is fragmented and there is still huge amount of assets in analog form. Performance, reliability and security is needed to handle all this complexity efficiently. Zenodys Platform contains the perfect fundamentals for digital transformation, no matter its complexity and size.

Zenodys Platform is not just some idea, beta or MVP product. It has been used extensively in industry environments for the last three years. Proving itself as a reliable and performant tool even for most complex of tasks.

Motivation for open sourcing the platform

If you managed to go through Whitepapers you can get a good picture that Zenodys is a huge project and includes practically every technological branch.

We decided to open source our technology for two practical reasons.

First one is that future can be predicted only if you participate in creating it. We believe that Zenodys Platform is perfect tool for digital assets standardization. And reading standard from open source code is, besides technical documentation, most efficient way for its wide adoption.

Second motivation is value chain monetization. Especially developers have problem with monetizing their code. They all have some developed components that makes their lives easier. But that doesn’t mean that those components, in the form that they have, would make life easier also to other developers.

Current problems

Today the marketplace for trading digital assets, that come in a form of standardized visual building blocks (Elements), doesn’t exist yet. So simple exchange between parties is not possible.

Second problem is component interoperability. There are so many programming languages, interoperable and non-standardized types of data structures from which consumers in most cases don’t benefit.

Let’s take, for example, Python developer who finds predictive maintenance algorithm or component written in C. The prerequisite to start integrating component into project is to be an expert in language in which the component is written. Interoperability between C and Python types must be ensured (for example with ctypes lib). Next challenge is formatting data in component or adopting our project for data exchange. Many things can go wrong in testing phase, like memory leaks. If author predicted that caller will free objects then component must be extended and objects must be freed there (some languages can be limited with memory management operations).

Those kinds of tasks show that integrating nonstandard components can turn into real nightmare, even if we found component that in theory solves our problem.

One of the problems is also monetization through entire value chain. It’s hard to ensure that we are going to be fairly rewarded in all subprojects that our component is going to be used. Especially if more than one developer is participating on same component through value chains.

Zenodys answer to current problems

Let’s see how Zenodys address those problems.

Zenodys Digital Assets Marketplace where you’ll be able to find algorithm, app or even UI in form of visual block and just drag’n’drop it into Visual Development Tool
Zenodys Open Protocol. Zenodys Open Protocol defines standard communication between digital assets. Besides algorithms, applications and code blocks, digital assets can be also real time data streams, historical data, files… Component is on marketplace transformed into Visual Block, called Element. End user doesn’t have to bother what is the language behind Element. Element inputs and outputs are also standardized, so data is exchanged between them in well-known format. Even better — end user doesn’t have to be programmer, because algorithm comes in visual form and all that is needed is just setting the properties.
Blockchain based fair monetization. Blockchain is used to reach transparent and fair monetization. All contributions to components are stored as licences inside blockchain. For every project where component is included, license is automatically validated, and all authors are instantly rewarded by their shares of contribution. By including component into Zenodys environment, author immediately start to benefit from whole ecosystem. For example, end user can combine our predictive maintenance Element with data and user interface Elements from different providers. Component authors don’t need to provide end to end solutions anymore to be competent. Their algorithms can easily become valuable when connected with data sources and UI’s inside Zenodys ecosystem.

Platform contributors

Different user’s profiles can contribute and benefit from Zenodys platform.

Non Developers

Those are project managers and profiles without programming skills. They are contributing by wiring Elements in meaningful application logic and setting their properties. They can also make project requirements with visual workflows and business Elements.

Data scientist and users with basic programming skills

Like non-developers, they are also Visual Development tool end users, but they can also use more advanced Elements. Those are still visual Elements, but instead of simple properties they have properties where snippets of code (Python, R, JS, C, C#…) can be entered.

Element creators

Those are creating visual Elements programmatically, which are then used by end users inside Visual Development Tool.

First steps into open source

We already started to migrate source code from private to public repositories. It’s often a case that some best practices are discovered during project development. In our case this was an over-complex project structure in already complex architecture. Project migration is perfect solution for improving it and we would like to make it as simple as possible.

Currently, two protocol implementations exist. First one is developed in C#, higher level language that offers rapid application development. It’s among the most popular programming languages in the world.

Second one is native C implementation. We like to call it “the beast”, because of its unbeatable performance. It can process millions of data points per second and is ideal choice for running it on smaller devices because of its small footprint.

But not every project deal with data quantity the would require such performance, so programmer can contribute with visual Elements in language that is comfortable in. Currently developers can choose between C/C++ and C#.

C implementation of Computing Engine already contains .NET Core bindings, so .NET Element creators can benefit from running their Elements on Native Computing Engine. Python and Java VM bindings are in progress. But note that performance and portability is decreased when mixing unmanaged and managed Elements.

Github project structure

.NET repository

.NET repository contains .NET Elements and Computing Engine implementations.

ZenEngine folder

ZenEngine folder contains Computing Engine implementation.

Elements folder

Elements folder contains two solution files, ZenElementsDotNet.sln is a project solution for .NET Elements and ZenElementsDotNetCore.sln for .Net Core elements. Folder Common contains implementations for both, .NET and .NET Core Elements.

Main implementation differences are callbacks called from Computing Engines. Those calls are separated with preprocessor directives.

Beside Common folder, there are two more, NetCore and NetFramework. Those contains .csproj files which link files from Common folder and are used to build Elements.

Common folder

Common folder contains interfaces, shared between .NET Computing Engine and native callback helpers for .NET Core Elements.

Libs folder

Libs folder contains libraries, shared between different Elements (JSON, ZWAVE, Modbus,Excel…)

C/C++ repository

C/C++ repository contains C/C++ Elements and Computing Engine implementations.

Directory structure is similar to .NET repository structure.