Open sourcing Harriet

First steps

At Field 33 we consider ourselves an open source company. While it’s very easy to say that about ourselves (and many companies nowadays do), it’s far harder to actually execute on it with meaningful actions (“Show, don’t tell”).

There are many ways in which a company can be an “open source company” by participating in the broader open source community, from having the core-product being completely open source to leaving bug reports on existing open source projects to sponsoring the maintainers of open source projects you are using. While we would like to do all of those right now (and have plans to do most of them in the future), we think it’s best to start small and in a way that is sustainable for us right now, and over time expand our efforts with more resources.

As our first step on the journey of Field 33 becoming an open source company, we are open sourcing our first library today: Harriet, our parser & serializer for the Turtle RDF format. We’ve been using it for core parts of our product and internal tooling for a few months and think it’s in good enough shape for external users now.

The Why & How

Harriet is written in Rust, not just because of we believe in the growing community around the language but also because firmly believe it will play a major role in our long-term tech stack. It offers many properties we want in a programming language. Specifically, in the case of Harriet, Rust’s portability and good interoperability give us the ability to use the library in many different settings, from back-office CLI tooling (native Rust) to customer-facing frontend (compiled to WASM) as well as for validation steps in JVM-based backend services (C-ABI bindings).

While there were already some parsers for Turtle written in Rust around, we opted to write our own for a couple of reasons. Firstly, none of the existing parsers allowed access to an AST (Abstract Syntax Tree) representation of Turtle documents directly but instead output a stream of RDF tuples. We want to have that level of access to the document, as in some parts of our product, we need to do some fine-grained validation steps that are not possible with the flattened RDF representation. In addition, most libraries for handling Turtle allow for parsing it but don’t allow for serializing it, which was also a hard requirement for us, as we sometimes have to manipulate Turtle documents.

All those factors put together led to the creation of Harriet, which as of right now very much looks to be a success in terms of fulfilling its goals of portability and the control we wanted to have over Turtle, in exchange for a moderate amount of effort required to create the library.

Next steps

As with any newly published library, there are likely many things that can be polished more in Harriet, so we are looking forward to your feedback!

The open sourcing of Harriet only marks our first step as an open-source company, and we are looking forward to our next steps in that direction. Follow us on LinkedIn to stay in the loop on where that journey takes us!

P.S.: If any part of the above sounds exciting to you, we have multiple open positions in engineering ;)