holoway

This is a great question. Eventually, yes. In an earlier prototype of SI, we actually had this feature, and it was pretty dope. We removed it as we made things much more programmable, but it's high on the road map to bring back. The first will be an `import` function that just builds an individual component from a resource, followed by the full discovery feature.

I think all great companies have names that are also great band names. System Initiative is a better band name than System-I. :)

I don't think you're alone, and to be honest, I'm as suprised as anyone that it turned out to be better. We built a lot of different implementations on the way here, and all of the initial versions started with code and plain text as the interface. But it's very hard (I think impossible) to change the user experience when you do that, because the data gets locked up in code - there isn't a good way to "see" what the real world is like, or what your proposed changes would do.

But you're not alone in thinking this, and I completely understand why you would. The history of things that look like this in this space is.. not great. :)

You can show up whenever you want to! Today it happens in the UI, but we could certainly send you a diff in your email at some point. :)

You don't, because we built the functionality in to the data model - you can review changes (in multiplayer!) and automate things directly in the application. Usually when we're talking infrastructure code, you don't really roll back to an N-1 version. In SI, you would make the changes you want in a change set, it would tell you if it looks like your change would work, and then you would apply the change set to run the actions needed.

Think of it this way - if you want to "move off of terraform", you're existing IaC isn't useful either (because you need Terraform/OpenTofu to run it). SI is the same.

It absolutely is. We're adding more resources all the time, we hang out in Discord and build the things folks need most. We're working on GCP now.

You can export your workspace, and import it into another version of SI. But we aren't producing IaC under the hood - we have a high fidelity modeling layer, and then we allow you to program those models directly.

But if you move off of System Initiative, we don't impact your resources at all. You can just stop using it.

Perhaps https://systeminit.com would make more sense. :)

Hello! Adam from System Initiative here. Happy to answer any questions. :)

Awful news. RIP Kris.

Absolutely it will. Everything we write will be open sourced. All of it.

Slave to the Grind, without question.

One side effect of our design is that, once we bring more of the bi-directional capabilities back into the product - we can track the real-world resources as they change, and update the model on your behalf. So you can keep using (or start using) whatever tool you like to make the changes, and SI will do its best to help you rationalize that. We've had this working in earlier versions, and will again in the not too distant future.

the ability to not have sandboxed local builds meant that it was easy for us to write the starlark/python code we needed to get things working in a rough way quickly, while correctness can come later.

I think you hit the nail on the head with crossplane being a 'much better terraform' by design. Our goal isn't so much a better IaC / Declarative infrastructure tool - it's a better overall workflow for doing collaborative DevOps work. We think that by having an active model of your component, and tracking the resources along side, we can fix the feedback loops in a way that things like crossplane, terraform, or pulumi really can't.

Of course today it's early - so you have to look at what we're building as a foundation for the future. But it's a solid foundation to build on!

We've got a fairly large monorepo, with code primarily in Rust, Typescript and PgSQL. We wanted something that would scale as we grew into things like remote execution and build farms, but that would let us be pragmatic in the meantime. Buck2 fit the bill at the time we needed to solve the problem. We also needed it to understand cross language dependencies.

One of the great things about it is that our CI system uses BXL to automatically generate pipelines on the fly from impacted code, taking into account dependencies. So things generally move as quickly as possible through the system.

It's been real work to adopt, but the upside for us has been worth it.

It's very early - it doesn't do much yet (but what it does do is compelling!). There isn't a ton of documentation, but we have put a lot of real user research into things.

1. Authentication works through Auth0. We're building towards multiple deployment models, where your account works across all of them. That said, it's all open source, so if Auth0 doesn't work for someone, we're happy to make it pluggable.

2. You can model anything you like. Under the hood it's a hypergraph of Typescript functions - so you would model Grafana, and then make calls to its API when actions are needed.

3. It's built in to the model via change-sets. As you do change the model, we show you whats changed, and what actions we would take. The design is heading toward letting you have comprehensive reviews based on which portions of the entire model are impacted. Roll-backs aren't really a thing in infrastructure land, but you can see old versions of the model and decide you want that to be the current one.

4. We model the upstream 1:1 - so that configuration uses the default VPC in the AWS account (which has likely been deleted if you use Terraform, for example.)

5. It's too early to have very large configurations yet. But there are techniques we can borrow from other domains - nesting, for example, or layers. We're working on the fundamentals first, and then we will deal with scale.

Great questions!

Skepticism here is warranted - the history of things that look like this in our space isn't fantastic. We've put a lot of engineering into trying to create something that is a power tool, and flexible enough to solve hard real world problems. It's early, and we've got lots of work to do, but that's the goal.

Yep. If you go to https://systeminit.com and click "Sign up", you can use our launcher to run a build directly.

We've been planning to open source it this way for the better part of a year. It just so happened that we were ready to open it up right after the Hashicorp folks made their decision. No intentional timing.

You can see more on our approach here: https://www.systeminit.com/open-source/

Hey - CEO here. Happy to answer questions if y'all have any.

Reset is a fabulous human.

It’s too early to know with real data. Architecturally, it should scale - but you know it’s going to need optimization when we start getting into high numbers.

Nothing about SI is intended to make ops a commodity. This is a power tool built by Ops people.

If you want to know more about some of the technical details, we wrote something up: https://www.systeminit.com/blog-five-breakthroughs

This is a reasonable reaction! :) There are a lot of ways to make the visual interface scale - examples from things like Blender, Figma, etc. We believe we can use them to make it scale semantically as the complexity climbs.

Hi! Adam Jacob here. Happy to answer questions!

I think it’s inefficient, in a market sense - for the reasons I explained above. All the source available companies we mentioned did that after they got the lift from the open source channel, and the lift from a competitive service. In the case of mongo, the competitor doesn’t use any of their code (making it even more of a straight competitor, meaning it might be harder to extract AWS customers for them).

I think they should’ve stayed/become open source, and instead used their trademark, distribution, and terms of service to ensure a brand monopoly, a-la RHEL.

You can read more about how I came to this conclusion at http://SFOSC.org

It’s absolutely their right to do. :)

It’s working pretty well for everyone. OpsWorks revenue was smaller than Chef. It grew our pie. Elastic, Redis, Mongo - all far bigger businesses with AWS competitions with them, seeing big growth in their cloud businesses.

Having AWS, Azure, or GCP validate your technology, product, and market is a huge win. Being the prime creator of the product puts you in a very advantageous position (new features, deep support, better user experience). Like the “normal” open source channel, you don’t collect all of the funnel. You do get a new channel (users of rival cloud providers) that operates at a disadvantage compared to your offering (at all but scale, and that’s not an impenetrable one). Those are well qualified users, accustomed to paying for the software. They’re great leads.

Downstream competitors are net good for you. Yes, it means other people get some of the revenue. But some of those would never have used the software in the first place without that competitor, or wouldn’t be used to paying for it. The increase in usage more than makes up for it.