| I think it's less about putting a list of features in a spreadsheet and checking off boxes, and more about how the tool thinks. Jenkins can "do" the things that Concourse does, if you assemble enough plugins, click through enough configuration pages and write enough shell scripts. But that's not its native way of thinking. I agree that lots of Jenkins users will look at Concourse, scratch their head and leave it. But for those who switch, it's really that much better. I think it'll spread largely by word of mouth, especially once it begins to appear in downstream distribution channels. > It needs to be stressed that for a lot of small/middle sized companies, the build server is just an afterthought. Not everybody has full time people working on setting up pipelines. I'm in a team of four -- two pairs. We maintain and extend a medium-sized app, central to our revenue, that has some surprisingly complex and legally scary business rules. These days whenever we're annoyed by something, it's common for us to think "how can we get Concourse to do this for us?", instead of checklists or wiki pages or Just Hoping Somebody Remembers. I think people tend to set up Jenkins and never touch it again because it's scary to tinker with your CI/CD. Concourse is, despite being configured by flat files and a CLI, much more approachable in this regard. |
People who like Jenkins will read it and say "Meh", while people who have already switched to Concourse (like you) don't need to read it in the first place.