Flutter databases –  sqflite, hive, ObjectBox, and Moor

Flutter databases – sqflite, hive, ObjectBox, and Moor

Flutter is becoming a serious developer platform and with it grows a need for Flutter databases. A quick note on Flutter and Dart as it is pretty young and you might either be looking for a Flutter database, a Dart database or truly a Flutter Dart database. Flutter is an open-source UI software development kit created by Google. Dart is the programming language in which developers code Flutter apps. Dart is an object-oriented programming language. 

Flutter databases / Flutter Dart data persistence

While the database market is huge and dynamic,  there are only few options to choose from if you are a Flutter / Dart app developer. Before we dive into the Flutter database options, advantages and disadvantages, we’re taking a very quick look at databases to make sure, we share a common ground. Accordingly, we’ll not get theoretical and extensive, but focus on what we mean here. 

What is a database?

A database is a piece of software that allows the storage and systematic use of digital information, in other words: data persistence. A database typically allows developers to store, access, search, update, query, and otherwise manipulate data in the database via a developer language or API. These types of operations are done within an application, in the background, typically hidden from end users. Many applications need a database as part of their technology stack. The most typical database operations are CRUD: Create, Read, Update, Delete.

What are the major types of databases?

There are many types of databases. For our purpose, the most important differentiations are non-relational (NoSQL) versus relational databases (SQL), cloud databases versus edge databases, and maybe embedded versus in-memory. However, databases can be further distinguished by additional criteria e.g. the data types they support, or the way they scale – and definitions can vary.

What is an ORM?

An Object relational Mapper (ORM) is not a database. We’re bringing this up mainly, because we see it confused often. It is a layer that sits on top of a database and makes it easier to use. This is typically especially relevant when the database is a relational database (SQL) and the programming language used is object-oriented. As noted above, Dart is an object-oriuented programming language.

The Flutter Dart data persistence landscape

At this point in time, the database landscape for Flutter Dart is still very limited. So, let us quickly introduce the current market players. Note: We are adding in Moor, because with that few player it is just one more option available and therefore, at this moment in time, should be part of the Flutter Dart data persistence landscapes, in our minds.

  • Firebase Realtime DB is a cloud-hosted database. It stores data as JSON and synchronizes it to connected clients.
  • Hive is a lightweight key-value database written in Dart for Flutter applications, inspired by Bitcask.
  • ObjectBox DB is a highly performant lightweight NoSQL database. It stores objects.
  • sqflite is a wrapper around SQLite, which is a relational database without direct support for Dart objects. 
  • Moor is a reactive persistence library for Flutter and Dart, built ontop of sqlite. 

 

What is the best Flutter Dart database?

This of course depends… Make up your own mind with the following comparison matrix as a starting point. Note: With very few options to choose from, the following overview is sometimes a bit comparing apples🍎 and pears🍐.

 

Data persistence Description Primary Model Location of data Language License Fun Fact
Firebase Realtime Database Mobile Backend as a Service (MBaaS) NoSQL Google Cloud Dart Proprietary acquired by Google in 2014
hive Light key-value DB for Flutter NoSQL local Dart Apache 2.0 Munich brew
ObjectBox High-performance Flutter DB NoSQL local, self-hosted server / cloud Dart Bindings are Apache 2.0 Munich-brew out-of-the-box data sync solution
sqflite SQLite plugin for Flutter relational local SQL SQLite is public domain, sqflite lib is MIT good old SQLite
Moor ORM for SQLite used on top of a relational DB local Dart SQLite is public domain, Moor lib is MIT Room spelled backwards

 

<p>Diese Seite verwendet Frames. Frames werden von Ihrem Browser aber nicht unterstützt.</p>

Flutter Database performance benchmarks

As with any benchmark, you need to take a look at the details. We take benchmarking very serious and strive to get accurate results. Therefore, we also always open source the benchmarking code and encourage you to check it out. If you note anything that does not even out in your oppinion, do let us know. We have a long history of updating and improving our benchmarks continually and are happy to take any recommendations.

Performance Benchmark Test Setup

We used an Android 10 device with a Kirin 980 CPU to run the benchmarks as a Flutter app. The app executed all operations (ops) in batches of 10.000 objects. Each batch formed a single transaction. We ran each test 50 times. The results you see in the diagram are averages across all runs. We set it up that way to ensure that neither the Virtual Machine warmup during the first run nor the garbage collections affect the overall result significantly. 

Flutter Databases CRUD Performance Results

Flutter Database Performance Benchmarks

Summary of the Flutter Dart DB Benchmarks

Hive and ObjectBox clearly outperform sqflite across all CRUD operations. The results show ObjectBox performing with up to 70 times the speedup for create and update operations. With regards to comparing Hive and ObjectBox, the results vary more. Hive can be faster at reading objects than ObjectBox. However, strictly speaking it’s not a fair comparison, because in Hive, the high read numbers result from Dart objects already cached in memory. If the objects are fetched using the async API from disk, the numbers drop by factor 1000.

As a cloud-based online database, Firebase is not really comparable. Local data persistence, an edge database, will typically always beat a cloud-based solutions with regards to response times. But of course cloud-based solutions have their own advantages and there may be reasons why you would choose to use Firebase over an edge database. It still may be a great option for you, depending on the use case.

Moor was not part of the benchmarking as it is an ORM. However, it is very likely it will perform similarly as sqflite, reflecting primarily the performance of SQLite.

Flutter and Data persistence landscape Conclusion

Flutter is becoming a serious developer platform and developers need a data persistence solution. There are currently only few databases supporting the Flutter community and 2021 will be an interesting year to watch where this is going. If you are interested to learn more about the database space, DB-engines and the database of databases are great starting points. Otherwise, go, check out ObjectBox Dart for Flutter Dart and share your thoughts with us – it’s not too late yet; we are shortly before releasing 1.0 and your feedback counts 🙂

Introducing: ObjectBox Generator, plus C++ API [Request for Feedback!]

Introducing: ObjectBox Generator, plus C++ API [Request for Feedback!]

We are introducing the ObjectBox Generator today to simplify ObjectBox development for more programming languages, starting with C/C++. Additionally, we are releasing a brand new C++ API that goes hand in hand with the new generator. Historically, our C API was rather low level as it was focused on providing the foundation for our Swift and Go APIs. With this release we want to provide C/C++ developers with ObjectBox convenience and ease of use. 

ObjectBox Generator takes over the burden of writing the binding code and data model declaration. Based on a single input file, it generates the code for you, so you can focus on the actual application logic.

Generator Example

ObjectBox let’s you handle data as FlatBuffers. For example, you can put and get data objects as FlatBuffers encoded bytes. To work with FlatBuffers, you need to define a FlatBuffer schema file (.fbs). And this file is also the input for ObjectBox Generator. This way, everything is defined in a single location.

Let’s say we have a FlatBuffers schema file “task.fbs” with the following content:

Now, we can tell ObjectBox Generator to use this file to generate C++ sources:

This makes ObjectBox Generator to generate the following files:

  • objectbox-model.h: source code to build the internal data model, that you need to pass when creating a store.
  • objectbox-model.json: keeps track of internal schema IDs; you don’t need to worry about this except that you should put it in your source control.
  • task-cpp.obx.h: the C++ value structs (data objects), binding code for FlatBuffers and the new Box class.

C++ API Example

Now, let’s use the previously generated code and the new C++ API around the Store and Box classes. A simple CRUD application boils down to a few lines:

Note that the generated code is header-only and compatible with the existing ObjectBox C-API, allowing both to be used from the same application. The C and C++ APIs both have unique advantages: the C++ API uses RAII so you do not need to worry about cleaning up, while the C API has additional features, e.g. queries.

Open Source, Docs

ObjectBox Generator is open source and available on GitHub. The repository comes with a readme file that also serves as a documentation. Among other things, you will find ObjectBox specific annotations there, which are used in fbs files to express ObjectBox-specific concerns. For example, in the definition of Task above, we used ulong as a FlatBuffers type to store dates. However, FlatBuffers does not know what a date is and we use ObjectBox annotations to express this:

For our initial release of ObjectBox Generator and the public C++ API we decided on labeling it as version 0.9. Although we are already very close to a 1.0 and we wanted to gather some feedback before our first major release. As we can still change the API or smooth out any rough edges you may find, we cannot stress enough how much we welcome and appreciate your feedback at this point. Thank you!

ObjectBox EdgeX v1.1 – database with ARM32 support

ObjectBox EdgeX v1.1 – database with ARM32 support

With EdgeX Foundry just reaching v1.1, we continue to provide ObjectBox as an embedded high-performance database backend so you can start using ObjectBox EdgeX v1.1 right away. If you need data reliability and high-speed database operations, ObjectBox is for you. Additionally, starting with ObjectBox EdgeX 1.1, you can use it on 32-bit ARM devices.

Combining the speed and size advantages of ObjectBox on the EdgeX platform, we empower companies to analyze more data locally on the machine, enabling new use cases.

With ObjectBox-backed EdgeX we’re bringing the efficiency, performance and small footprint of the ObjectBox database to all EdgeX applications. It is fully compatible, so you can use it as a drop-in replacement: you call against the same REST and Go EdgeX APIs. As simple as that;no need to change any code.

Performance comparison of EdgeX database backends

EdgeX Foundry comes with a choice of two database engines: MongoDB and Redis. ObjectBox EdgeX brings an alternative to Redis and MongoDB to the table.  Because ObjectBox is an embedded database, optimized for high speed and ease of use while also delivering data reliability, it enables a new set of use cases. As we all know, benchmarks are hard to do. This is why all our benchmarks are open source and we invite you to check them out for yourself. To give you a quick impression of how you could benefit from using ObjectBox, let’s have a look at how each compares in basic database operations on “Device Readings”, one of the most performance intensive data points.

ObjectBox EdgeX
ObjectBox EdgeX

Note: The Read and Write operations (all CRUD (Create, Read, Update, Delete) operations are measured in objects / second). The benchmarks test internal EdgeX database layer performance, not the REST APIs throughput.

These benchmarks provide a good perspective why you should consider ObjectBox with EdgeX. Benchmark sources are available publicly in ObjectBox EdgeX github repo.

So, why is ObjectBox EdgeX faster?

First of all, you are probably aware of the phrase “Lies, damned lies, and statistics benchmarks”. Of course, you should look at performance for yourself and consider based on your specific use case needs. That’s why we make our benchmarks available as open source. It is a good starting point.

To make it easier to compare ObjectBox (in addition to our open source benchmarks) here are some of the high-level “unfair advantages” that make ObjectBox fast:

  • Objects: As you can derive from its name, ObjectBox is all about for objects. It’s highly optimized for persisting objects. The EdgeX architecture and Go sources are a great fit here as it puts Go’s objects (structs) in the center of its interface. This means, we can omit costly transformations and this helps with speed.
  • Embedded database: Redis and MongoDB are client/server databases running in separate processes. ObjectBox, however, is running in the same process as EdgeX itself (each EdgeX microservice, to be precise). This has definite efficiency advantages, but it also comes with some restrictions: Whereas you can put Redis/MongoDB in separate Dockers or machines, this option is not available for ObjectBox yet.
  • Transaction merging: ObjectBox can execute individual write operations in a common database transaction. This means, we can reduce the costly transactions for a number of write operations. This is a great way to add on performance, delaying the transaction end by single digit milliseconds.

Get started with ObjectBox EdgeX

The simplest way to get started is to fetch the latest docker-compose.yml and start the containers:

You can check the status of your running services by going to http://localhost:8500/. At this point, you have the REST services running at their respective ports, available to access from your EdgeX applications.

Find more details, instructions for ARM32, and sources in our GitHub repo at  https://github.com/objectbox/edgex-objectbox.

If you’re new to EdgeX, find out all about the open source  IoT Edge Platform here. The EdgeX project is led by the Linux Foundation and supported by many industry players, including Dell, IBM, and Fujitsu.

We love to hear from you ?

We’re very interested to hear about the challenges you are facing on the edge and in IoT. As performance experts, we are always embracing a tough challenge. Reach out to us to set up a pilot project.

Is there something you are missing? Please do reach out to us. We want to make ObjectBox the best edge data persistence layer available. We love to receive your feedback.

What next?

Find out more about ObjectBox EdgeX and get started, go directly to GitHub or download the snap on Snapcraft.

Sync.Drone: a drone in-flight synchronization project

Sync.Drone: a drone in-flight synchronization project

This spring, a student group from Augsburg University of Applied Sciences build a drone application based on ObjectBox Database and Sync. This is a guest blog post by Michelle from the sync.drone project group, describing the project from start to finish and sharing the results. 

The goal: Showcasing the ObjectBox database and Synchronization solution with drones

The goal of the project was to synchronize the colors and flight patterns between two drones coordinating the colours and flight formation autonomously in flight to showcase the ObjectBox Sync solution. Why? For a deeptech database startup it is often hard to demonstrate and communicate the uses of the technology. So, we, a team of students of the FH Augsburg went on a mission to help showcase. Due to ObjectBox’ speed, more data can be processed faster on each drone, saving resources, specifically battery. This allows drones to fly longer, but that really does not have that much sex appeal for a broader audience. However, adding some colorful lights and developing a special kind of light show… Going beyond the scope of a doable student showcase, the technology could be used to synchronize swarms of drones creating beautiful colored messages and patterns in the night sky. While our outlook was more on an artistic installation, such a showcase should also help transfer the application to other use cases, g.g. self-syncing drones could be used in emergency situations during a large-scale search for missing persons. Of course, there are more use cases in the future: Drones can also be used in large warehouses to facilitate the organization of different parts, and pass on the position of a particular part.

In this article, we will explore the process we used to build our self-synchronizing drones, sharing our software and hardware, so you can try it out yourself.

drones that can be synchronized

Hardware: Raspberry Pi, 3D printing, and more

In order to build our drones and turn our vision into reality, we had to consider a number of hardware options. It was important that our drone was compatible and programmable with ObjectBox. The drone had to be localizable and airworthy, so that a safe autonomous flight was possible. All parts had to be compatible so we could easily swap parts if something did not meet our requirements.

We built the drone frame from scratch, using 3D printers. The housing was created in the 3D program Autodesk Inventor and the parts were assembled to a drone frame. We used NeoPixel RGB LED sticks to make the drone glow in color. We chose the following components. 

drones that can be synchronized
drones that can be synchronized

Microcomputer

A Raspberry Pi was the most suitable central computer on our drone. It offered both performance and size. We chose the Raspberry Pi 3 B+, which would later control the processes of our drone independently.

Tracking system 

After looking at different tracking systems, we chose the “POZYX” UWB tracking system. This ensured an accurate and user-friendly handling.

Accumulator

We had to make sure that the drone’s battery would last long enough to power a Raspberry Pi, LEDs and a POZYX tag in addition to the flight hardware. First started with a 6 cell LiPo battery with 5000mAh. However, later in the project, we replaced the battery with a lighter and more compact 6-cell LiPo battery with 1800mAh.

drones that can be synchronized

Engines

The engines (1750 kV) from the Drone-Racing sector had enough power to make the drone fly. Motors with even lower kV would have given the drone more power, but are much more expensive.

Flight controller 

As flight controller we chose the “Omnibus F4 V6” chip, which ran with the open source software “Beta Flight” and was accessible via the so-called Multiwii Serial Protocol (MSP). This allowed us to use the advantages of a proven flight software, and also transfer the flight instructions via USB directly to the flight controller using the MSP.

Electronic Speed Controller (ESC) 

For the ESC , which implements the instructions of the flight controller by direct voltage changes at the motors, we chose a 4-in-1 model. With only one connection cable to the flight controller, all four motors can be controlled at the same time. Usually one ESC is required per motor. It was also compatible with our hardware.

drones that can be synchronized

Software – Tracking, Flying and Syncing the Drones

Except for a start signal, the drone was supposed to operate without a remote control. Several drones would coordinate themselves at the same time according to the instructions. We decided to develop the code in three separate “cores”, which were merged at the end of the project. These were divided into “tracking”, “flying” and “syncing”. Using the university git lab as a repository, we were able to simplify development and share the code with the group. This allowed structured work on the code. With the help of ObjectBox and Prof. Dr. -Ing. Alexandra Teynor we were able to assemble the following code parts.

Tracking 

For collision avoidance it was important to implement tracking, so that the drone knows it’s own position. We solved this by using the position calculated by the POZYX tag, which was then transmitted to the Raspberry Pi in the tracking core.  We read the coordinates from the IMU sensors (“inertial measurement unit” = unit of measurement based on multiple sensors ) from the POZYX tag, but not the exact positioning.

The so called “heading”, or yaw of the drone, is read out by a magnetometer. However, this internal “compass” reacts to disruptive factors and can deliver inaccurate results. We solved the correction of the heading via an algorithm using OpenCV. This algorithm uses a small camera module on the drone and special markings on the ground to detect its orientation. This allows the direction vectors of the drones to be calculated more accurately.

drones that can be synchronized

Flying

In the flying core, the flight instructions were developed based on the tracking core data, and then implemented by passing this data on to the flight controller. First of all the drones have to be lifted off the ground. For this purpose we used a laptop keyboard control, which forwarded flight instructions to the drone via a web socket.

Flight control

The Raspberry Pi establishes a serial connection to the flight controller via USB. As soon as this connection is established, flight instructions are transmitted in the form of inclination values for roll, pitch, yaw and throttle (thrust). These values may lie between 1000 and 2000. In a neutral position, roll, pitch and yaw are at an average value of 1500.  

Using Python, we calculated the required roll, pitch, yaw and throttle values and assembled them using the Multiwii Serial Protocol. This was translated into pure byte code and sent to the flight controller via the USB cable. The flight controller now tries to reach the corresponding values. In order to turn to the right, the left motors are turned slightly up and the right motors slightly down. The ESC received the commands for the desired motor speed from the flight controller. It then applied the required voltage to each motor according to its instructions. The communication between the flight controller and ESC happened either by an analog (PWM) signal or a digital signal (D-Shot).

Keyboard control 

The computer runs a Python script that registers keystrokes and converts them into instructions. For example, pressing the right arrow key creates the command “raise-roll” and pressing the left arrow key triggers the command “lower-roll”.

The drone also runs a Python script that opens a web socket to which the PC script connects. Each time a key is pressed on the laptop, a corresponding command string is generated (e.g. “raise-yaw”) and sent to the drone via the web socket. As soon as a string arrives, the relevant value (roll, pitch, yaw, throttle) is increased or decreased.

To prevent the drone from crashing if a connection is lost, the values are flattened algorithmically.

ObjectBox Database and Sync Drone Implementation  

In the syncing core, the position data of all drones as well as the LED color, should be exchanged and commands passed on. The RGB color space of the LEDs was mapped to the x-, y- and z-position. In this way, the sync features of the drones could be displayed without them flying. For the implementation we used the ObjectBox database and the ObjectBox Sync Server.

Originally, we had planned to use the ObjectBox Go Binding because it is precompileable and very fast. However, the POZYX system we chose used Python. There was also already a Python implementation available for our flight controller, but none available for Go. Luckily, ObjectBox offered to develop and provide a small Python binding of their database according to our needs. This included all ObjectBox functions that were relevant to us. It was officially released in version 0.1.0 specifically for our project. As a result, the ObjectBox database could be easily integrated into our code.

Realization of syncing

In Python version 0.1.0, ObjectBox incorporated the basic features we needed. For our application the simple CRUD functions and the Sync feature, which synchronizes the data in near real time, were sufficient. The database is compact and the speed and ease of use is optimized for restricted IoT devices, for example the Raspberry Pi used in this project.

The sync server is started by running the init-server.py script on the master drone. At first, an empty database (model) was initialized. The master drone then communicates with the other drones via WLAN network connection and synchronizes the ObjectBox database between the respective devices.

Three entities (classes) are stored:
– the identification and position data of the anchors
– the identification and position data of the tags
– the color values of the LEDs.

The drone stored it’s position and LED color in the database. The master drone then reads out this information and overwrites it  with the values calculated by the master drone (e.g. LED color or target position in the future).

sync drone

Thank you!

At the end of our project, we had three drones. Depending on the position of the master drone, all drones could synchronize their LED colors. Unfortunately we were not able to finish the flight due to a defect in the flight controller and a delayed delivery of parts. Finally we decided to publish the code for the drone control on GitHub. Additionally, you can get inspired on our website as well as on our social media platforms. 

Furthermore, we would be happy, if the project would be continued by another group of students in the future. With our work we have created a basis for many more ideas. In summary, our project still has a lot of ambitious potential for the future.

Thanks to ObjectBox for this great opportunity – we mastered many problems along the way and learned a lot. Thanks for the constant support.We also thank our professors Prof. Dr. -Ing. Alexandra Teynor, Prof. KP Ludwig John and our coach Sandra Hobelsberger for their professional advice and patience. Finally, we would like to thank HSA_Innolab for their additional financial support and FabLab for their advice and resources.

In collaboration with interactive media students of the University of Applied Sciences in Augsburg.

 

sync drone team
sync drone projects
sync drone projects
sync drone projects

ObjectBox Swift Binding Open Sourced

ObjectBox Swift Binding Open Sourced

Today’s 0.9 release is not just a step closer to 1.0, but also an important milestone for us: for the first time, all Swift binding source code is available on GitHub. We’ve also improved performance (again) and added useful features like type converters.

ObjectBox’ lightning-fast database offers a cross-platform C API for language-specific bindings. These bindings provide a thin and nimble wrapper around the C calls and expose ObjectBox functionality in the way that feels most natural to the host language (i.e. Swift).

An open-source binding allows you to make changes to ObjectBox and build it on your own, backport it to older OS or Swift versions, and contribute your changes back to us if you feel so inclined.

Is this the binding I’ve been using all this time?

Although it’s one of our newer language bindings, our Swift binding already has a storied and colorful history. The first Swift binding actually predates our C library and was built directly against the core C++ codebase. As such, it used Objective-C to bridge Swift and C++.

Once we had the C library, we set about eliminating the intermediary and started rewriting the central Objective-C portions as pure Swift on top of the C API. The immediate result when we released ObjectBox for Swift 0.8, was a significant speed-up in write operations due to Swift’s new native UTF-8 strings, and struct support.

But for the open source release, we completed this rewrite, and ObjectBox Swift got even faster:

ObjectBox Swift Open Source

Not having to bridge to Objective-C meant we could take advantage of Swift’s associated types to resolve class/entity associations instead of a runtime look-up, and eliminate a few duplicated classes necessitated by adding Swift features to Objective-C classes. This in turn allowed removing some unnecessary data copying, which translated directly to increased speed.

While we enjoy a good performance increase as much as the next database developer, we also added new features and fixes, like more query comparison operators for scalar types, and improved behavior when adding properties to an entity.

Property Converters

One major new feature of this release is support for converting simple user-defined types into types the database understands. For example, you can mark any RawRepresentable enum with an annotation to tell ObjectBox how to serialize it. Let’s say we have an enum like

In your class, you simply add the following annotation:

But of course we also let you work with your own types, or system types. Let’s say you wanted to save a window’s dimensions into your database. You do this using a converter class that implements convert() methods that convert your custom type into one of ObjectBox’s built-in types, and back:

And then you tell ObjectBox to use that converter using an annotation:

That’s it.

And that’s just a selection of the changes you’ll find in the new open-source release. It contains the entire binding, but also the fork of Sourcery that does its duties as our code generator, and a performance test app. It is faster, more feature-full, and we’ve also squashed some bugs in the binding.

To take a look and get started, simply go to our ObjectBox Swift Git repository, where, in addition to our example application, you can now also find the binding’s source code. Or pull version 0.9 via CocoaPods.

We can’t wait for you to try it out and let us know what you think. Don’t forget to star us if you like it!

GitCoin: Harnessing the Power of Blockchain for Open Source

GitCoin: Harnessing the Power of Blockchain for Open Source

Gitcoin is used by nearly 50,000 developers and delivered more than $6.5mm 💰 to open source developers around the world in 2020 ❤️. The topic of sustainability of Open Source and means of securing funds for independent open source developers has been of increasing concern and discussion in the open source community. As a response, Microsoft launched GitHub Sponsorhips, which provides an alternative, but has seen disappointing results for open source developers by and large so far. However, another new initiative aims to support active and good open source citizens: GitHub Stars ⭐. While this does not pay the rent, it helps get people that provide great software and know-how for free, the attention they deserve 🤗. Unfortunately, the process on what happens with nominations and who chooses the stars ultimately is a bit unclear. I definitely submitted three of my GitHub rockstars, but never heard back and none of them has been chosen so far 🤷‍♀️ (all have fairly successful repos, a ton of stars and are considerate open-minded people judging from their online communications). Possibly also leading to more GitHub Sponsorships being made. 🤞

In 2018, Vivien had the chance to chat with Kevin Owocki, about his latest project GitCoin, and the intersection of open source and blockchain. A lot of what Kevin said is timeless and has been an even more relevant question for the open source community in 2020.

Kevin Owocki

Kevin Owocki

Startup entrepreneur, founder of GitCoin
Vivien Dollinger

Vivien Dollinger

Founder and CEO of ObjectBox

Vivien: Hi Kevin, thanks for talking with me today. Why don’t you start by telling me about yourself and your current open source project, GitCoin?

Kevin: I’ve been a startup entrepreneur over the past ten years, and all of the businesses that I’ve built on or built have been based off of open source software. One of the things that I’ve learned is that value accrual goes to the application layer, to the data that you’re collecting about marketing, and the services that are built on top of the software. Gitcoin is my current project, and its mission is to grow open source. Our thesis is that Blockchain is a game changer for open source funding. There’s so much money in Blockchain right now because of the 2017 Bull market… billions of dollars chasing too few developers. And that creates an opportunity for developers to monetize their work in open source software. Gitcoin is our core product and it’s basically a double sided market: people who want to augment their team can hire talent on a per-issue basis. So, it’s less commitment than hiring someone for a contract. On the other side, developers get to work on issues in open source, learn new skills, meet new people, and get paid using cryptocurrency. We incentivize developers to work on their open source software. The second product that we just launched is called CodeFund, kind of like a sub brand that we’re working on. Basically, it is ads on documentation sites that are aimed at open source developers. So the idea is that if you have a following for your open source repo, you can create passive income by putting ethical advertisements. These advertisements don’t track your users on your documentation site or on your Github and they sustain your open source with passive income. This is a long way of saying that we think Blockchain is a game changer for open source funding and are trying to build the rails for capital deployment to open source projects.

Open Source

Image Source: Freepik

Vivien: We work in the worldwide market where laws are different, e.g. EU vs US. Do you have support for the contracts?

Kevin: Each project kind of has its own license, and we have a repo setup guide where we ask people to add contributor guidelines, licenses, stuff like that. If you look at the Gitcoin terms of service, it basically says that if you develop for this repo, then you are assigning rights according to their license. But the worldwide nature of all of this stuff is very interesting because enforcing IP agreements, from Germany over to the US, there’s not really a court of law that handles that, so we’re kind of waiting for the legal system to catch up in that respect.

Vivien: You’ve built all your business on open source. What do you recommend to other people looking to build on open source?

Kevin: I think it depends on the nature of your business and whether or not open source can accelerate it. For me, I’ve built a lot of B2C companies, and leveraging open source data stores and open source web servers worked for me, but if I was a risk averse financial institution, then I think it’d be different, right?

We think Blockchain is a game changer for open source funding and are trying to build the rails for capital deployment to open source projects.

Kevin Owocki

Founder, GitCoin

Vivien: Why did you choose to always build on open source? What do you think is best about open source?

Kevin: I think that open source tools with an active community are the ones that are going to have the need for developers, because they have support, and support isn’t monopolized by one company. I think that because of the scale of development today, if you have a problem with an open source repo, you can likely search it and find someone else who’s had that problem in the past. I actually just watched Revolution OS, which is an interesting documentary about the free software movement. Then later the open source movement, and it made a really interesting case. Just focusing on creating great software, and not worrying about the RM and licensing of that software, you can get it in the most hands possible. This includes people who are focused on creating working software over comprehensive documentation or licensing, and therefore that tends to create the best software over time. I think those are all reasons that I’ve been doing it, but it’s very much a cultural thing in startups these days. I think if I’d been born a generation earlier, maybe we’d be singing the praises of Microsoft Visual Studio or something like that, but it’s a generational thing, you know?

If you’re an open source developer… it’s about more than good compensation, it’s about doing work that aligns with your values, and has an impact on the world.
Kevin Owocki

Founder, GitCoin

Vivien: So, you use open source projects as a basis – what is your business model?

Kevin: Well, in my prior businesses, we would build off open source but our software itself was proprietary. We sold it with various degrees of success (laughing). I think for Gitcoin we’re still figuring out the business model, so I’m in awe a little bit, about that, but it’s basically a question about where the value accrues in the network. Our core thesis is that by focusing on being open source, we can make our product as good as possible because we have the most contributors. We think that the value accrues in the brand, and the relationships with the customers. So, while anyone can fork Gitcoin and copy it if they wanted to, then they wouldn’t have our network of developers, they wouldn’t have our mission and our ethos, and they wouldn’t have the relationships with the people who are going to deploy the capital. So, I think it’s very much a work in progress, but that’s a strategy at least, Gitcoin is less than a year old so that’s the strategy in year 0.

Vivien: But you’re already quite big, right? How many users do you have?

Kevin: We’ve got about 7,000. We’ve benefited from being well funded by consensus, but I wouldn’t say we’re super big yet, the open collectives of the world have hundreds of thousands of users and so I think, that to me is big. I think we’re still a small startup.

Vivien: What types of projects do you think you’ll be mainly supporting? Like big company type of open source projects?

Kevin: If you picture a Venn diagram of open source software and Blockchain, we’re in the center of that Venn diagram, and it means that a lot of the people we fund are kind of like Blockchain hipster types, to be honest. I think eventually we would like to go into the broader open source community, and traditionally that’s been monetized with big corporate types, and so I think there’ll be a cultural shift and maybe a little bit of a brand shift as we do that. But that’s very much a year 2 or year 3 thing, there’s plenty of money in Blockchain, so we’re in no hurry to exit that niche at this point.

Blockchain for Open Source
Vivien: So if I have a small open source project, often I struggle devoting my time to it, especially if it’s more of a side project, could I expect to be getting help in your community, and what would I need to expect to pay?

Kevin: One of the things that we found about open source software developers and their motivation is that it’s about more than good compensation. It’s about doing work that aligns with your values, and has an impact on the world. So, if you’re a repo maintainer that wants to incentivise people to work on your repo, having a mission that aligns with your core contributors, and giving them an ability to impact your project are two axes that you can modify in addition to the compensation axis. When you’re seed stage, you want to be working with people that are intrinsically motivated to work on your project. Balancing those intrinsic and extrinsic motivations is really important. If I were talking to a repo maintainer who wants help on their project, I would help articulate their mission, and identify where people can have an impact. Only then would I start thinking about putting Gitcoin balances on their repo.

“There is this paradox with software, that strategic value doesn’t always mean economic value for the authors(…)”
Kevin Owocki

CEO, Gitcoin

Vivien: There’s a whole ecosystem of great libraries that are used by thousands of big companies, yet struggle to maintain their projects due to restrained resources. How can they get paid? Can they get paid?

Kevin: I’ll hedge my answer a little bit and say that I am at the intersection of Blockchain and open source, and I think that Blockchain changes the dynamics of funding for open source. This is sort of outside of my area of expertise, but I do have ten years of experience in working on software prior to doing Blockchain stuff, and so for that reason I empathize with the contributors of these project. They built something that by all accounts brought lots of value for the world. There is this paradox with software, that strategic value doesn’t always mean economic value for the authors, but my hope is that we can solve that problem moving forward. For right now, I would say these contributors could try to put some CodeFund adds up, because if you can earn a couple hundred to a thousand dollars per month by putting ethical advertising in front of your audience, then I think that at least helps ease some of the pain associated with those support requests and feature requests. Right now I think that we’re sort of in the early stages of the Blockchain revolution, and so I can’t say that we have anything immediately up our sleeve, but I hope that things change and turn around for projects like this.