The text-based software that would eat work management is one that embraces the incumbents rather than avoid them.
I want a bidirectional SaaS <=> YAML/JSON adapter. So that I can push and pull our CRM (and other SaaS utilities like project management) into a common (schematized) YAML format.
The YAML then can be analyzed and modified using LLMs and/or stored in git.
And then use the bidirectional sync to reconcile conflicts and push.
So I can do work processes on the console, and still collaborate with people who want the native web UI.
Thinking of Terraform, you have data blocks that can grab data from an external source. Still trying to grok what would be a convenient way of doing something like this - whether that gets generated to DSL, or if data pulled in dynamically as you build the org graph...
Having your plain-text workspace as a unified structural source where you pull in data from external systems would be potentially powerful.
I’d be happy with SQL access, which I think gets to roughly the same place.
I’ve done something like what you’re talking about before for a CMDB, though it was one way YAML -> DB sync. Many to many relationships were a pain to view, there’s not a great way to put them in YAML that makes them easy to read. Can’t embed them because then you have multiple copies and which one is the real one. References suck because you can’t see the relationship and the related objects at once.
The real killer is permissions, though. Your sync tool basically has to have admin privileges, which means permissions have to be checked at merge time, and then you’re rebuilding the entire permissions flow as a git hook.
SQL with RLS is capable of implementing permissions in a way that works for both API access and direct SQL access. I get the feeling few companies do it, but they could.
This is interesting, very similar to a project I am working on, which is a cli asset manager for a small repair shop. Basically, mine keeps track of service tickets, customers and inventory while being query-able to help identify trends in problem products or recall records for warranty disputes, etc. It's just a silly little project I started in my spare time because I got fed up with having to open up three pieces of software with clunky UIs and frequent crashes to accomplish what should be fairly simple and straight-forward tracking and analysis. My biggest hurdle was getting it to export to a nice looking PDF that could be emailed or printed later.
While mine is functional, yours looks A LOT more refined, so I think I will play around with it and see if I can't adapt it to my needs.
I try to work in the terminal as much as I can since that's where I'm most comfortable, but when it comes to business software like CRMs, HRMs or ERPs, especially geared toward smaller shops, the selection for terminal-based options is severely lacking.
(1) Command lines lack the discoverability element of GUIs (and TUIs), where the available choices are typically laid out in front of you. Just look at the command "firm -c list contact" in the screenshot in the linked readme - no doubt it's sensible, but you wouldn't just type it in out of nowhere. You could argue that good docs fix this, but they'll never be a substitute. (Silly analogy: imagine if your toaster had buttons just labelled "1", "2", "3" and you had to refer to the manual for which meant toast, defrost, extra browning.)
(2) Command lines lack the visual persistence of the data you're operating on (like a list of files in a directory, or project/people data like in this program). If you rename a file and you then re-run ls and now everything appears in a slightly different place on the screen (because the previous listing had shifted up when you ran "mv") it's visually jarring in a way that just operating directly on the data isn't. Not-silly analogy: it's like how no-one today would dream of operating on a text file using a pure line editor like ed. (Even command-based editors like vim persist the file data in the main visual area.)
Command lines are much better than GUIs/TUIs for some applications, for example when called from a script, or where you might need to compose a complex command and then tweak and re-run it (in fairness, that might apply to OP's project). But I think techies sometimes get a bit carried away. GUIs are sometimes a legitimately better choice.
Reading all these opinionated comments about CLI vs GUI, I feel out of place as just a humble TUI fan.
- CLIs are powerful but hard, basically an exercise in mnemonics.
- GUIs are much friendlier, and can be faster than CLIs for certain use cases. While complex and bloated, they have their use cases to shine.
- TUIs are basically less expressive GUIs, since they're limited to text, but you must go out of your way to make them bloated and slow; they usually are very snappy.
All have their best and worst scenarios, no need to argue which is better. Use what fits best with your workflow, no size fits all.
The main reason might be that terminals are ugly and messy, you can't find shit, everything melts together. Might be nice for power users, but those aren't so many I would guess.
Many people forget the main reason why Windows, Mobile, Webapps succeeded is because of convenience. The more easy to use the more better. Convenience is also the reason why Meta Glasses will be successful.
Looking at the points you made and examples, I would cobble a similar tool with Django, writing only CLI commands with no HTTP endpoints. And most LLMs are already fluent in Django.
- Schemas and relationships live in models.py, actual data is persisted in Sqlite
- I can dump to JSON or XML with Django utils for LLMs
- Query engine can simplify reuse Django syntax, like `Firm.objects.get(owner_name__like="john", date__gt=2015)`, fetch related names, aggregate subqueries
- Format as tables
I love the idea. More power to text-based tools, more power to the CLI.
But ... why invent a new file format?
Why not just make in JSON, so it is easier to integrate in other toolchains (e.g. having a python script add customers based on external APIs without having to write your own output generator)?
I’ve tried JSON, YAML, and TOML for storing data. Last time, I ended up with an 8,000-line JSON file. And I had to write an editor for it, because text-based editing caused more syntax errors than I expected (what a surprise :).
But each of formats seemed nice at first.
So I understand that sometimes it’s easier to invent a new format. But compatibility with other formats can definitely be a problem lately.
My question is: how does the proposed system handle multiple editors working on the same text file?
Parsing your data format completely via tree-sitter is an interesting choice. Usually tree-sitter is "the second parser" only (for syntax highlighting etc), and the t-s version of a grammar isn't 100% comprehensive.
I do wonder how much value all this work adds compared to having e.g. JSONC files with schemas. (Or HCL-syntax-for-JSON to visually match this work and then JSON schemas.)
things like this are so much fun. I mess around with projects like this too. I have a little "status" app that that's a web UI embedded into a Go binary that shows my current WIP and it updates my slack status with what my WIP is. so outside of standup everyone just knows what I'm up to
The age of LLMs is shifting the predominant modality of data towards plaintext. For people like us, it's easier to grok, and it allows all of the poweruser use cases. I think this is a great idea.
This looks very similar to a FoSS version of Tana: https://tana.inc/
Which is well timed because I've been increasingly leaning more into Tana but also being like "it would really suck if this tool goes away". Having something that has the same ergonomics of Tana but is more open is really interesting.
While I do not think big corps would go for it, I believe you have something there that could:
1. Appeal to some of the crowd here
2. Potentially run in the background as meta layer for llm ( as crazy as that sounds, the annoying reality is that it is happening already, but in the most annoying way possible 'worst of all worlds' version )
It will. But humans have eyes, observability, metrics will still need graphs or eye-candy for most people. Though the means of communication might be heavily be based on text.
Interesting approach to work management! The text-based interface
reminds me of challenges we faced building task coordination for an
AI agent system. How do you handle dependency tracking between tasks?
For our Django development agent, we use a similar structured approach
where each feature is broken into steps. Found that explicit
dependencies (vs implicit) prevented a lot of circular issues.
Very cool like a text based crm. Like how obsidian keeps all your docs in local .MD files.
Perfect for building agent automations without delving into lots of integrations.
This does make it harder to collaborate though
Looks like an early stage, immature project, but it's a neat concept.
It seems Windows Defender flags the zip download as a trojan. Likely false positive since scans on the unzipped exe (Defender and virustotal) come back clean.
I'd suggest providing a way to disable the builtin schemas in case someone wants to use it for more tech things as opposed to business things.
I think that's fair. I'm personally happy with a text editor + CLI, but can acknowledge that is not enough for broader adoption.
The project is structured as libraries such that you could build an editor separately, but it's not something that has taken priority for me (as the only user, so far).
With cursor you can hit Cmd+K in the terminal and give a prompt for the agent to convert to a command in the terminal. Would be good if it could allow to do the same to generate SQL queries based on the databases schemas available. Then it would be a generic solution that would cover this use case.
Healthy skepticism. I think firm differs from ops as code in the sense that it focuses on the structural aspects and representing the people-ops side in a way that machines can interact with too.
To be clear, I'm trialing this out in my own small business. Whether it's ergonomic enough to add value and whether it's scalable, I don't know yet. So far, so good, though.
bravura|4 months ago
I want a bidirectional SaaS <=> YAML/JSON adapter. So that I can push and pull our CRM (and other SaaS utilities like project management) into a common (schematized) YAML format.
The YAML then can be analyzed and modified using LLMs and/or stored in git.
And then use the bidirectional sync to reconcile conflicts and push.
So I can do work processes on the console, and still collaborate with people who want the native web UI.
danielrothmann|4 months ago
Thinking of Terraform, you have data blocks that can grab data from an external source. Still trying to grok what would be a convenient way of doing something like this - whether that gets generated to DSL, or if data pulled in dynamically as you build the org graph...
Having your plain-text workspace as a unified structural source where you pull in data from external systems would be potentially powerful.
everforward|4 months ago
I’ve done something like what you’re talking about before for a CMDB, though it was one way YAML -> DB sync. Many to many relationships were a pain to view, there’s not a great way to put them in YAML that makes them easy to read. Can’t embed them because then you have multiple copies and which one is the real one. References suck because you can’t see the relationship and the related objects at once.
The real killer is permissions, though. Your sync tool basically has to have admin privileges, which means permissions have to be checked at merge time, and then you’re rebuilding the entire permissions flow as a git hook.
SQL with RLS is capable of implementing permissions in a way that works for both API access and direct SQL access. I get the feeling few companies do it, but they could.
swoorup|4 months ago
kstrauser|4 months ago
0xEF|4 months ago
While mine is functional, yours looks A LOT more refined, so I think I will play around with it and see if I can't adapt it to my needs.
I try to work in the terminal as much as I can since that's where I'm most comfortable, but when it comes to business software like CRMs, HRMs or ERPs, especially geared toward smaller shops, the selection for terminal-based options is severely lacking.
SuperHeavy256|4 months ago
Thom2000|4 months ago
If you can export to structured data such as JSON, I guess Typst would be a perfect fit for that job.
mayowaxcvi|4 months ago
jaaron|4 months ago
gnu and emacs already have a long history of cli and text friendly solutions that LLM dev agents can easily use and are trained on.
Or for structured data, just use a database. Dev agents can work with SQL just fine.
4b11b4|4 months ago
Protostome|4 months ago
I live in the terminal, but most people in my company, including developers rather stay away from it
quietbritishjim|4 months ago
(1) Command lines lack the discoverability element of GUIs (and TUIs), where the available choices are typically laid out in front of you. Just look at the command "firm -c list contact" in the screenshot in the linked readme - no doubt it's sensible, but you wouldn't just type it in out of nowhere. You could argue that good docs fix this, but they'll never be a substitute. (Silly analogy: imagine if your toaster had buttons just labelled "1", "2", "3" and you had to refer to the manual for which meant toast, defrost, extra browning.)
(2) Command lines lack the visual persistence of the data you're operating on (like a list of files in a directory, or project/people data like in this program). If you rename a file and you then re-run ls and now everything appears in a slightly different place on the screen (because the previous listing had shifted up when you ran "mv") it's visually jarring in a way that just operating directly on the data isn't. Not-silly analogy: it's like how no-one today would dream of operating on a text file using a pure line editor like ed. (Even command-based editors like vim persist the file data in the main visual area.)
Command lines are much better than GUIs/TUIs for some applications, for example when called from a script, or where you might need to compose a complex command and then tweak and re-run it (in fairness, that might apply to OP's project). But I think techies sometimes get a bit carried away. GUIs are sometimes a legitimately better choice.
ASalazarMX|4 months ago
- CLIs are powerful but hard, basically an exercise in mnemonics.
- GUIs are much friendlier, and can be faster than CLIs for certain use cases. While complex and bloated, they have their use cases to shine.
- TUIs are basically less expressive GUIs, since they're limited to text, but you must go out of your way to make them bloated and slow; they usually are very snappy.
All have their best and worst scenarios, no need to argue which is better. Use what fits best with your workflow, no size fits all.
brettermeier|4 months ago
sunshine-o|4 months ago
My guess is that the console is a much better and natural UI because it goes in one direction and is less confusing and productive for humans.
In the end we seems to move back to it through the chatbot paradigm, because it is in the end a console...
cantor_S_drug|4 months ago
aitchnyu|4 months ago
- Schemas and relationships live in models.py, actual data is persisted in Sqlite - I can dump to JSON or XML with Django utils for LLMs - Query engine can simplify reuse Django syntax, like `Firm.objects.get(owner_name__like="john", date__gt=2015)`, fetch related names, aggregate subqueries - Format as tables
alchemist1e9|4 months ago
https://www.gnu.org/software/recutils/
DocTomoe|4 months ago
But ... why invent a new file format? Why not just make in JSON, so it is easier to integrate in other toolchains (e.g. having a python script add customers based on external APIs without having to write your own output generator)?
sixtyj|4 months ago
But each of formats seemed nice at first.
So I understand that sometimes it’s easier to invent a new format. But compatibility with other formats can definitely be a problem lately.
My question is: how does the proposed system handle multiple editors working on the same text file?
yencabulator|4 months ago
https://github.com/42futures/firm/blob/31fc084b7c7855bef9694...
I do wonder how much value all this work adds compared to having e.g. JSONC files with schemas. (Or HCL-syntax-for-JSON to visually match this work and then JSON schemas.)
itsnowandnever|4 months ago
I love little CLI tools for managing productivity
ipnon|4 months ago
virajk_31|4 months ago
runlaszlorun|4 months ago
kkukshtel|4 months ago
Which is well timed because I've been increasingly leaning more into Tana but also being like "it would really suck if this tool goes away". Having something that has the same ergonomics of Tana but is more open is really interesting.
A4ET8a8uTh0_v2|4 months ago
1. Appeal to some of the crowd here 2. Potentially run in the background as meta layer for llm ( as crazy as that sounds, the annoying reality is that it is happening already, but in the most annoying way possible 'worst of all worlds' version )
yencabulator|4 months ago
ithkuil|4 months ago
swoorup|4 months ago
vebgen|4 months ago
For our Django development agent, we use a similar structured approach where each feature is broken into steps. Found that explicit dependencies (vs implicit) prevented a lot of circular issues.
Curious about your experience!
dcsan|4 months ago
Reminds me also a bit of
https://github.com/MrLesk/Backlog.md
benchloftbrunch|4 months ago
It seems Windows Defender flags the zip download as a trojan. Likely false positive since scans on the unzipped exe (Defender and virustotal) come back clean.
I'd suggest providing a way to disable the builtin schemas in case someone wants to use it for more tech things as opposed to business things.
matthewcanty|4 months ago
I’d love to simply map all the relationships between stock, assets, tools like invoicing, APIs all in a place like this.
But I have to agree I think CLI alone would result in it being usable by only me.
EDIT: just wanted to add I’m interested in where this project goes.
danielrothmann|4 months ago
The project is structured as libraries such that you could build an editor separately, but it's not something that has taken priority for me (as the only user, so far).
kovek|4 months ago
baby-yoda|4 months ago
Thinking about an LLM use case, not needing a query language should remove translation risk I'd assume?
pjz|4 months ago
n0um3n4|4 months ago
cyanydeez|4 months ago
N_Lens|4 months ago
danielrothmann|4 months ago
To be clear, I'm trialing this out in my own small business. Whether it's ergonomic enough to add value and whether it's scalable, I don't know yet. So far, so good, though.
actionfromafar|4 months ago
blitzers|4 months ago
[deleted]