I can't speak for Tom, but I've actually never earned a penny from my
open source projects. Not that I wouldn't *love* to, but for me, it
isn't about making money from these projects. Let me briefly go through
the various projects that I have and *why* I did them:
1. MIME::Types, Text::Format: These two were originally done for a tool
called RTidy/CD which ran HTMLTidy for the Fog Creek web site
editor/manager CityDesk (hence the /CD). I needed to format the
output of the tool nicely and handle binary files differently than
HTML files, so I ported these from Perl. RTidy/CD itself is open
source, but no one ever asked me for the source and CityDesk version
2 made RTidy/CD obsolete. I keep maintaining MIME::Types and
Text::Format because I have taken them on as responsibilities.
Text::Format saw a 1.0 release recently and probably won't see a lot
of work until Ruby 2.0 (or at least the M17N strings in Ruby 1.9)
comes out and I need to look at what may need to change for that.
MIME::Types is likely to see more releases, plus a change in the way
that the whole thing works so that the core library (MIME::Type, and
the MIME::Types lookup) can be released separately from the MIME
content type data. I will also be looking at integrating
libsharedmime and libmagic functionality. I should get a new version
out soon because I have noticed that the definitions are a little
out of date, but that depends on the other work that I do.
2. Uninheritable. This library will probably never see another release,
and I'd be surprised if anyone uses it. It was more of a proof of
concept and there seemed to be a rash of requests for making classes
"unable to be inherited from" at the time that I did it originally.
3. TeX::Hyphen, Text::Hyphen: These libraries were created because of
needs for Text::Format. Martin DeMello actually ported TeX::Hyphen,
and then I modified that to Text::Hyphen (with a lot more languages
supported) to fix some bugs that existed in the original Perl (e.g.,
not Martin's fault, and VERY complex to fix, hence the new library as
I wasn't interested in creating a TeX interpreter in Ruby). The
former probably won't see any more updates by me, although Martin is
an administrator/developer on that project so he may choose to do
something with it. Text::Hyphen may see periodic updates as people
report hyphenation issues or point out that there's an updated
version of a language that I don't have converted. It will also
probably see an M17N update when Ruby has M17N strings. After that,
the library Just Works, so I expect that it will probably see few
4. Transaction::Simple: Created for the initial (technology preview)
release of PDF::Writer. It's grown a bit since then, and there are
things that I *want* to do with it that I just haven't had time to
ask how they might be done of people who are much better at Ruby than
I am (one of the big flaws of Transaction::Simple is that it can end
up duplicating objects, and this has caused an API change in
PDF::Writer that I ultimately want to change back). This will see
5. color-tools: Created for the second release of PDF::Writer (1.0) to
collect colour information in one place. It's grown since then, and
will probably continue to grow. I'm looking at incorporating
littleCMS-alike functionality (and possibly bindings to littleCMS for
performance) so that it can deal with ICC colour profiles and then
properly convert between various colour spaces meaningfully and
reversably (not all colour conversions are reversable right now).
This will see more releases.
6. Diff::LCS: Originally written to support Ruwiki. Interestingly, this
library shouldn't even have to exist, since Algorithm::Diff did most
of what I needed at the time (Diff::LCS does more, now) but was
licenced as GPL, which was not compatible with the desired Ruwiki
licence. It will see more releases, probably ultimately including
better diff support and merge support.
7. Archive::Tar::Minitar: Adapted from code provided by Mauricio
Fernandez for Ruwiki's command-line deployment support. This will
also see more releases, as I plan on adding symlink and hardlink
support, but will probably stop at that point.
8. Ruwiki: Picked up because I needed a wiki. I have plans for further
work on Ruwiki, but the changes I plan are big, and I will be looking
at the implementations of some other wikis in the meantime. This will
probably be dependent upon changes to Diff::LCS moving forward. I'll
probably be looking at the AJAX stuff that one of the Rails wikis
just added, but Ruwiki will not be moving to a web framework (it will
still be a CGI-based Wiki) and will remain flat-file based at its
core. Someone -- I *think* Gavin Kistner -- did something with node
reparenting that I may be digging into, or even reusing the OWL stuff
for future versions. There have been changes in the Ruby environment
since I last worked on Ruwiki -- Ruwiki will adapt, and I will make
it possible to upgrade.
9. PDF::Writer: This was originally written because there was a hole in
Ruby's support for PDF. It's somewhat taken over my life at this
point, and as I pointed out in a different post today, I'm working on
a release right now (well, I'm procrastinating right now) and then
I'm starting work on version 2.0 -- which will be demonstrated, in
part, at RubyConf 2005 because I'm also adding a slideshow producer.
Don't get me wrong -- if anyone wants to donate to the "Encourage
Austin" fund, I'll not turn it down. It'll help defray my costs to
RubyConf I do this because I *love* it, and it keeps me thinking
about different programming mechanisms and paradigms that I don't get to
work with at my day job. This is *very* valuable, because I've been able
to present ideas that have been accepted even though they're a bit
"off-the-wall". Because I love doing this, why should I be selfish? I
share what I do.
On 8/13/05, Julian Leviston <firstname.lastname@example.org> wrote:
how do u earn money from them then?
Austin Ziegler * email@example.com
* Alternate: firstname.lastname@example.org