couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CGS <>
Subject Re: (perceived) barriers to entry
Date Wed, 11 Apr 2012 08:50:16 GMT
Hi Tim,

I am not a developer and I don't think I will be too soon as my free time
doesn't allow me that. But I've been helping the users to get their
products based on CouchDB done and I noticed 4 types of problems a new
developer can attempt to solve:
1. installation problems on different platforms;
2. compatibility problems with different external software;
3. undesired (but understandable) differences in functionality (e.g., push
vs. pull replications);
4. new cool staff.
If you have time, you may want to start with point 1 and, in time, to reach
point 4. In time you reach point 4, the confidence is built up and no need
to ask yourself if you are good or not for this project because you are
already involved in it.

Now, my thoughts about the problems you raised.

"serious business"
Once one thinks that way, then it's clear he/she needs this task just for
adding it at CV. If you do it because you really would like to help, I am
sure you will get help with your ideas if you don't manage by yourself.
Does everything works in Linux? I recall the time when wireless drivers
under Linux were really bad. Implement your ideas at the best of your
knowledge and if they work for you, there are many chances to work for
everybody (after all, Erlang is supposed to work in the same way on
whatever platform).

"Erlang, wtf"
One way to learn it is reading and trying to understand the code. One step
further is to add your own modules. This requires only time and
willingness. Not to mention that there are parts in this project which have
nothing to do with Erlang.

"I still don't understand rereduce"
Good point. There may be many points you have no idea how they work or what
they actually implement. But nobody asks you to develop CouchDB from
scratch. Just focus on what you know at the beginning and leave what you
don't know for later.

"Where are the easy bugs?"
Really? The easy bugs which are solved are those reported here. Just look
at the users list and see how many easy bugs are reported there almost
every day and they are not reported in the dev list. That's because they
are easy bugs which can suffer a workaround rather than the intervention
from the devs (e.g., tests compatibility in different browsers or
incompatible tests in the configure script which, in the end, attracted the
devs attention, but there are still problems there). You can start by
fixing those bugs.

"wow, big code base"
I think there are few devs here who can claim they know the full code and I
haven't seen any message here saying "RTFM" for those who don't know
everything. As far as I noticed here, there is a tendency of collecting the
knowledge and not to show off with what one knows. Why should it be
different for the newcomers? If you have time to study all the code, then
it would be great. Nevertheless, in my 2 cents opinion, it's useless to
understand the full code from the beginning because you are not going to
work on optimization of the code at that point, correct?

"Apache project?"
Well, it's not like you sign a contract with ASF. I am helping in
maintaining the documentation on wiki when it's needed, but I have no idea
how it is to work for ASF. It's nothing else but a contribution to a
freeware community-based project. Create your own git repository, report
your modules and if they proved to be useful, your modules will be added
into the CouchDB repository (that I noticed while following this list, but
I might be wrong). In time you will be given the committer rights. This is
general for all the community-based projects and, therefore, it has nothing
to do with ASF at this stage. It may be, like in most of such projects,
that from time to time ASF will reward your efforts, but, mainly, people
here are doing it without that thought (I think).

As I said, even if I wanted to become a dev, I am not able to take that
step because I have no time. But if I started, I would follow what I wrote

I hope these thoughts will help removing the "(perceived) barriers to


On Wed, Apr 11, 2012 at 2:46 AM, Tim McNamara

> 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?
> "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.
> "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"
> "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.
> "Apache project?"
> As someone outside of the ASF, I don't really know what contributing
> on an Apache project means.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message