couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McNamara <>
Subject Re: (perceived) barriers to entry
Date Sat, 14 Apr 2012 03:39:22 GMT
Thanks to everyone who has responded to my points. It's really
encouraging to hear everyone's supporting thoughts.

On 12 April 2012 00:22, Paul Davis <> wrote:
> On Tue, Apr 10, 2012 at 8:46 PM, Tim McNamara
> <> wrote:
>> After chatting with Noah S on Twitter, I offered to jot up some
>> thoughts on things that my reduce or eliminate perceived barriers to
>> entry to work on CouchDB.
>> Here are a few things that I've been able to think of. In the course
>> of researching this mail though, I've actually answered many of my own
>> questions.
>> "serious business"
>> A database seems like the kind of project that only extremely talented
>> people would touch. People depend on the code working. Getting started
>> would require quite a bit of confidence. Am I good enough?
> @antirez of Redis fame did a really great post on data durability a
> couple weeks ago. If you read and understand that you're briefed
> enough to start diving into the code. Beyond those basics the advanced
> details are more about learning the details of how certain types of
> hardware reacts to those POSIX API's. Ie, stuff that @antirez alludes
> to but doesn't cover (non-volatile write caches being a fun one).
>> "Erlang, wtf"
>> This is a barrier that I've been facing for a while. I'm actually in
>> the process of learning Erlang, trying to expand my horizons from
>> Python. Still, a new language makes it harder to have the required
>> confidence.
> Heh, I still say "Erlang, wtf?" after using it for a few years. But I
> think that's true of any language I've used for any extended period of
> time. As much as I love Python it's still got its warts (outer
> variables not captured by closures?).
> In the end I would wager that a big part of the Erlang stumbling block
> is that it's also functional and that is a stumbling block for some.
> When I started with it I was like "oh, its one of those academic
> things the CS people dreamed up," and didn't get into it right away.
> But once you get into it you realize its not as hard as you made it
> out to be.
>> "I still don't understand rereduce"
>> I'm personally not 100% clear on how queries work. This is even after
>> using the db for a while. I don't want to look like a stupid idiot in
>> front of great developers. Therefore, there's a high risk of offering
>> suggestions and getting told to "RTFM"
> For this I would say come ask in IRC or on the dev@ list. There are
> also some older resources that still do a decent job of describing the
> internals. But I would say no one expects any new comer to jump in and
> tackle some of the core modules without first learning how they're
> used in other places in the code.
>> "Where are the easy bugs?"
>> [solved]
>> "wow, big code base"
>> Is there any documentation on how to project is laid out? Stepping
>> into a new project is always a little daunting.
> You're joking, right? :D CouchDB is something like 15K lines (although
> in a weird language and not as clean as it could be) but compared to
> other similar databases that's absolutely tiny.
> That said, there's not much excuse for us to not have documentation on
> code layout and the internal and external APIs and so forth. Hopefully
> we'll be doing some work in the next few months to try and address
> this issue.
>> "Apache project?"
>> As someone outside of the ASF, I don't really know what contributing
>> on an Apache project means.
> Don't worry about this. As you start contributing its the same as any
> other open source project since the beginning of open source. Look at
> the code, make a change, submit it back.
> Other than that, I would say if you're interested in contributing to
> pick one section of the code base and start reading and trying to
> understand. Do some hacking and see if you can break it or change its
> behavior in fun ways. My personal quest into the internals started at
> the HTTP layer, worked into the view engine, and then finally to the
> actual core. For me that was just what I found interesting at the
> time. I could see another approach to start at the level of couch_file
> and work outwards if that seems more approchable.
> HTH and always feel free to ask questions,
> Paul Davis

View raw message