I would like to ask HN about the licensing model that we are considering. Tentatively we call it as 'more open than open source products' because our product is not entirely open source, but practically it is more open than typical open source products.

A typical (commencial) open source product has by definition an open source repository, but its enterprise features are usually closed source. This implies that even if a user has purchased a license for the enterprise features, he/she still cannot rebuild the product after modifying/extending/fixing the code in the open source repository. In fact, there is no guarantee that the same open source repository is used in building the product.

In our case, we provide the binary distribution of the engine and everything else so that the user can rebuild the product, including all the enterprise features. For example, a user can modify/extend/fix the code in the open source repository and immediately rebuild his/her own version. If the user needs an extension to the proprietary engine (which we believe will rarely occur), we implement the extension at no charge. So, the user should trust a small core of the product (less than 5%) without access to the source code.

So, do you agree that this strategy deserves to be called 'more open than open source products'? Thanks!

We were a YC W21 startup (Cheqout) that originally worked on restaurant tech. We ended up pivoting after the pandemic and decided to build Floro due to a lot of problems we encountered while working on Cheqout.

We struggled a lot with string content and dark mode, especially when it came to static assets. We were a cross-platform product, so everything was an SVG. What we wanted was a way for our designer (who cannot use a command line) to be able to check static assets into our codebase and be able to manage our color themes without us having to manually edit the assets ourselves. We also faced a lot of problems with i18n and keeping translations up to date. Both problems felt kind of similar, they’re both essentially just key value solutions that require people who aren’t software engineers to edit them.

This led us down a path of searching for a way to incorporate something like Dropbox into git. We didn’t want a content management system, we wanted something where we could diff and merge our static assets without requiring the user to know how to fix conflicts in plain-text or binary. We wanted a way to reference something like a snapshot of a tar of our static assets so we could idempotently rebuild our application and add type-safety to our assets. Eventually, we found a trick to diff and merge a certain type of tree structure that fit these problems well. After a bit more experimenting around, we figured out how we could write an interface to make UIs that could be diffed and display merge conflicts.

To show what visual version control could be applied to, we decided to build four plugins (applications that can be diffed and merged in Floro).

1. Text - This plugin is basically a replacement for i18n strings. It supports rich text, typed variable interpolations, conditional logic (for things like pluralization), links, ML translations, and a plethora of other features. It’s also sort of an IDE/TMS for translators & copy editors.

2. Icons - This plugin allows you to recolor an SVG asset so that all the colors are consistent with your color palette. You can automatically generate dark mode (and any other themed) versions of your assets, as well as versions of your asset that change with state (e.g. hovered, etc.) by applying themes to the asset.

3. Themes - This plugin allows you to create themes from your color palette.

4. Palette - This plugin allows you to define colors and shades that can be consumed by other plugins or used in your code for managing your app’s colors.

Since Floro is an offline-first desktop application we realized that we could allow users to test their local content out by building a browser extension that would allow them to override the state of their production websites and apps with the local content from floro. Floro essentially creates a localhost environment out of production apps, which allows non-technical users to treat content similarly to how engineers manage code. The demo video (shown above) does a good job of showing how this works. We also have a demo of how this works for mobile apps (https://www.youtube.com/watch?v=Om-k08GDoZ4).
We are fully open source (MIT licensed). We intend to monetize with consulting and private hosting. Users are more than welcome to self-host and build their own distributions of the desktop application and all the plugins we have created.

This is really our launch (anticipate some bugs but nothing serious, restarting the app(s) takes care of most things). We’ve now built four applications with Floro (including our website) and feel confident that it’s ready. We’ve spent 18 months getting here, we hope some of you like it!

Thanks!

Jamie & Jacqueline

Website: https://floro.io

Hi HN, we’re building floro (floro.io), an open-source, offline-first visual version control system that allows you to merge and diff graphical content. We were a YC W21 startup (Cheqout) that originally worked on restaurant tech. We ended up pivoting after the pandemic and decided to build floro due to a lot of problems we encountered while working on Cheqout.

We struggled a lot with string content and dark mode, especially when it came to static assets. We were a cross-platform product, so everything was an SVG. What we wanted was a way for our designer (who cannot use a command line) to be able to check static assets into our codebase and be able to manage our color themes without us having to manually edit the assets ourselves. We also faced a lot of problems with i18n and keeping translations up to date. Both problems felt kind of similar, they’re both essentially just key value solutions that require people who aren’t software engineers to edit them.

This led us down a path of searching for a way to incorporate something like Dropbox into git. We didn’t want a content management system, we wanted something where we could diff and merge our static assets without requiring the user to know how to fix conflicts in plain-text or binary. We wanted a way to reference something like a snapshot of a tar of our static assets so we could idempotently rebuild our application and add type-safety to our assets. Eventually, we found a trick to diff and merge a certain type of tree structure that fit these problems well. After a bit more experimenting around, we figured out how we could write an interface to make UIs that could be diffed and display merge conflicts.

To show what visual version control could be applied to, we decided to build four plugins (applications that can be diffed and merged in floro).

1. Text - This plugin is basically a replacement for i18n strings. It supports rich text, typed variable interpolations, conditional logic (for things like pluralization), links, ML translations, and a plethora of other features. It’s also sort of an IDE/TMS for translators & copy editors.

2. Icons - This plugin allows you to recolor an SVG asset so that all the colors are consistent with a your color palette. You can automatically generate dark mode (and any other themed) versions of your assets, as well as versions of your asset that change with state (e.g. hovered, etc.) by applying themes to the asset.

3. Themes - This plugin allows you to create themes from your color palette.

4. Palette - This plugin allows you to define colors and shades that can be consumed by other plugins or used in your code for managing your app’s colors.

Since floro is an offline-first desktop application we realized that we could allow users to test their local content out by building a browser extension that would allow them to override the state of their production websites and apps with the local content from floro. Floro essentially creates a localhost environment out of production apps, which allows non-technical users to treat content similarly to how engineers manage code. The demo video (shown above) does a good job of showing how this works. We also have a demo of how this works for mobile apps (https://www.youtube.com/watch?v=Om-k08GDoZ4).

We are fully open source (MIT licensed). We intend to monetize with consulting and private hosting. Users are more than welcome to self-host and build their own distributions of the desktop application and all the plugins we have created.

This is really our launch (anticipate some bugs but nothing serious, restarting the app(s) takes care of most things). We’ve now built four applications with floro (including our website) and feel confident that it’s ready. We’ve spent 18 months getting here, we hope some of you like it!

Thanks!

Jamie & Jacqueline