
Memcached - Report Card for an Open Source Project - r11t
http://dustin.github.com/2009/10/22/memcached-reportcard.html
======
pierrefar
This such a greatly written appeal for bug reports. It explains why users need
to file bugs, and dives into great detail to show that bugs do get closed and
the policies of closing them (crash bugs vs other types). Kudos.

~~~
viraptor
Unfortunately filing bugs is not enough. Memcached seems to be a well managed
project, which is an exception rather than a rule (they close almost as many
bugs as are opened! - that's really amazing!) And that attitude makes a
difference.

<rant> About a year ago I got to the stage where I stopped filing bugs for
projects where I don't have a direct contact with any developer, because
usually it's just a waste of time for me. I've got issues opened with OO.o,
ubuntu, firefox, f-spot and others that weren't looked at for years. I didn't
even get a response from developers to verify most of them... OO.o is the
winner with 4 issues opened and 0 closed since 2005 followed with ubuntu with
16 triaged / confirmed (but no fixes).

Developers - please take example from memcached. If you let someone wait for 3
years, and then ask "so how do I reproduce it" the only answer you're likely
to get is "don't know, I'm using some other app since 2005, because you can't
be bothered to fix bugs"

~~~
there
it's difficult to compare a project like memcache to firefox. the memcache bug
list page can probably fit on a single screen, whereas firefox probably has
hundreds if not thousands of open bugs due to the size of the codebase.

once a list of open bugs gets too big, users won't bother searching for
duplicates or can't accurately find them, and new developers won't know where
to jump in, so the list just keeps getting bigger.

add to that the fact that many users don't include proper information like how
to reproduce the problem, test cases, backtraces, etc. and once developers
actually get around to looking at those bugs, they have no interest in
tracking down a user whose email will often bounce or isn't running the
software anymore, just to reproduce an issue that may have been fixed by some
other change months ago.

~~~
btilly
The lesson I take from that is to work hard to keep your buglist low.

As an example look at OpenBSD. By my count from <http://www.openbsd.org/query-
pr.html> they have 208 open bugs, of which they are actively working on over a
third of them. That's for _a whole operating system!_

~~~
there
yes, a few things have been done to get to that point.

1 - make the kernel tell the user exactly what to report in the case of a
kernel panic

[http://www.openbsd.org/cgi-
bin/cvsweb/src/sys/ddb/db_trap.c....](http://www.openbsd.org/cgi-
bin/cvsweb/src/sys/ddb/db_trap.c.diff?r1=1.13;r2=1.14)

2 - rewritten sendbug to remove useless fields and automatically add useful
information for developers (dmesg output, acpi dumps, etc.) to make it easier
to trace problems to specific hardware

[http://www.openbsd.org/cgi-
bin/cvsweb/src/usr.bin/sendbug/se...](http://www.openbsd.org/cgi-
bin/cvsweb/src/usr.bin/sendbug/sendbug.c)

3 - quickly respond to new bugs. if they are valid, poke a developer that will
know something about it. assign the bug to someone or at least mark it as
verified. if the bug report doesn't have the required info or isn't valid,
respond to the user and close it right away. don't let things pile up.

------
dugmartin
Since users/fans of memcached will be reading this I wanted to ask a quick
question: I wrote a debug version of memcached in Python that has a couple of
"x" commands in it - xdump which dumps all the data in the hash using the same
return format as get and xtrace which keeps the connection open and dumps the
incoming commands, values and results as they come in.

I was thinking of writing an Adobe Air app that uses xdump and xtrace to let
you view/edit usage of memcached. A friend has a project on github that lets
you do this in 1 app on a mac but the Air app would be cross platform.

Thoughts on releasing this as an open source project?

btw, the Mac app is at <http://github.com/gerardg/mcinsight> \- its a fork of
another project.

~~~
dlsspy
> Thoughts on releasing this as an open source project?

The only reason I'd say you _shouldn't_ release something as an open source
project is if you strongly feel that someone is going to hand you a sufficient
amount of cash to keep it proprietary (and even then, it's pretty easy to
convince them that there's potentially more value in your project as open
source).

I have regretted _not_ pushing projects forward as open source in the past. I
have never regretting making something open source.

------
p0ppe
It's refreshing to see such a level of humility from an open source project!

------
chwahoo
I hate to immediately divert the discussion off topic, but does anyone know
what tool can be used to make attractive graphs like the ones in this article?

~~~
dlsspy
I used this thing: <http://www.omnigroup.com/applications/omnigraphsketcher/>

~~~
boucher
OmniGraphSketcher is a great little app. It approaches the graphing problem
from the opposite direction that traditional graphings apps take.

------
boucher
This is a great report. I intent to try and start doing something similar to
this on our projects in the future. Thanks!

