FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Progress on FreeTDS has been slowing down for some time now.  Once we had
three or more active developers and would receive 1000+ line patches over
the transom.  Today we're down to two, and many days it seems we're out of
breath.  It's quite common for a week or more to pass without any commits
to CVS.  That's not because there's nothing to do; it's because there's no
one to do it.  

You could change that.  

Why would you?  

The best reason is to do something you otherwise can't: exercise your best
judgement, and improve your skills by doing something you otherwise
couldn't.  A free software project is more patient, and more demanding,
than any boss you've ever had.  Patient, because you set the deadline;
Demanding, because your code has nowhere to hide.  If it's not your best
work, you can't say you didn't have time or that no one cares.  If you
don't think working in the open will make you a better programmer, ask
someone who's done it.  

Database communication library programming in particular, I happen to
know, is both challenging and interesting.  It forces you to think very
clearly about data, about what is available when, about what is safely
stored and what is still in flight.  A database can store *anything* (OK,
not a can of peas, but any kind of data) and must do so in such a way that
various clients can all use it while remaining blithely ignorant of the
details.  Endianism?  Encoding?  Timeouts?  When most people first down to
"deal with the database", they barely know those issues exist.  From
inside the library, though, you're a universal translator, a magician
keeping each client happily ensconced in his own illusion.  

Not every task requires intimate knowledge of the code, and FreeTDS offers
free on the non-job training.  Answering questions on this list is a great
way to start.  Dig into the code, see if you can find the answer.  If not,
say where you got stuck.  As you research more questions, the structure
will become clearer, and pretty soon you'll write your first 10-line
patch.  

Or maybe you learned C years ago but nowadays spend your time in C++
frameworks or Java libraries or ... meetings.  Working on a C library with
command-line tools can be bracing, like a bicycle ride by the ocean.  

freebcp really needs an option designating a file's encoding.  Fixing that
doesn't require deep TDS mojo.  Instead of taking the encoding from
freetds.conf, it has to come from the comamnd line.  

We also need more, more flexible, and better tests.  We've started to make
the unit tests more portable.  Any work on them, from improving their
specificity and fussiness to completely overhauling the framework would be
a signficant contribution and an easy way to start.  

There's also non-coding work.  It would be wonderful if someone would
apply some TLC to the website.  For example, summarize the progress once a
month on the News section.  Or work a little CSS magic.  

+++

Some of the current torpor is my doing.  In my enthusiasm to help, I
sometimes crowd out others, or give them reason to think, "Why should I
answer?  James will soon enough."  That contributes to a kind of us/them,
developer/user dichotomy, the antithesis of community.  

To correct that, I offer two things:

1.  I'll keep quiet on the list.  If you answer a question instead of me,
you're doing us both a favor.  (I won't be totally absent, though.  I
don't like to see questions go unanswered.) 

2.  Mentoring.  If you want to answer a question or work on a bug, and
find yourself stuck, you can email me on-list or off.  

That's all I can think of that I can do, although I'm open to suggestions.
 The real quetion is, what about you?  

--jkl