
Ask HN: BugsEverywhere was a great idea – why didn't it catch on? - smoyer
The BugsEverywhere (http:&#x2F;&#x2F;docs.bugseverywhere.org&#x2F;1.1.1&#x2F;)project has been dormant for a good five years but the idea of including a distributed bug database alongside your code seems like a no-brainer.  Several other systems (Fossil, AccuRev, Veracity) include this functionality but I&#x27;m wondering why BE didn&#x27;t catch on with the CLI crowd since it can be layered on top of a variety of SCM systems.
======
WorldMaker
I'm also someone that fell in love with the concept of issue databases as
source control artifacts.

I think the biggest problem is always going to be the "Stakeholder" issue, and
just about everyone else is touching on this too. Issue databases solve a
number of different problems for a number of disparate roles of people. As
much time as developers spend embedded in an issue tracker, you also have PMs,
Managers, Executives, Clients, Customers, Testers, and sometimes a panoply (or
even panopticon) of all sorts of other "stakeholders" with one reason or
several to be in and out of an issue database scattered across a wide variety
of technical acumen.

For anything more than a small team of only technical people, one or more
systems of reporting (in either direction) becomes generally required. Can
Clients or Customers submit new issues easily? Can PMs (or Managers or
Executives) get the reports they need? Can Testers accept issues as completed
or file new bugs on them?

There's so much more workflow than just the Developer side of things, for
better and sometimes for a lot worse. (The "Jira Effect" where nearly every
issue tracker eventually seems to succumb to becoming a super-configurable
business workflow engine with a built-in CRM and a support desk ticketing
system and a hideous kitchen sink with terrible load times.)

There's probably still a chance to find a really good sweet spot for
distributed issue tracking that has just the right amount of bidirectional
reporting to fill an average development team _and_ their stakeholders' needs,
but it's probably going to take a smart UX team to do it. A CLI-only approach
seems unlikely to work, again just given the huge swath of technical acumen to
be found with fingers in an issue tracking pie.

~~~
viraptor
I'm not sure that's a big issue really. The repository is just a database.
You're not forced to work on them manually with the low level tools.

There's nothing that would stop you from putting a full blown jira-like UI
which interacts with that database. Well... Apart from that UI not existing
yet. But in theory, you can have both. With a centralised main head in the
same way people use central repository for git.

~~~
shoo
> I'm not sure that's a big issue really. The repository is just a database.

in large non-tech companies i see a pattern where the company adopts standard
open source tools arguably better suited to open source distributed
development (many small git repos, github/gitlab) -- but then there can be
pressure to present information for ease of central governance and control

at $current_job there's pressure for 100-200 people to use a single jira
project so auditing and risk can be done via that one jira project, whereas at
the same time there are an increasing number of git repos containing code for
different systems (or ci/cd/build scriptery for different systems)

the jira project everyone is forced to use has about 100 different states a
ticket can be in (many synonyms) and about 30 different custom relationships
defined between pairs of tickets - so it is challenging to sanely encode or
track the state of tickets (lowest-common-denominator meaning that it cannot
be a fair approximation of the reality of an individual team's process) while
also being absurdly slow.

i am not quite sure what my take away is but it is completely non obvious how
putting the issue tracking db in a single git repo would materially help any
of this. a sufficiently entrenched bureaucracy can destroy the value of any
technology...

~~~
viraptor
> but it is completely non obvious how putting the issue tracking db in a
> single git repo would materially help any of this

I think it could actually prevent bureaucracy from destroying the value. They
can have whatever reporting, enforced flows, business states, etc that live in
the repo. You get all of that info locally - so you can create a minimal, lean
interface for only the small part of it that matters to you. One of the
problems I had with JIRA where I used it was that it grew into a monster, even
though I only needed maybe 3 functions out of it. It could be simplified from
my side, but... the API was not exposed because corporate rules and the number
of requests that would require to enable, made it useless to try.

------
cjbprime
Hey, I maintained Bugs Everywhere for a while! For four years starting in
2008. It sure seemed ahead of its time.

But also, behind the times in one important way. GitHub has created an
expectation that anyone in the world can open an issue against and collaborate
with a project. That's incompatible with requiring Git push access to make
changes to issues.

I created another project -- GitTorrent -- which also tried to increase the
decentralization of software production, and this tension of collaboration
benefitting from centralized spam fighting and access control mechanisms was
there, too.

Hopefully one day there'll be magic spam fighting blockchain decentralized
identity dust that makes everything work with p2p.

~~~
ChristianBundy
> Hopefully one day there'll be magic spam fighting blockchain decentralized
> identity dust that makes everything work with p2p.

If you aren't already familiar, you might dig Secure Scuttlebutt. Dat is also
in a very similar space.

~~~
cjbprime
I really like SSB, but it doesn't work for this use case where a random person
wants to open an issue on a repo. In SSB, you (as the open source project
maintainer, say) only see content from people whom _you_ follow, or are part
of your network graph. So random person's attempt to file an issue is
invisible to you on the network. Because it's a gossip network.

~~~
ChristianBundy
> In SSB, you (as the open source project maintainer, say) only see content
> from people whom you follow, or are part of your network graph.

This is exactly right, and is one of the main reasons we still use GitHub for
issue tracking. There's some internal Git + issues + npm registry
infrastructure that some of us use, but it only works when other contributors
are within your web of trust. It also depends on SSB working, which means that
broken SSB installations can't report bugs (!).

The main implementation defaults to downloading content from people you follow
and people that they follow, but this could (and should (in my opinion)) be
increased once we've finished partial replication and off-chain content. I'd
prefer to download a public message addressed that's 5 hops away over a
private message from 4 hops away, but right now we don't have infrastructure
to do that.

Potential friends that are connecting to the network for the first time and
are experiencing bugs should probably have some public bug tracker that they
can report to, but I'd imagine that once someone confirms your issue that it'd
be moved from purgatory into the formal bug tracker.

Bias disclaimer: I'm _very_ skeptical of GitHub-style issues, where anyone can
add items to your todo list, and I'd really like to experiment with systems
that require maintainer consent before an issue is hosted on the bug tracker.

------
PaulHoule
I like the idea of the bug database synchronized with the code base, becoming
part of the documentation, but here are my concerns.

Often people who are not developers put "issues" into the bug tracker and they
might not find working with the command-line easy.

If an instance of the system is in use by many, debugging a problem
experienced by a particular user might involve personally identifying
information which should not be checked in with the source.

Also issue trackers sometimes deal with multiple branches of development. In a
sane place you might have 4.8 and 4.9 in production and a 5.0-dev, fix a bug
in 4.9, then port the fixes to the other branches. To do this you are thinking
about the tree as a whole and that's easier done from outside rather than
inside the tree.

~~~
flukus
> Often people who are not developers put "issues" into the bug tracker and
> they might not find working with the command-line easy.

IME it's best not to have non-technical people entering bugs, they should be
submitting through email, a simple form, automated crash tracker or something
along those lines. Most issue trackers will contain so many fields that will
make zero sense for someone outside (or even inside) your organisation. They
won't know the priority, the won't know the component, they can't find
relevant logs to attach, they don't know the internal workflow, they aren't
familiar enough to search for similar issues. And that's before you get to the
corporate mandated fields, there's some on our issue tracker I don't know, I
have no idea if something is capitalizable. Similarly I don't think I've ever
put in a successful request to our internal desktop support system, I have no
idea what their division of responsibilities are and somehow always select the
wrong team.

I've become quite religious about creating issues on behalf of people when we
get support requests or relevant lunch room chats, otherwise nothing makes it
up their side of the corporate org chart and back down ours.

------
michaelmure
Shameless plug warning. I'm the author of git-bug
([https://github.com/MichaelMure/git-bug](https://github.com/MichaelMure/git-
bug)), a distributed bug tracker actively developed (even a gsoc this
summer!). If you are interested by this topic I would very much like you to
give it a try or even contribute.

git-bug try to improve over the previous iteration of this idea in several
ways. To answer your question, those are what I think prevented them to catch
on:

\- it doesn't pollute your project: no files are added alongside your code, no
mess during a merge, bugs are stored in your repository but decoupled from
your code workflow

\- it doesn't impose an interface: as you prefer, you can use the CLI tools,
the interactive terminal interface or even a webUI. You could also integrate
it to your editor, CI system ...

\- it allows outsider of the project, client, users ... to browse and open
bugs, without asking them to install anything. Admittedly, git-bug is not
there yet, but the goal is to have the webUI work as a public portal that a
project could host easily, accepting authentication from outside system
(github OAuth ...).

------
Izkata
There were several others active at around the same time, most with slightly
different ideas on how to store the case data. One, for example, handled it
with dot files committed as normal - no need to mess with refs.

One benefit of that method was that it was truly linked with the code, no need
for additional push/pull commands or hooks. This also meant that you could
tell the state of a case on a given branch without having to look through
commit/merge history - it would become closed on master alongside the code
merge.

That was also its downside though, since a case could have different
comments/status on master vs branches where they started, you had to actually
check each branch to see if someone else had already begun or not. Not having
a grand centralized view was that one's downfall.

------
girishso
Distributed databases like git you mean? Even git is no longer used as
distributed database, thanks to GitHub.

~~~
CraftThatBlock
Git being "distributed" version control is meant as distributed because it
doesn't require a central checkout server, and GitHub is simply a distribution
(not checkout) server

~~~
girishso
Yes absolutely, but I meant the workflows most people use these days (PRs) has
turned GitHub into a “central” server.

------
ChristianBundy
I think this is a great question.

I was originally interested in BugsEverywhere, but noticed that the website
linked to a demo at
[http://bugs.bugseverywhere.org/](http://bugs.bugseverywhere.org/) which
was... not a demo. This gave me the impression that the project was completely
dead, so I moved on.

Recently I've been looking at git-bug, which is similar, but I've been
hesitant to use it because the readme talks about how it's alpha software and
I'm not super excited about the demo web interface.

I'd be interested to hear what others think.

~~~
smoyer
I have a clone of the final repository state and had created a Java
implementation in about 2013. I was interested in integrating it with Github
and Eclipse at the time. Now I'm wondering about resurrecting that project and
converting it to Go but I don't want to create something that doesn't get
used.

------
jfkw
I also favor issue tracking integrated with the source code and experimented
with most of these systems. The first roadblock I noticed to using distributed
issue trackers was that the client programs need to be extremely convenient to
install on the personal OS and mobile device of everyone involved in the
project, something which is very difficult to deliver. A web interface with
editing capability could cover some cases, but then you're obliged to host it
on a server somewhere.

------
frou_dh
I would posit that the vast majority of working programmers have always-on
internet while working. So an offline-capable bug tracker is not actually that
much of draw.

~~~
jazzkingrt
Maybe I'm a special case, but once in a while I'm working on a local branch
somewhere that doesn't have internet access, like on the subway.

I feel this is directionally the same win as the offline capability of a VCS
like Git itself. If we have it, we come to expect it. And if someone took it
away for some reason, we'd have a better conception of just how useful it can
be.

------
freeone3000
Our CI already has a bug tracker. In addition, I think making a commit every
time you change bug status (priority, etc) then having to resolve bug database
conflicts is less than ideal.

