12 ms·

It's interesting to me how much effort is being spent on adding tools like issue tracking, build pipelines, deploy management, etc. vs just providing good hooks

It's interesting to me how much effort is being spent on adding tools like issue tracking, build pipelines, deploy management, etc. vs just providing good hooks for standalone tools that do all those things. We have discussions about Jenkins vs Concourse, where to keep ansible vault passwords, should documentation live in Github wiki or in Confluence (apparently "tech" documentation in the form, "business" documentation in the latter - what if it's both? Who decides?), and so on. There is something nice about being able to go to a single place and saying "OK, it's all here in this box". Github has made inroads with some of this stuff, but not quite enough. Gitlab could try and do all this, but then people will moan ("I prefer JIRA/Trello/whatever"). Most of the pain around developer/business workflow around us at the moment actually comes down to the fact that nobody has _really_ thought about providing a great unified UX for all of this. Part of the concern is people want to be "flexible". No, dictate, just make sure what you dictate is a better solution to what people have. If GitLab get it right, github could be a minor player (unless they keep up) in a few years time.

flukus 10y ago
> Most of the pain around developer/business workflow around us at the moment actually comes down to the fact that nobody has _really_ thought about providing a great unified UX for all of this. Microsoft did with TFS. That was enough to convince me it's a terrible idea.
theunquietone 10y ago
Hey Paul - All great notes. We believe in a single solution from idea to production. More about that here: https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope We hope to make it easy to go to a single place for everything needed for development from issue boards, CI, analytics, etc. The unified UX for this tool is key and we are hiring a great team to support that goal. Later today we're having a live event to talk more about that vision and answer questions. https://page.gitlab.com/20160913_unveilingmasterplan_landingpage.html https://page.gitlab.com/20160913_unveilingmasterplan_landing... Again, love the notes and how you're thinking about this. Happy we are aligned! Edit: Sorry! Removed the signature. Habit :)
- mikepurvis 10y ago
  Makes for a tough pitch at an established shop with existing tools already in place.
  - sytse 10y ago
    We want to play nice with established tools and give people the option to use them. We have: 1. Extensive JIRA integration (and we're working on improving this) https://docs.gitlab.com/ee/project_services/jira.html https://docs.gitlab.com/ee/project_services/jira.html 2. Jenkins support https://docs.gitlab.com/ee/integration/jenkins.html https://docs.gitlab.com/ee/integration/jenkins.html via our commit status API https://docs.gitlab.com/ee/api/commits.html https://docs.gitlab.com/ee/api/commits.html 3. Slack integration https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/project_services/slack.md https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/proj... and we're working on a Slack bot https://gitlab.com/gitlab-org/gitlab-ce/issues/20799 https://gitlab.com/gitlab-org/gitlab-ce/issues/20799 We realize that we should allow other tools to integrate well and want to open up as much as we can via API's.
  - theunquietone 10y ago
    We hope to create tools and resources to make that pitch and migration easier. Out of curiosity, what tools are you currently using? We think it'll be a piece by piece migration versus all at once. In a perfect world, we have a tool for an all at once migration but perhaps that will come with time.
    - mbreese 10y ago
      The problem with that approach is that you're limited by the quality of your weakest tool. Code review might be a strength, but if your CI tool is weak, that's what you'll be judged on. Integrations are a way to allow you to focus on what you do best and effectively outsource the rest. Ideally, the integration hooks would be well integrated, but I don't see an upside in trying to make a monolithic app in this market.
      - 10y ago
gumby 10y ago
> It's interesting to me how much effort is being spent on adding tools ... vs just providing good hooks for standalone tools that do all those things. This is very important. From the GL's PoV an integrated suite sounds great because the integration is easier and you can capture more of the value chain. But not only is it a barrier to adoption, if successful it squeezes out innovation. The whole point of open source is user benefit, right?
- jobvandervoort 10y ago
  Why is it a barrier to adoption? Our intend is to make it easy and possible to use only part of GitLab, whilst integrating with your other tools. The integration with our own tools will always be better, because we can do things that'd be hard with external tools, but if you want to use something else for anything, it'll work with GitLab.
  - gumby 10y ago
    > Our intend is to make it easy and possible to use only part of GitLab, whilst integrating with your other tools. ... if you want to use something else for anything, it'll work with GitLab. If that's your intent then my statement is not operative, great. But your other public statements imply (to my reading) the opposite of what you say in your comment. For example, from the announcement: > We prefer to offer an integrated set of tools instead of a network of services or offering plugins for the following reasons: and some comments from your colleague theunquietone: > We believe in a single solution from idea to production. and when someone commented "Makes for a tough pitch at an established shop" he replied: "We hope to create tools and resources to make that pitch and migration easier." It's early days so you have time to clarify/refine your story.
    - jobvandervoort 10y ago
      Our goal is to ship a single tool that will work for (almost) everyone. We believe that this will be a better experience and allow for deeper integration, besides cost, setup and maintenance advantages. That said, we don't expect to be able to replace every single tool one might use -such as internal tools-, therefore we make it possible to integrate with GitLab easily and have an API that covers everything. Examples of this are plenty. For instance, we build our commit status API to support our own CI system, but immediately also published the public API that allows any other CI to make use of this and offer similar integration in GitLab (in that case, you'll still have to switch between apps, which we believe can be better - hence our goal).
solatic 10y ago
The market will show that all-in-one box solutions are the best solutions for new companies. When you're a new startup and you're trying to race to an MVP and being default-alive, what do you really want to do? Do you really want to spend time getting all of your ALM and build pipeline and production environments up and running? Or do you want to start iterating on business features as quickly as possible? The truth is that providing 80% of the features is going to be good enough for 80% of new companies. When companies figure out that they need one of the 20% of the features that are missing, they can then migrate to get the feature that they positively identified a need for. Putting in much more effort in the beginning for ALM/pipeline/environment features you may not even need is a form of premature optimization.
- sytse 10y ago
  We both see the value of all-in-one solutions for new companies. I think that for existing companies there is a comparable amount of value. All-in-one solutions make it easier to switch to a new team and be effective immediately. And it allows for company wide processes and tools. The 20% missing features can be added via API's (we're trying to add API's for everything people need https://docs.gitlab.com/ce/api/ https://docs.gitlab.com/ce/api/ ). Or even better, by having people contribute code to the project itself.
ryanackley 10y ago
Way easier said than done :) As someone who has been doing product development their entire career, I have found there to be an economy of focus in a software company when it comes to product development. I think it's a great vision for Gitlab but it's risky because it splits their focus into like 6 beams. The major players in the market (Atlassian, GitHub) already have this vision and they are there already pretty much. The market wants flexibility in their tools in spite of what people on HN tell you. Atlassian has tools for every lifecycle stage but people still mix and match with other tools. Github is missing a few of these stages but I'm sure they are hard at work filling in the blanks. I know people who use GitHub and JIRA together even though GitHub has it's own issue tracker.
- sytse 10y ago
  I agree it would be risky to go on this path. So when Dmitriy wanted to make CI years ago I told him to keep the main thing the main thing. Why reinvent the CI wheel, our efforts were better spent making our Jenkins integration better. But I didn't stop him. And what I learned was that we were able to do CI and make it a better product that what was on the market. That was counterintuitive for me. But we've since seen the benefits of integrating CI, CD, issue boards, and a docker container registry. We still have lots of work to do integrating Mattermost, Koding, Cog, Prometheus. But we're convinced we can do a better job. If you look at what we shipped last month I hope you can see the rate of improvement https://about.gitlab.com/2016/08/22/gitlab-8-11-released/ https://about.gitlab.com/2016/08/22/gitlab-8-11-released/ And to make sure we have enough capacity going forward we hire remotely, use open source collaboration processes, and just raised more capital.
- deleted 10y ago
  [deleted]
sytse 10y ago
I used to think that a collection of standalone tools was better and that we should focus on code hosting and review. When Dmitriy started with GitLab CI I was dismissive but of course as the author he could do as he pleased. It turned out that having a CI tool that closely works together with the main product was a better experience, especially behind the firewall/single-tenant/on-premises. Then Dmitriy and Kamil (our CI lead) proposed integrating the CI coordinated into GitLab the main program instead of a standalone Ruby on Rails app. Again I was sceptical. But this has been a great success. We have all the API's (webhooks, commit status API, etc.) to integrate well with Jenkins (and we'll make sure that we'll always play well with that, JIRA, Slack, and others). But having everything in one interface and one datastore makes for a much better user experience. We've since doubled-down on this strategy. Bringing the entire software development lifecycle under one roof https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope During the webinar we'll show a demo video of how these components will soon work together. We think it is an amazing experience and everyone on our team is focussed to get it right.
- contingencies 10y ago
  Give me a rolling upgrade AWS/Rackspace/wherever (I choose) private hosted version of Gitlab with everything just working for under or equal to Github's USD$25/month and you have my business. Do a bulk deal, get some custom instances, lower the overheads. IMHO the pain of Gitlab (which I've used ~2008-now?) has always been unfamiliarity, UI obtuseness (recently vastly improved) and maintainability. Kill those - you're well on the way to doing so - and you'll gain market share quickly. You can even sell stuff like storage space, redundancy and global POPs as real time deployable add-on packages.
  - brodock 10y ago
    Did you know about https://githost.io/ https://githost.io/ ? It's managed by GitLab Inc and it's the closest you get from "Insert your credit card here, and hit a button" to get your own GitLab instance.
    - 10y ago
bobbyi_settv 10y ago
> nobody has _really_ thought about providing a great unified UX for all of this. Isn't the Stash-Jira-Bamboo-Confluence stack a unified UX for doing all of this (source control, pull requests, deployment, docs, issue tracker, build pipeline, etc)? It may not be a great UX, but can we at least give Atlassian credit from probably having thought about it having a great UX?
- nathan_f77 10y ago
  That's funny, because you're right, and Atlassian has an enormous head start. And it's hard to explain why I like GitLab so much more. I used the entire Atlassian suite for 3 years at my first web development gig, when I started over 7 years ago. I just have all these memories of things being ugly, slow, and hard to customize. Although I had a mostly positive experience with Confluence. Bamboo was just not nice to use. BitBucket does most of the same things, but it just didn't feel nice to use. Maybe it's the UI, or the dark blue theme. Maybe it's purely psychological, like GitHub was the place where all the cool developers hang out, and BitBucket is the corporate nerd who just wants to fit in so they give away all their private repos for free. So I dumped my private, personal stuff on BitBucket, until GitLab came along. And honestly, up until the last few months, I actually really disliked GitLab. I kind of saw them as just rip-offs who were blatantly copying GitHub, and stealing their customers. But then I realized that GitHub hasn't really done anything interesting for years and years, while GitLab is working on all these awesome features and integrating things that GitHub should have been doing years ago. So now my opinion is that GitHub had their chance, and they blew. GitLab is the new cool place to host your code.
  - Snappy 10y ago
    Wow, thanks for the kind words. GitLab has grown a LOT in the last year or so.
  - technomancy 10y ago
    > And it's hard to explain why I like GitLab so much more. In my case having the Atlassian all tools look the same seems to have backfired; every time I go to BitBucket it makes me think of Jira, which makes me cringe and wish I were on a different web site.
therealmarv 10y ago
Is not whole Atlassians business a unified toolset for all of this? I would not say that nobody actually tried to be that one place... I only seeing GitLab beeing the best open source solution without making a big risk with vendor lock in. And they are also cheaper than their competitors (github, Atlassian etc.) when you want to do private team development.
- kazagistar 10y ago
  I wouldn't say Atlassian has worked to make a great unified UX. I mean, they tried, but using their products makes it painfully clear that they just glued togeather a bunch of disparate projects. For example, each product supports different markup languages (or none at all) with different editor buttons and shortcuts and so on. Even the github ecosystem feels more integrated, because everyone just follows the broad strokes of what github does with its UX and integrates with it.
  - aalbertson 10y ago
    ...and keyboard shortcuts....don't forget about those!
- chrisseaton 10y ago
  I feel like every Atlassian product has a totally different Markdown syntax for no good reason. That makes it feel very non-unified.
  - josh64 10y ago
    If they support markdown at all... (I'm looking at you, hipchat).
  - therealmarv 10y ago
    this is the number reason for me for using Slack. Although their Markdown support is also not perfect.
joneholland 10y ago
Counterpoint is team foundation server that aspires to do everything and does a terrible job at all of it
- vtbassmatt 10y ago
  Would you elaborate on the terrible job we do?
  - joneholland 10y ago
    Are you serious? TFS is such a bad product that most teams at Microsoft don't use it. You use XAML to configure builds. The source control system still uses a locking workflow. The issue tracker managed to be under powered and over complex at the same time. I had to suffer through it at two previous jobs. Never again.
  - flukus 10y ago
    Take a look at the competition. There is no single part of TFS that isn't done much better elsewhere. The only reason it still exists as a product is because of Microsofts sales force, not it's own qualities.
  - u02sgb 10y ago
    File editing/locking/merging isn't great, particularly if we've got Excel in our Source Control. We can either have everyone lock files or everyone merge. You can't merge Excel files so it means everyone has to lock or we store Excel elsewhere. Unix Client is flaky and inconsistent and doesn't get much love. I can't put a version number into a file so I can see in Prod what version the code is. I could go on.
jamie_ca 10y ago
At work, the worst thing we've done this year from a product management standpoint is migrate from Github Issues to JIRA. It was done for the right reason: to have a single place for all our work (JIRA for feature planning/sprint planning/dev+qa tracking, Confluence for documentation) but it's been hobbled because we still need github to coordinate code review + merges. The better solution would have been to stay with Github and use Huboard or something to layer on the swimlane sprint planny stuff, but keep _all_ our info in GH Issues. Moving entirely to Gitlab in a year or so once things have matured would be a great win for us, I'm sure.
- phonon 10y ago
  Why not move to Bitbucket (cloud or server) too?
setheron 10y ago
This is close to what phabricator (https://www.phacility.com/ https://www.phacility.com/) does and personally I dislike it. I like bringing the right tool from the job rather than the massive hodgepod mega site
- MaulingMonkey 10y ago
  A massive hodgepod of plugins and separately created and admined accounts is frequently just as much of a pain, IME. I like having both options so I can go with whichever option hurts less.

flukus 10y ago

> Most of the pain around developer/business workflow around us at the moment actually comes down to the fact that nobody has _really_ thought about providing a great unified UX for all of this. Microsoft did with TFS. That was enough to convince me it's a terrible idea.

theunquietone 10y ago

Hey Paul - All great notes. We believe in a single solution from idea to production. More about that here: https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope We hope to make it easy to go to a single place for everything needed for development from issue boards, CI, analytics, etc. The unified UX for this tool is key and we are hiring a great team to support that goal. Later today we're having a live event to talk more about that vision and answer questions. https://page.gitlab.com/20160913_unveilingmasterplan_landingpage.html https://page.gitlab.com/20160913_unveilingmasterplan_landing... Again, love the notes and how you're thinking about this. Happy we are aligned! Edit: Sorry! Removed the signature. Habit :)

mikepurvis 10y ago
Makes for a tough pitch at an established shop with existing tools already in place.
- sytse 10y ago
  We want to play nice with established tools and give people the option to use them. We have: 1. Extensive JIRA integration (and we're working on improving this) https://docs.gitlab.com/ee/project_services/jira.html https://docs.gitlab.com/ee/project_services/jira.html 2. Jenkins support https://docs.gitlab.com/ee/integration/jenkins.html https://docs.gitlab.com/ee/integration/jenkins.html via our commit status API https://docs.gitlab.com/ee/api/commits.html https://docs.gitlab.com/ee/api/commits.html 3. Slack integration https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/project_services/slack.md https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/proj... and we're working on a Slack bot https://gitlab.com/gitlab-org/gitlab-ce/issues/20799 https://gitlab.com/gitlab-org/gitlab-ce/issues/20799 We realize that we should allow other tools to integrate well and want to open up as much as we can via API's.
- theunquietone 10y ago
  We hope to create tools and resources to make that pitch and migration easier. Out of curiosity, what tools are you currently using? We think it'll be a piece by piece migration versus all at once. In a perfect world, we have a tool for an all at once migration but perhaps that will come with time.
  - mbreese 10y ago
    The problem with that approach is that you're limited by the quality of your weakest tool. Code review might be a strength, but if your CI tool is weak, that's what you'll be judged on. Integrations are a way to allow you to focus on what you do best and effectively outsource the rest. Ideally, the integration hooks would be well integrated, but I don't see an upside in trying to make a monolithic app in this market.
    - 10y ago

gumby 10y ago

> It's interesting to me how much effort is being spent on adding tools ... vs just providing good hooks for standalone tools that do all those things. This is very important. From the GL's PoV an integrated suite sounds great because the integration is easier and you can capture more of the value chain. But not only is it a barrier to adoption, if successful it squeezes out innovation. The whole point of open source is user benefit, right?

jobvandervoort 10y ago
Why is it a barrier to adoption? Our intend is to make it easy and possible to use only part of GitLab, whilst integrating with your other tools. The integration with our own tools will always be better, because we can do things that'd be hard with external tools, but if you want to use something else for anything, it'll work with GitLab.
- gumby 10y ago
  > Our intend is to make it easy and possible to use only part of GitLab, whilst integrating with your other tools. ... if you want to use something else for anything, it'll work with GitLab. If that's your intent then my statement is not operative, great. But your other public statements imply (to my reading) the opposite of what you say in your comment. For example, from the announcement: > We prefer to offer an integrated set of tools instead of a network of services or offering plugins for the following reasons: and some comments from your colleague theunquietone: > We believe in a single solution from idea to production. and when someone commented "Makes for a tough pitch at an established shop" he replied: "We hope to create tools and resources to make that pitch and migration easier." It's early days so you have time to clarify/refine your story.
  - jobvandervoort 10y ago
    Our goal is to ship a single tool that will work for (almost) everyone. We believe that this will be a better experience and allow for deeper integration, besides cost, setup and maintenance advantages. That said, we don't expect to be able to replace every single tool one might use -such as internal tools-, therefore we make it possible to integrate with GitLab easily and have an API that covers everything. Examples of this are plenty. For instance, we build our commit status API to support our own CI system, but immediately also published the public API that allows any other CI to make use of this and offer similar integration in GitLab (in that case, you'll still have to switch between apps, which we believe can be better - hence our goal).

solatic 10y ago

The market will show that all-in-one box solutions are the best solutions for new companies. When you're a new startup and you're trying to race to an MVP and being default-alive, what do you really want to do? Do you really want to spend time getting all of your ALM and build pipeline and production environments up and running? Or do you want to start iterating on business features as quickly as possible? The truth is that providing 80% of the features is going to be good enough for 80% of new companies. When companies figure out that they need one of the 20% of the features that are missing, they can then migrate to get the feature that they positively identified a need for. Putting in much more effort in the beginning for ALM/pipeline/environment features you may not even need is a form of premature optimization.

sytse 10y ago
We both see the value of all-in-one solutions for new companies. I think that for existing companies there is a comparable amount of value. All-in-one solutions make it easier to switch to a new team and be effective immediately. And it allows for company wide processes and tools. The 20% missing features can be added via API's (we're trying to add API's for everything people need https://docs.gitlab.com/ce/api/ https://docs.gitlab.com/ce/api/ ). Or even better, by having people contribute code to the project itself.

ryanackley 10y ago

Way easier said than done :) As someone who has been doing product development their entire career, I have found there to be an economy of focus in a software company when it comes to product development. I think it's a great vision for Gitlab but it's risky because it splits their focus into like 6 beams. The major players in the market (Atlassian, GitHub) already have this vision and they are there already pretty much. The market wants flexibility in their tools in spite of what people on HN tell you. Atlassian has tools for every lifecycle stage but people still mix and match with other tools. Github is missing a few of these stages but I'm sure they are hard at work filling in the blanks. I know people who use GitHub and JIRA together even though GitHub has it's own issue tracker.

sytse 10y ago
I agree it would be risky to go on this path. So when Dmitriy wanted to make CI years ago I told him to keep the main thing the main thing. Why reinvent the CI wheel, our efforts were better spent making our Jenkins integration better. But I didn't stop him. And what I learned was that we were able to do CI and make it a better product that what was on the market. That was counterintuitive for me. But we've since seen the benefits of integrating CI, CD, issue boards, and a docker container registry. We still have lots of work to do integrating Mattermost, Koding, Cog, Prometheus. But we're convinced we can do a better job. If you look at what we shipped last month I hope you can see the rate of improvement https://about.gitlab.com/2016/08/22/gitlab-8-11-released/ https://about.gitlab.com/2016/08/22/gitlab-8-11-released/ And to make sure we have enough capacity going forward we hire remotely, use open source collaboration processes, and just raised more capital.
deleted 10y ago
[deleted]

sytse 10y ago

I used to think that a collection of standalone tools was better and that we should focus on code hosting and review. When Dmitriy started with GitLab CI I was dismissive but of course as the author he could do as he pleased. It turned out that having a CI tool that closely works together with the main product was a better experience, especially behind the firewall/single-tenant/on-premises. Then Dmitriy and Kamil (our CI lead) proposed integrating the CI coordinated into GitLab the main program instead of a standalone Ruby on Rails app. Again I was sceptical. But this has been a great success. We have all the API's (webhooks, commit status API, etc.) to integrate well with Jenkins (and we'll make sure that we'll always play well with that, JIRA, Slack, and others). But having everything in one interface and one datastore makes for a much better user experience. We've since doubled-down on this strategy. Bringing the entire software development lifecycle under one roof https://about.gitlab.com/direction/#scope https://about.gitlab.com/direction/#scope During the webinar we'll show a demo video of how these components will soon work together. We think it is an amazing experience and everyone on our team is focussed to get it right.

contingencies 10y ago
Give me a rolling upgrade AWS/Rackspace/wherever (I choose) private hosted version of Gitlab with everything just working for under or equal to Github's USD$25/month and you have my business. Do a bulk deal, get some custom instances, lower the overheads. IMHO the pain of Gitlab (which I've used ~2008-now?) has always been unfamiliarity, UI obtuseness (recently vastly improved) and maintainability. Kill those - you're well on the way to doing so - and you'll gain market share quickly. You can even sell stuff like storage space, redundancy and global POPs as real time deployable add-on packages.
- brodock 10y ago
  Did you know about https://githost.io/ https://githost.io/ ? It's managed by GitLab Inc and it's the closest you get from "Insert your credit card here, and hit a button" to get your own GitLab instance.
  - 10y ago

bobbyi_settv 10y ago

> nobody has _really_ thought about providing a great unified UX for all of this. Isn't the Stash-Jira-Bamboo-Confluence stack a unified UX for doing all of this (source control, pull requests, deployment, docs, issue tracker, build pipeline, etc)? It may not be a great UX, but can we at least give Atlassian credit from probably having thought about it having a great UX?

nathan_f77 10y ago
That's funny, because you're right, and Atlassian has an enormous head start. And it's hard to explain why I like GitLab so much more. I used the entire Atlassian suite for 3 years at my first web development gig, when I started over 7 years ago. I just have all these memories of things being ugly, slow, and hard to customize. Although I had a mostly positive experience with Confluence. Bamboo was just not nice to use. BitBucket does most of the same things, but it just didn't feel nice to use. Maybe it's the UI, or the dark blue theme. Maybe it's purely psychological, like GitHub was the place where all the cool developers hang out, and BitBucket is the corporate nerd who just wants to fit in so they give away all their private repos for free. So I dumped my private, personal stuff on BitBucket, until GitLab came along. And honestly, up until the last few months, I actually really disliked GitLab. I kind of saw them as just rip-offs who were blatantly copying GitHub, and stealing their customers. But then I realized that GitHub hasn't really done anything interesting for years and years, while GitLab is working on all these awesome features and integrating things that GitHub should have been doing years ago. So now my opinion is that GitHub had their chance, and they blew. GitLab is the new cool place to host your code.
- Snappy 10y ago
  Wow, thanks for the kind words. GitLab has grown a LOT in the last year or so.
- technomancy 10y ago
  > And it's hard to explain why I like GitLab so much more. In my case having the Atlassian all tools look the same seems to have backfired; every time I go to BitBucket it makes me think of Jira, which makes me cringe and wish I were on a different web site.

therealmarv 10y ago

Is not whole Atlassians business a unified toolset for all of this? I would not say that nobody actually tried to be that one place... I only seeing GitLab beeing the best open source solution without making a big risk with vendor lock in. And they are also cheaper than their competitors (github, Atlassian etc.) when you want to do private team development.

kazagistar 10y ago
I wouldn't say Atlassian has worked to make a great unified UX. I mean, they tried, but using their products makes it painfully clear that they just glued togeather a bunch of disparate projects. For example, each product supports different markup languages (or none at all) with different editor buttons and shortcuts and so on. Even the github ecosystem feels more integrated, because everyone just follows the broad strokes of what github does with its UX and integrates with it.
- aalbertson 10y ago
  ...and keyboard shortcuts....don't forget about those!
chrisseaton 10y ago
I feel like every Atlassian product has a totally different Markdown syntax for no good reason. That makes it feel very non-unified.
- josh64 10y ago
  If they support markdown at all... (I'm looking at you, hipchat).
- therealmarv 10y ago
  this is the number reason for me for using Slack. Although their Markdown support is also not perfect.

joneholland 10y ago

Counterpoint is team foundation server that aspires to do everything and does a terrible job at all of it

vtbassmatt 10y ago
Would you elaborate on the terrible job we do?
- joneholland 10y ago
  Are you serious? TFS is such a bad product that most teams at Microsoft don't use it. You use XAML to configure builds. The source control system still uses a locking workflow. The issue tracker managed to be under powered and over complex at the same time. I had to suffer through it at two previous jobs. Never again.
- flukus 10y ago
  Take a look at the competition. There is no single part of TFS that isn't done much better elsewhere. The only reason it still exists as a product is because of Microsofts sales force, not it's own qualities.
- u02sgb 10y ago
  File editing/locking/merging isn't great, particularly if we've got Excel in our Source Control. We can either have everyone lock files or everyone merge. You can't merge Excel files so it means everyone has to lock or we store Excel elsewhere. Unix Client is flaky and inconsistent and doesn't get much love. I can't put a version number into a file so I can see in Prod what version the code is. I could go on.

jamie_ca 10y ago

At work, the worst thing we've done this year from a product management standpoint is migrate from Github Issues to JIRA. It was done for the right reason: to have a single place for all our work (JIRA for feature planning/sprint planning/dev+qa tracking, Confluence for documentation) but it's been hobbled because we still need github to coordinate code review + merges. The better solution would have been to stay with Github and use Huboard or something to layer on the swimlane sprint planny stuff, but keep _all_ our info in GH Issues. Moving entirely to Gitlab in a year or so once things have matured would be a great win for us, I'm sure.

phonon 10y ago
Why not move to Bitbucket (cloud or server) too?

setheron 10y ago

This is close to what phabricator (https://www.phacility.com/ https://www.phacility.com/) does and personally I dislike it. I like bringing the right tool from the job rather than the massive hodgepod mega site

MaulingMonkey 10y ago
A massive hodgepod of plugins and separately created and admined accounts is frequently just as much of a pain, IME. I like having both options so I can go with whichever option hurts less.