Hey all, OP here from the team who built this feature. This came about from years of trying to coordinate Infra changes from my days wrangling Mesos and then Docker and then, on Railway itsself. Hopefully you really enjoy the deep dive that went into making the backing system for this feature. (even if you don't use Railway)
> What if you could take your projects from 1 → n just like you would with Git? What worlds would it open for your development workflow if your infrastructure on Railway was fully versioned and reproducible?
> To implement Changesets, our team took inspiration from Git.
Putting things nicely, I don't think people love git for it's elegance. After all, it was conceived and developed as an alternative to proprietary VCS software. Presenting a proprietary solution as "Git for X" is a catch-22. Most people will see the "pricing" button and register that immediately; you're not making Git, but instead selling a service.
It's a bit off-topic, and I don't expect any direct response. It just burns me up when ad copy buries it's lede so far.
Wait no- comments like this are what I enjoy. I personally struggle with the whole dichotomy of "marketing led" writing and then balancing that with just spending 2,000 words talking through test frameworks and cases. Maybe for a future blogpost, but the idea of stateful state tracking is a rabbit hole I can get buried under.
To address your main point, I think Git is in the same camp of Python's origins. Powerful despite the creator's initial intentions. Where like it or not, it becomes a powerful mental API to interact with domains. (Git -> Changesets, Python -> Notebooks/Repls)
When I was working on the material for the feature, I kept on trying to find a parallel that fit within people's mental model without it being a leaky abstraction. (Of course my colleague helps make me sound sane.) Other ideas to get people's attention was talking a bit about YAML, but to your point- I hate the bashing that most DevOps companies do that say: K8s is EVIL!!11!!!. Or end DevOps11!!!!!! - it's a series of practices that help you for an outcome, in the same way how Git, SVN, Mercurial, help you and a team track changes.
Changesets is just one way to maintain a production/infra practice a suite of recommendations that a team can adopt.
Thanks for commenting and I hope it was an interesting read :3
> I kept on trying to find a parallel that fit within people's mental model without it being a leaky abstraction
It's a good analog, but doesn't mention a credit card as a hard-dependency :p
With all seriousness, I'm sure you're working on a swell tool. I also understand how difficult it is writing confident ad copy. This still sends the wrong message though, and I'm afraid you're going to get a lot of users belly-laughing at a Git comparison for non-GPL software. That's my only real comment on the thing.
Hey, GNU solved fraud by not assuming that the user wants to pay them a dime. It's been a very successful model at-scale! (albeit hardly profitable)
> I will throw some credits your way so you can play around with it.
I'm not poormouthing you here, if that's what you mean. It's just a bad comparison that almost deliberately ignores the reason for git's development and widespread adoption. It exits the domain of a meaningful metaphor and skates straight into confusion.
Again, I wish you luck. This marketing just doesn't fit for the product you're selling, and that lack of clarity will cost you conversions and waste your time. My $0.02.
6 comments
[ 0.19 ms ] story [ 88.7 ms ] thread> To implement Changesets, our team took inspiration from Git.
Putting things nicely, I don't think people love git for it's elegance. After all, it was conceived and developed as an alternative to proprietary VCS software. Presenting a proprietary solution as "Git for X" is a catch-22. Most people will see the "pricing" button and register that immediately; you're not making Git, but instead selling a service.
It's a bit off-topic, and I don't expect any direct response. It just burns me up when ad copy buries it's lede so far.
To address your main point, I think Git is in the same camp of Python's origins. Powerful despite the creator's initial intentions. Where like it or not, it becomes a powerful mental API to interact with domains. (Git -> Changesets, Python -> Notebooks/Repls)
When I was working on the material for the feature, I kept on trying to find a parallel that fit within people's mental model without it being a leaky abstraction. (Of course my colleague helps make me sound sane.) Other ideas to get people's attention was talking a bit about YAML, but to your point- I hate the bashing that most DevOps companies do that say: K8s is EVIL!!11!!!. Or end DevOps11!!!!!! - it's a series of practices that help you for an outcome, in the same way how Git, SVN, Mercurial, help you and a team track changes.
Changesets is just one way to maintain a production/infra practice a suite of recommendations that a team can adopt.
Thanks for commenting and I hope it was an interesting read :3
It's a good analog, but doesn't mention a credit card as a hard-dependency :p
With all seriousness, I'm sure you're working on a swell tool. I also understand how difficult it is writing confident ad copy. This still sends the wrong message though, and I'm afraid you're going to get a lot of users belly-laughing at a Git comparison for non-GPL software. That's my only real comment on the thing.
Good luck with your service otherwise!
(Also if you send me an email to angelo@railway (dot) app- I will throw some credits your way so you can play around with it.)
> I will throw some credits your way so you can play around with it.
I'm not poormouthing you here, if that's what you mean. It's just a bad comparison that almost deliberately ignores the reason for git's development and widespread adoption. It exits the domain of a meaningful metaphor and skates straight into confusion.
Again, I wish you luck. This marketing just doesn't fit for the product you're selling, and that lack of clarity will cost you conversions and waste your time. My $0.02.