5 ms·

I've thought about building GitHub / BitBucket tools (issue management, pull requests etc) that work with data stored in git repositories, as opposed to one big

I've thought about building GitHub / BitBucket tools (issue management, pull requests etc) that work with data stored in git repositories, as opposed to one big tool that owns the git repository and manages the data in a locked-up SQL database. We already have this for code browsers (e.g. cgit), but that alone can't compete with the "full suite" that others offer. It would have several advantages for the user: 1) You could pick your issue management separately from your code browser 2) You don't have to worry that the best tooling (Github) has some of the least reliable storage. 3) If it stored the data in git, it would work offline! The big downside is that having to "assemble your own" is more complicated for the user, and that it isn't Github/BitBucket's business model...

stephenr 12y ago
I like the idea of some good, open source tools to do the different bits, preferably focused on flexibility and ease of data access (as you mentioned) to me this would mean an issue tracker, and some kind of merge request/review tool. these could be paired with the likes of Gollum, providing a wiki. One thing though, I would really love to see them support more than just git. Mercurial shouldn't be hard to support, as it has largely similar concepts, and even though SVN is not as popular as it was at its peak, its still widely used and a very good choice for some workflows/use cases. In the same vane, I would love to see a decent stand-alone code browser that supports different VCS.
- justinsb 12y ago
  Thanks - great input (and the Gollum suggestion is a good starting point!) On multiple VCS: On the one hand, git is so dominant (for better or worse) that I don't know if the complexity is worth it. On the other, perhaps git is so dominant because github is so dominant. The answer in open source land is probably to set up a reasonable abstraction layer and let interested people provide their own implementations of the VCS-interface.
  - stephenr 12y ago
    I think I should also clarify a little.. My key focus for this would be on a more unix-philosophy approach (separate tools that do one thing well). I like the idea of using a VCS repo (again, ideally any of those supported not just git) to store related information such as issues/tickets, etc however I don't know what the practical constraints of that would be, my first thought is that issues/tickets stored primarily in a (version controlled) filesystem (and then presumably indexed on a server for web views, searching etc) would not be as intuitive as say a wiki like gollum. If the issues/tickets tool used a flexible SQL model (e.g. choice of mysql, postgresql and sqlite for instance) I would be happy with that, as the data is still quite open (to the system, owner, not as much to the individual developers admittedly)
hyp0 12y ago
"distributed tools for distributed data" Customers fear vendor lock-in, so an open platform/ecosystem for git could flourish, like java. Hopefully they'll have a better business model for it than Sun did. Maybe amazon's?
- justinsb 12y ago
  Figuring out a good business model (or a way to survive without one) is indeed the challenge here! I'm not sure that AWS's margins will support this (and historically they haven't been great at supporting open-source anyway) The fact that so much of the world's private source code is on a single public website (GitHub), which has repeatedly been hacked via relatively easy exploits, is pretty frightening to me.
  - hyp0 12y ago
    Not sure it helps, but an observation is that Oracle's relational database occupied a somewhat similar role, in that it tied together data from different sources, and enabled cross-platform interoperation. This was very important at the time, because there were several different hardware vendors, and companies didn't want to get locked in. And of course, a whole ecosystem of third-party tools grew up around Oracle - esp reporting tools, BI, warehousing, and everything had bindings for relational databases. Not sure how that translates as a business model, as no one owns git (like Oracle owned oracle). However, although Sun didn't make money from java, everyone else did - so there is a business model, just as a user of git, not an owner. e.g. reporting tools based on git; CI tools, code quality tools. So maybe the answer is to just to treat git as infrastructure, for the app you sell, as opposed to trying to make money from the infrastructure itself. Linux is a similar product.
swaroop 12y ago
FYI, Fossil[1] does distributed/decentralized bug tracking & wiki just as with the code. [1] http://fossil-scm.org/ http://fossil-scm.org/ by the author of SQLite.
- lnmx 12y ago
  There is also Veracity SCM [1], but it seems to have gone dormant... [1] http://veracity-scm.com/ http://veracity-scm.com/
grandalf 12y ago
This is the key point. Would be great if all the other tools were integrated into git itself and worked in a distributed fashion. In theory Github should be leading the way on this (per its open source mission).
- stephenr 12y ago
  No, that would not be "great" to have things like that built directly into your version control system. Built on-top of it (like how Gollum is a wiki using git for storing documents) is not necessarily bad, but a built-in system is the worst possibly solution IMO
gry 12y ago
Both GitHub and BitBucket wikis are already managed by the respective SCMs. git clone https://github.com/snowplow/snowplow.wiki.git hg clone ssh://hg@bitbucket.org/BruceEckel/python-3-patterns-idioms/wiki Also, a project atop git does issues: https://github.com/jeffWelling/ticgit https://github.com/jeffWelling/ticgit The idea is interesting to me.

stephenr 12y ago

I like the idea of some good, open source tools to do the different bits, preferably focused on flexibility and ease of data access (as you mentioned) to me this would mean an issue tracker, and some kind of merge request/review tool. these could be paired with the likes of Gollum, providing a wiki. One thing though, I would really love to see them support more than just git. Mercurial shouldn't be hard to support, as it has largely similar concepts, and even though SVN is not as popular as it was at its peak, its still widely used and a very good choice for some workflows/use cases. In the same vane, I would love to see a decent stand-alone code browser that supports different VCS.

justinsb 12y ago
Thanks - great input (and the Gollum suggestion is a good starting point!) On multiple VCS: On the one hand, git is so dominant (for better or worse) that I don't know if the complexity is worth it. On the other, perhaps git is so dominant because github is so dominant. The answer in open source land is probably to set up a reasonable abstraction layer and let interested people provide their own implementations of the VCS-interface.
- stephenr 12y ago
  I think I should also clarify a little.. My key focus for this would be on a more unix-philosophy approach (separate tools that do one thing well). I like the idea of using a VCS repo (again, ideally any of those supported not just git) to store related information such as issues/tickets, etc however I don't know what the practical constraints of that would be, my first thought is that issues/tickets stored primarily in a (version controlled) filesystem (and then presumably indexed on a server for web views, searching etc) would not be as intuitive as say a wiki like gollum. If the issues/tickets tool used a flexible SQL model (e.g. choice of mysql, postgresql and sqlite for instance) I would be happy with that, as the data is still quite open (to the system, owner, not as much to the individual developers admittedly)

hyp0 12y ago

"distributed tools for distributed data" Customers fear vendor lock-in, so an open platform/ecosystem for git could flourish, like java. Hopefully they'll have a better business model for it than Sun did. Maybe amazon's?

justinsb 12y ago
Figuring out a good business model (or a way to survive without one) is indeed the challenge here! I'm not sure that AWS's margins will support this (and historically they haven't been great at supporting open-source anyway) The fact that so much of the world's private source code is on a single public website (GitHub), which has repeatedly been hacked via relatively easy exploits, is pretty frightening to me.
- hyp0 12y ago
  Not sure it helps, but an observation is that Oracle's relational database occupied a somewhat similar role, in that it tied together data from different sources, and enabled cross-platform interoperation. This was very important at the time, because there were several different hardware vendors, and companies didn't want to get locked in. And of course, a whole ecosystem of third-party tools grew up around Oracle - esp reporting tools, BI, warehousing, and everything had bindings for relational databases. Not sure how that translates as a business model, as no one owns git (like Oracle owned oracle). However, although Sun didn't make money from java, everyone else did - so there is a business model, just as a user of git, not an owner. e.g. reporting tools based on git; CI tools, code quality tools. So maybe the answer is to just to treat git as infrastructure, for the app you sell, as opposed to trying to make money from the infrastructure itself. Linux is a similar product.

swaroop 12y ago

FYI, Fossil[1] does distributed/decentralized bug tracking & wiki just as with the code. [1] http://fossil-scm.org/ http://fossil-scm.org/ by the author of SQLite.

lnmx 12y ago
There is also Veracity SCM [1], but it seems to have gone dormant... [1] http://veracity-scm.com/ http://veracity-scm.com/

grandalf 12y ago

This is the key point. Would be great if all the other tools were integrated into git itself and worked in a distributed fashion. In theory Github should be leading the way on this (per its open source mission).

stephenr 12y ago
No, that would not be "great" to have things like that built directly into your version control system. Built on-top of it (like how Gollum is a wiki using git for storing documents) is not necessarily bad, but a built-in system is the worst possibly solution IMO

gry 12y ago

Both GitHub and BitBucket wikis are already managed by the respective SCMs. git clone https://github.com/snowplow/snowplow.wiki.git hg clone ssh://hg@bitbucket.org/BruceEckel/python-3-patterns-idioms/wiki Also, a project atop git does issues: https://github.com/jeffWelling/ticgit https://github.com/jeffWelling/ticgit The idea is interesting to me.