All of the “first wave” of development is complete, and the code’s currently undergoing some pre-release testing, but I should be able to release FXRuby 1.6 some time next week. This release will provide support for all of the new features in FOX 1.6, and includes all of the bug fixes from the 1.4 line of development up to and including those fixes made in version 1.4.6.

When I say that I’ve finished the first wave of development, what I mean is that I’ve made all of the necessary updates to make FXRuby compatible with FOX 1.6. I have not yet begun work on any of the new features that I’d like to introduce in the FXRuby 1.6 line, but some of those features include:

• As previously discussed, there are some global API changes that I’d like to make to the naming of classes and methods in FXRuby.
• Per a couple of different feature requests, I’d like to do something to address the problems that occur when a programmer fails to call create() on a newly-constructed resource such as a new icon, or a new child window.
• Not a code feature per se, but I’d like to organize some effort to produce more tutorial-style documentation for FXRuby.

Another thing that I’m investigating is how to open up FXRuby a bit more. FXRuby development has for the most part been a one-man operation for the 5+ years that it’s been around. As my life gets more and more complicated, I’m finding less and less time to put into the development, support and maintenance of the code — so something needs to change for the project to stay relevant.

I’m currently reading through Karl Fogel’s book, Producing Open Source Software, and there’s a lot of good information in there, even for people who’ve been immersed in the open source software world for a long time. One of the big take-away points for me is that in order to attract new developers to help share the load (especially in terms of handling support requests and debugging users’ problems), I’m going to have to write some developer documentation. And by developer documentation, I’m talking about documentation of the FXRuby internals and how things are actually implemented. FXRuby is somewhat of an ugly beast on the inside, and I can imagine that it would be daunting for a new developer to wrap their mind around the code base so that they could begin contributing.

Amy Hoy of Slash7 has written a guide to help software developers spot “help vampires”:

Identifying Help Vampires can be tricky, because they look like any ordinary person (or internet user, whichever is lesser). But by closely observing an individual’s behavior using this handy checklist, you too can identify Help Vampires in the field:

• Does he ask the same, tired questions others ask (at a rate of once or more per minute)?
• Does he clearly lack the ability or inclination to ask the almighty Google?
• Does he refuse to take the time to ask coherent, specific questions?
• Does he think helping him must be the high point of your day?
• Does he get offensive, as if you need to prove to him why he should use Ruby on Rails?
• Is he obviously just waiting for some poor, well-intentioned person to do all his thinking for him?
• Can you tell he really isn’t interested in having his question answered, so much as getting someone else to do his work?

Read the whole thing, especially if you’ve taken to sleeping a lot more during the daytime as of late.