An older post of mine about "company-as-code" was shared here recently. So I thought it might be nice with follow-up about how I'm approaching this practically in my small business.

Thanks for sharing!

I wrote this post some time ago, and more recently built a thing to do roughly this for my small business: https://github.com/42futures/firm

Had it in practice for about 4 months now and happy so far. It works for me, at my small scale. Hoping to share a follow-up with lessons learned soon.

This is incredibly cool.

Licensing it as AGPL-v3 throws up an interesting question - given the thing this produces is your company as code, if you use this does your entire company count as a larger work that would need to be open sourced? Or is there an explicit distinction between the "firmware" (excuse me) and the work product?

Licensing generally applies only to the thing being licensed and not its output.

Otherwise all software written with a GPLv3 editor would also be GPLv3…or all software built with a GPLv3 compiler would be GPLv3. (Neither are true)

That's because the output isn't a derivative work of the licensed software.

Agreed, this is on my mind as well.

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.

You'll unfortunately have to agree on some sort of state representation for each source and then delve into those APIs to extract that information

Hi there, I've made my own text-based todo list with compatible web view which is kind of similar to what you did. (though far from completion)

There's a sync engine behind it so the UX is extremely responsive.

Link: https://mglogi.com/portfolio

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.

It's good to experiment, and your boldness should be commended.

It's an interesting trend. With the push for chatbot-based interactions, CLIs and plain text representations are making a bit of a comeback, since LLMs interface with those more easily than UIs.

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).

You've got a point on RTO. Because it's a group behaviour, if you believe it will have positive effects, mandating it could be a way of jumpstarting the group dynamic.

With LLMs, I'm not so sure. Seems more like an individual activity to me. Are some people resistant to new tools, sure. But a good tool does tend to diffuse naturally. I think LLMs are diffusing naturally too, but maybe not as fast as the AI-boosters would like.

The mistake these managers are making is assuming it's a good tool for work that they're not qualified to assess.

> You've got a point on RTO. Because it's a group behaviour, if you believe it will have positive effects, mandating it could be a way of jumpstarting the group dynamic.

Fair point! It was just the first recent example of "it's obviously better but we'll force you to do it" I could think of.

In case of RTO I think it should have been left to individual small team. If one is so clearly it would have been clear in a few years time which teams work better and which didn't and how it depended on them being in the same office.