3 ms·

One year of Redis

90 points by jcsalterego 17y ago

kssreeram 17y ago
"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 http://cspace.in) for more than a year.
- pierrefar 17y ago
  I think it applies to any project, not just open source ones. When the going gets tough, and it always eventually get tough, you'll need personal interest or passion to get you through.
  - kssreeram 17y ago
    Projects which help in earning your living will do fine. You'll probably end up working on it everyday. On the other hand, it's harder to find time for projects which are not related to how you make a living. And, if you struggle to find time for a project, then it's going to be hard to sustain it. Opensource projects typically fall in the latter category. The ideal situation is if you manage to establish some sort of connection between your pet project and your source of income. edit: typos
- thwarted 17y ago
  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 17y ago
    Thanks. I do hope to revive cspace sometime in 2010.
- woadwarrior01 17y ago
  I feel the the issue with cspace is that at first glance people at first glance, usually percieve it as some sort of a secure IM, and the mainstream user base for IMs doesn't really care about security. For those of us who use it, it works well. I guess its primary user base is mostly made up of people (like me) who aren't too good with evangelizing for things they use. That being said, I'm just as guilty as you for letting it bitrot. I always wanted to do something about cspace, but never got around doing anything :( disclaimer: I used to work (a long time ago) for sreeram, on cspace.
cmelbye 17y ago
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.
simonista 17y ago
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 17y ago
  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 17y ago
    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 17y ago
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 17y ago
  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/ http://github.com/andymccurdy/redis-py/
  - ideamonk 17y ago
    Ah fixed the issue I was facing :) Thanks! /me jumps back to redis with the new binding.
alexpopescu 17y ago
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 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 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.
Aleran 17y ago
"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?

90 points by jcsalterego 17y ago

"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 http://cspace.in) for more than a year.

pierrefar 17y ago
I think it applies to any project, not just open source ones. When the going gets tough, and it always eventually get tough, you'll need personal interest or passion to get you through.
- kssreeram 17y ago
  Projects which help in earning your living will do fine. You'll probably end up working on it everyday. On the other hand, it's harder to find time for projects which are not related to how you make a living. And, if you struggle to find time for a project, then it's going to be hard to sustain it. Opensource projects typically fall in the latter category. The ideal situation is if you manage to establish some sort of connection between your pet project and your source of income. edit: typos
thwarted 17y ago
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 17y ago
  Thanks. I do hope to revive cspace sometime in 2010.
woadwarrior01 17y ago
I feel the the issue with cspace is that at first glance people at first glance, usually percieve it as some sort of a secure IM, and the mainstream user base for IMs doesn't really care about security. For those of us who use it, it works well. I guess its primary user base is mostly made up of people (like me) who aren't too good with evangelizing for things they use. That being said, I'm just as guilty as you for letting it bitrot. I always wanted to do something about cspace, but never got around doing anything :( disclaimer: I used to work (a long time ago) for sreeram, on cspace.

cmelbye 17y ago

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.

simonista 17y ago

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 17y ago
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 17y ago
  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 17y ago

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 17y ago
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/ http://github.com/andymccurdy/redis-py/
- ideamonk 17y ago
  Ah fixed the issue I was facing :) Thanks! /me jumps back to redis with the new binding.

alexpopescu 17y ago

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 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 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.

Aleran 17y ago

"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?