Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YDyo8v1tDanf8LSw-KeENb2gjigRMknpY=LpR1kfePOzQ@mail.gmail.com>
References: 
 <CA+YLJLv6wFXpKpuFCxYr8Lzg69AX7d1n2ACwF8N+eeHmLd4SjA@mail.gmail.com>
	<CAJ_m3YDyo8v1tDanf8LSw-KeENb2gjigRMknpY=LpR1kfePOzQ@mail.gmail.com>
Date: Sat, 14 Apr 2012 15:39:22 +1200
Message-ID: 
 <CA+YLJLtooLCGFCCV+CPWujJONvNA_d_P51UuoC5F5p-WxiX8dA@mail.gmail.com>
Subject: Re: (perceived) barriers to entry
From: Tim McNamara <paperless@timmcnamara.co.nz>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

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 <paul.joseph.davis@gmail.com> wrote:
> On Tue, Apr 10, 2012 at 8:46 PM, Tim McNamara
> <paperless@timmcnamara.co.nz> 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).
>
> http://antirez.com/post/redis-persistence-demystified.html
>
>
>>
>> "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.
>
> http://horicky.blogspot.com/2008/10/couchdb-implementation.html
>
>>
>> "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