5 ms·
This article really resonated with me. Especially the integration is something we can uniquely do. At GitLab we'll build the GitLab IDE in 2018. It will be a si
by sytse 9y ago
This article really resonated with me. Especially the integration is something we can uniquely do. At GitLab we'll build the GitLab IDE in 2018. It will be a single user thing at first but the article has a couple of great ideas for to do it with multiple users.
- procrastitron 9y agoThis resonated with me except the part about integration. The article seems to assume tight coupling between tools as a prerequisite for seamless integration between them. I am the maintainer of git-appraise, and its founding precept is that tools can be loosely coupled and still seamlessly integrate together. All they have to do is store their data in the git repository in a common format. The result works well. For example, a commit can be built by both Travis and Jenkins, and other tools can show both results without caring which tools produced them. The rest of the suggestions seemed reasonable, though.
- kartickv 9y agoAuthor here. If you can build a seamlessly integrated user experience from separate tools, that's fine with me.
- elygre 9y agoAh, please don’t. I love GitLab, made it a corporate standard accessible to every single employee. But the current problem space is already huge, and you are struggling to solve all of it properly. Branching off into an entirely new dimension, like an IDE will be, will make it even harder for you to satisfy existing customers.
- sytse 9y agoThanks for using GitLab. Overextending ourselves is a concern we share. Where in the problem space so you think we struggle most?
- kartickv 9y agoThat's the problem with enhancing existing tools — you have to choose between satisfying existing customers in the short term. The best vehicle for my ideas may be a new tool built from scratch. Sure, reuse code fragments or libraries, but don't feel constrained by backward compatibility.