Open Source
Open source contributions
Everything we create at floro is open source and MIT licensed. We've never operated a large open source project before or significantly contributed to a large open source project, so there's a lot of learning to be done on our end. With that said, we are happy to take contributions to the project(s) that align with our idea of what floro should be.
We do have a vision and roadmap for what we want to build though. If our vision doesn't align with yours, please fork the project(s). If there's a better version of floro that can exist and we're not seeing it, please build it.
Code Repositories
Floro - This is the node server that runs locally on your machine. This is where all the version control logic and plugin and generator logic live. This is also where the CLI code resides and where all of our plugin & generator codegen features exist. The project is pure Typescript.
Floro Mono - This is the mono-repo that hosts our backend, our desktop client, our website, our browser extension, and our in-house plugins.
- Our backend is a NodeJS/Express typescript service that uses a GraphQL API. We use Postgres and TypeORM (kind of), as well as Redis. We make extensive use of inversify for dependency injection. All of our front-end is almost exclusively React/Vite.
- Our desktop client uses the smallest set of electron features we could get away with. It is also a Typescript/React/Vite project.
- Our Chrome-Extension is very small. It is also a Typescript/React/Vite project.
Floro Terraform - We deploy with terraform to AWS. You could pretty easily adapt this to work with another cloud provider. If you are going to self-host you will likely need to consult this repository.
Text Generator - This is the repository for generating typescript code for the Text plugin.
Icons Generator - This is the repository for generating typescript code for the Icons plugin.
Theme Generator - This is the repository for generating typescript code for the Theme plugin.
Palette Generator - This is the repository for generating typescript code for the Palette plugin.
Communication
We can communicate through Github pull requests and issues but if you want to make a significant contribution, please reach out to us on Discord. So we can talk it though first though.
Contributing Asks
We don't care much for many things when it comes to code aesthetics (you'll hate the code if you care about linting a lot). What we do ask is that you understand what you submit. Please do not use LLM generated code when submitting features. We don't mind if you use a co-pilot and can walk-through the code line-by-line but blind LLM usage makes us very nervous. This isn't a dig at AI, we're sure the robots will be replacing us all soon but in our opinion, we're not there yet.
Our short term roadmap
Right now we need a lot of help with identifying and fixing bugs. If you can give reproduction steps for bugs (or even a fix) that would be immensely valuable to us.
Security reviews are also welcome! If you find a vulnerability please let us know privately so we have some time to fix.
If there are sections of the documentation that are particularly confusing or misleading, let us know. We would really value contributions on documentation. Especially from individuals who have had to go through installing floro.
We would love to support a Firefox browser extension that should hopefully be a direct port of our Chrome Extension (it's a small app).
We would love help localizing and internationalizing the project. You can contribute this to our floro repository or the README.md files. Right now only our website is setup to be internationalized, we'll be adding floro to the desktop application soon and would love help correcting bad translations.
We have quite a bit of testing in the floro repository but none in some areas that could probably benefit from unit tests and integration tests. If you want to work with us on adding automated testing -- that will make it much easier for us to accept and review open contributions.
Finally, we really want to build migration tools for switching remote hosts. We don't want you to be stuck with floro.io as a host for your repositories. While there might be lock-in with floro as an integration into your codebase, there's no reason that you should be locked in to floro.io as your hosting provider for your repositories. There is some re-mapping of commit history that has to be done when switching remote hosts but it's completely doable. Reach out to us if you're interested in building this.
Our long term roadmap
We would love to have better debugging tools for developing floro plugins. They're okay right now but there's quite a bit of hackiness. For one, you write the floro schemas in a weird json dialect we invented that's kind of similar to json-schema but has some unique constraints and requirements.
If anyone wants to help us write the floro schema language (.fsl), we would love that. This might be tricky until we release our documentation on building plugins but we think this could be really fun.
We have a couple of ideas about how we could do p2p branch sharing with Bonjour. We think we could even do this in a way that respects the needs of IT departments. This might make floro a better tool for personal usage. We'd likely have to work very closely on this together though.
We would love to build a way to host local services that can be queried by plugins offline. There's a lot to think through here but it would be great if we could containerize and sandbox certain offline services like local LLMs that could be safely interacted with with by plugins. This is all possible if you're technical and working with a specific OS but might be really nice to introduce to non-software engineers in a platform-agnostic way.
Things not likely to be on our roadmap ever
We probably won't ever build floro in a way that supports federated remote hosts. There's too many security issues that come up. If we thought floro was more of a tool for individuals than organizations then this might make sense to consider but it's probably too ideological for what floro is useful for.
We probably won't introduce CRDTs. We've got a lot of respect for CRDTs but they don't really make sense for what floro is for.
Mobile and tablet clients. It's not totally impossible but it probably doesn't make a lot of sense for any near term roadmap. If you want to tackle this on your own we'd be happy to share where we think problems might pop up and think through ways to overcome them.