5 ms·

I'm surprised we haven't seen more consolidation of companies whose primary product is related to developer experience. I always thought either Github or Micro

I'm surprised we haven't seen more consolidation of companies whose primary product is related to developer experience. I always thought either Github or Microsoft would start snatching up all these small companies to integrate them more tightly to sell as end to end packages. Anyone in this space have any insight into why that hasn't happened yet?

pm90 9y ago
GitLab has been doing an excellent work of integrating CI/CD tools with their code hosting solution; I'm guessing thats what you're talking about. Specifically for Github, I believe they want to focus on hosting and developing (reviewing and managing) code and not on owning the CI/CD tools. They do provide many many integrations with different tools (TravisCI, Jenkins etc.). Which is a good thing: I want Github to be working on making code development better and remain agnostic of pipeline tools, which come and go as fashion dictates (OK I'm being a little harsh but my point is that I should be able to choose my CI/CD tools while having all my code live in Github).
- colbyh 9y ago
  It would benefit Github to own a CI/CD tool if said tool was used in the vast majority of projects and there was little worry about disrupting the rest. E.g. if Codeship was used by 99% of Github customers it would totally make sense for them to purchase the co and integrate more tightly. But since the pipeline space is varied and rich, as you say, they benefit quite a bit by being a centralized tool that connects to all of them. Just pointing out that should that change in the future (in some unrelated area, say code review as a service?) we could very well see GH plop down a ton of cash and break out of that "code development tools" vertical.
  - moritzplassnig 9y ago
    I think that's a good point. There's quite some fragmentation in the cloud CI/CD space (if we look beyond Jenkins). If necessary, GitHub could still acquire down the road. The downside risk is small.
scarface74 9y ago
Microsoft already has an excellent easy to use hosted CI/CD platform with Visual Studio Team Services. You can either use hosted build agents or on prem build and deployment agents. They treat Git as first class citizens.
- sitepodmatt 9y ago
  And such confusing naming yet again. Makes it sound like a cross between Visual Studio IDE (the heavyweight version) and the god awful Team Foundation Services.
  - snuxoll 9y ago
    It's a rebranding of Team Foundation Services, tbh. They've done a lot to improve it over the years, but as someone who is forced to work with it daily I'd still take just about anything else - better than it used to be doesn't make it a "good" product by far.
    - scarface74 9y ago
      As a CI/CD tool, what do you feel is missing?
      - snuxoll 9y ago
        There’s still no way to describe your build as code or configuration in your source repository like travis.yml, Jenkinsfile, etc. which I consider a key feature of a relatively modern CI/CD tool. Beyond that, the new build tooling isn’t half bad - leaps and bounds ahead of the nasty XML nightmare which is why our team has been moving back to it from out TeamCity deployment. Most of my gripes with VSTS are around the rest of it, everything under “Work” has barely been touched since TFS 2012 - it got a coat of paint but it’s still the same enterprise-grade turd that makes me yearn for JetBrains YouTrack every day. They’ve had adequate git support for a while but the web-based repository browser is such a chore to use that I end up cloning a repository to do a quick search more often than I should need, the admin interface is still a mess to navigate, the list goes on.
moritzplassnig 9y ago
I think the majority of developers & companies doesn't want one product that does everything. It's better for the user to have clear APIs, solve specific problems very well and then make it easier to integrate with other products. It should all be building blocks that work well together. You should be able to use, e.g., GitHub because you prefer it over Bitbucket, integrate it with Codeship (or whatever other CI/CD solution you like) and then add other products like Percy or Code Climate as needed. There's a use case, and some people prefer to get everything out of one hand, but if we look at how software is getting purchased nowadays, it's more and more team-focused, fewer company-wide purchases. That's great. Pick the tools and products that solve your specific problem very well, as long as they integrate well with what the rest of your team uses. Now that doesn't mean you couldn't build a company that does everything, or that Microsoft couldn't start acquiring and then does everything (they kind of doing it already, same with AWS). What we can see, though, is that the quality of specific products isn't that great. That's not surprising. It's easier to do a few things very well vs. 200 things. And yes, I'm biased because of Codeship :)
- mschuster91 9y ago
  > It's better for the user to have clear APIs, solve specific problems very well and then make it easier to integrate with other products. At my company, some teams use the integrated GitLab CI features and other teams use a linked Jenkins instance, and both work well with Sonar. The only thing that is not linked automatically to this (or, at least, not in the best possible way) is the Atlassian stack because the integration plugins needed cost a boatload of money.
  - sytse 9y ago
    We're trying to do complete DevOps with GitLab https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/ What part of the Atlassian stack are you missing in GitLab?
    - mschuster91 9y ago
      > What part of the Atlassian stack are you missing in GitLab? Well, customers and our employees are used to JIRA and Confluence. What I am talking about is proper automated linking of Gitlab branches/MRs/commits to (multiple) JIRA tickets and Confluence pages and vice versa. Basic interfacing is working but it could be done better if we'd shell out thousands of dollars per year.
kkapelon 9y ago
Because Github wants to be app store. See https://github.com/marketplace https://github.com/marketplace Instead of creating a solution for themselves they will take 30% from all other solutions
- hobofan 9y ago
  Really curious how that's working out for them. If the numbers in the Gemnasium shutdown post are any indiction, I'd say not really.

pm90 9y ago

GitLab has been doing an excellent work of integrating CI/CD tools with their code hosting solution; I'm guessing thats what you're talking about. Specifically for Github, I believe they want to focus on hosting and developing (reviewing and managing) code and not on owning the CI/CD tools. They do provide many many integrations with different tools (TravisCI, Jenkins etc.). Which is a good thing: I want Github to be working on making code development better and remain agnostic of pipeline tools, which come and go as fashion dictates (OK I'm being a little harsh but my point is that I should be able to choose my CI/CD tools while having all my code live in Github).

colbyh 9y ago
It would benefit Github to own a CI/CD tool if said tool was used in the vast majority of projects and there was little worry about disrupting the rest. E.g. if Codeship was used by 99% of Github customers it would totally make sense for them to purchase the co and integrate more tightly. But since the pipeline space is varied and rich, as you say, they benefit quite a bit by being a centralized tool that connects to all of them. Just pointing out that should that change in the future (in some unrelated area, say code review as a service?) we could very well see GH plop down a ton of cash and break out of that "code development tools" vertical.
- moritzplassnig 9y ago
  I think that's a good point. There's quite some fragmentation in the cloud CI/CD space (if we look beyond Jenkins). If necessary, GitHub could still acquire down the road. The downside risk is small.

scarface74 9y ago

Microsoft already has an excellent easy to use hosted CI/CD platform with Visual Studio Team Services. You can either use hosted build agents or on prem build and deployment agents. They treat Git as first class citizens.

sitepodmatt 9y ago
And such confusing naming yet again. Makes it sound like a cross between Visual Studio IDE (the heavyweight version) and the god awful Team Foundation Services.
- snuxoll 9y ago
  It's a rebranding of Team Foundation Services, tbh. They've done a lot to improve it over the years, but as someone who is forced to work with it daily I'd still take just about anything else - better than it used to be doesn't make it a "good" product by far.
  - scarface74 9y ago
    As a CI/CD tool, what do you feel is missing?
    - snuxoll 9y ago
      There’s still no way to describe your build as code or configuration in your source repository like travis.yml, Jenkinsfile, etc. which I consider a key feature of a relatively modern CI/CD tool. Beyond that, the new build tooling isn’t half bad - leaps and bounds ahead of the nasty XML nightmare which is why our team has been moving back to it from out TeamCity deployment. Most of my gripes with VSTS are around the rest of it, everything under “Work” has barely been touched since TFS 2012 - it got a coat of paint but it’s still the same enterprise-grade turd that makes me yearn for JetBrains YouTrack every day. They’ve had adequate git support for a while but the web-based repository browser is such a chore to use that I end up cloning a repository to do a quick search more often than I should need, the admin interface is still a mess to navigate, the list goes on.

moritzplassnig 9y ago

I think the majority of developers & companies doesn't want one product that does everything. It's better for the user to have clear APIs, solve specific problems very well and then make it easier to integrate with other products. It should all be building blocks that work well together. You should be able to use, e.g., GitHub because you prefer it over Bitbucket, integrate it with Codeship (or whatever other CI/CD solution you like) and then add other products like Percy or Code Climate as needed. There's a use case, and some people prefer to get everything out of one hand, but if we look at how software is getting purchased nowadays, it's more and more team-focused, fewer company-wide purchases. That's great. Pick the tools and products that solve your specific problem very well, as long as they integrate well with what the rest of your team uses. Now that doesn't mean you couldn't build a company that does everything, or that Microsoft couldn't start acquiring and then does everything (they kind of doing it already, same with AWS). What we can see, though, is that the quality of specific products isn't that great. That's not surprising. It's easier to do a few things very well vs. 200 things. And yes, I'm biased because of Codeship :)

mschuster91 9y ago
> It's better for the user to have clear APIs, solve specific problems very well and then make it easier to integrate with other products. At my company, some teams use the integrated GitLab CI features and other teams use a linked Jenkins instance, and both work well with Sonar. The only thing that is not linked automatically to this (or, at least, not in the best possible way) is the Atlassian stack because the integration plugins needed cost a boatload of money.
- sytse 9y ago
  We're trying to do complete DevOps with GitLab https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/ What part of the Atlassian stack are you missing in GitLab?
  - mschuster91 9y ago
    > What part of the Atlassian stack are you missing in GitLab? Well, customers and our employees are used to JIRA and Confluence. What I am talking about is proper automated linking of Gitlab branches/MRs/commits to (multiple) JIRA tickets and Confluence pages and vice versa. Basic interfacing is working but it could be done better if we'd shell out thousands of dollars per year.

kkapelon 9y ago

Because Github wants to be app store. See https://github.com/marketplace https://github.com/marketplace Instead of creating a solution for themselves they will take 30% from all other solutions

hobofan 9y ago
Really curious how that's working out for them. If the numbers in the Gemnasium shutdown post are any indiction, I'd say not really.