

One year of Redis - jcsalterego
http://antirez.com/post/one-year-of-redis.html

======
kssreeram
"So make a careful choice when starting the development of a new open source
project, don't pick something you are interested in today, but something
you'll probably be interested in for the next decade."

+1 for that. Sustaining opensource projects is hard. I feel sad when I see
that I've not been able to maintain my own opensource project
(<http://cspace.in>) for more than a year.

~~~
thwarted
Wow, cspace looks like a really interesting project. The concept is explained
well with _connect(user, service) is like connect(ip, port)_ and shows its
generic build-on-this power.

I've had problems with becoming demotivated and uninspired on open source
projects that don't attract any other experienced developers, even to just
shoot the shit about the design and implementation (even if they don't want to
contribute code). I don't think this means one should feel bad, it just means
the market isn't necessarily there, and as open source developers, we'd rather
be coding than marketing. But still, the open source ecosystem as a whole is
richer, even if slightly, for an open source release, even if it ends up being
unmaintained.

~~~
kssreeram
Thanks.

I do hope to revive cspace sometime in 2010.

------
cmelbye
I love the Redis project. Whenever I see that a new feature is going to be
implemented, I think "Oh, it's an open source project, we _might_ see that in
a year." But antirez is so good at implementing new (and incredibly useful
features) that it's usually done in a matter of weeks or a few months! Happy
New Year, Redis! Looks like there's a lot more in store for the project in
2010.

------
alexpopescu
These are all fantastic advise for any open source project. A couple of days
ago, I was arguing that for NoSQL projects in particular there is an
additional required step: making sure that it is easy to be used from major
frameworks and that this integration is "as seamless as possible" (you can
read the whole thing here <http://nosql.mypopescu.com/post/299775877/nosql-to-
people>). With all the NoSQL solutions around, right now it is quite difficult
to pick the one that fits your problem. Making it simple to try it out will
generate a lot of use cases and that will make further adoption even easier.

:- alex

ps: (excuse and/or ignore what probably can be seen as a plug) on MyNoSQL
(<http://nosql.mypopescu.com>) I am trying to follow some of the most
promising NoSQL projects and Redis is one of them. And according to the stats,
there is a lot of cool activity around Redis.

------
simonista
I'm curious about this: _Don't expect tons of code that you can actually
merge_. Is this a general open source phenomenon? Are there good ways of
managing a project to encourage more high quality code submissions from users?

~~~
pieter
I think it's general for open source, most source contributions aren't very
good in the first round.

The trick is to keep potential contributors enthousiastic enough to take your
comments well and rewrite the patches to conform to the standards of the
project. I have had the same observation as antirez, but haven't found a
solution yet.

~~~
notauser
It's true of a lot of commercial code as well. How often do junior devs and
contract coders deliver something perfect on the first try, especially if they
are coding for their problem and you are trying to keep the needs of the whole
community in mind?

------
ideamonk
Is the python api still broken? I tried storing some gzipped binary data, it
stored, but fetching it out always ended in encoding failures. Has this been
fixed in the python interface?

~~~
antirez
Hello idealmonk, I think there is a new version of the Python bindings with a
lot of bugs fixed. Not 100% sure your issue is fixed as I mostly use the Ruby
bindings at work, but here is the link: <http://github.com/andymccurdy/redis-
py/>

~~~
ideamonk
Ah fixed the issue I was facing :) Thanks!

/me jumps back to redis with the new binding.

------
Aleran
"There will be somebody that will contribute code actually, but most of the
times this code will be about features you don't want to implement, or will
not look like sane enough to be merged without a profound review, or will
solve a good problem in a way that is not general enough, or simply the coder
does not understand enough of the Redis internals or about your future plans
to provide an implementation that is acceptable."

When this happens should the maintainer write back to the contributor and
explain to them how they would like to code to be written instead (can be very
difficult to explain). Or if the maintainer has time should they fix the code
up themselves and merge it in?

