On 8/13/05, Julian Leviston <jul...@coretech.net.au> wrote:
> how do u earn money from them then?
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 releases.
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 more releases.
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.
Daniel Berger wrote: > Without looking at Ruport, I added support for YAML config files in > gruf. So, say you have a config file that looks like this:
You'd need to break into some computers to see Ruport just yet :) It hasn't been released yet! However, the development head will be moved to CVS on rubyforge when the first release comes out. So it's only going to be a secret until the 28th
> Then you call Report#configure. This will automatically generate > "host" and "mailhost" methods (accessors) for you, with the values set > appropriately. The ENV tag is special in that it simply sets > environment variables for your script (which I need sometimes).
Very neat! I'll definitely look into something like this for Ruport. I don't handle ENV variables yet, though my config setup (or Jame's actually) is essentially the same.
Julian Leviston wrote: > how do u earn money from them then?
Austin put this quite well though I have to say that I've made my living off of free software thus far. Essentially I have been funded by companies to implement certain features into generic systems that they don't have much of a stake in. I make this agreement with them and all they care about is the fact that they get a product that does what they want, and they leave me free to share.
To me, anything I can share with the community, I will. I do not take straight proprietary jobs simply because I never want to lock my source in a vault for life and throw away the key. There are a ton of reasons to write Free Software, and Austin mentions many of them.
For me, it's just fun to share and get to know people and all of that good stuff.
> > Without looking at Ruport, I added support for YAML config files in > > gruf. So, say you have a config file that looks like this:
> You'd need to break into some computers to see Ruport just yet :) It > hasn't been released yet! However, the development head will be moved > to CVS on rubyforge when the first release comes out. So it's only > going to be a secret until the 28th
> > Then you call Report#configure. This will automatically generate > > "host" and "mailhost" methods (accessors) for you, with the values set > > appropriately. The ENV tag is special in that it simply sets > > environment variables for your script (which I need sometimes).
> Very neat! I'll definitely look into something like this for Ruport. > I don't handle ENV variables yet, though my config setup (or Jame's > actually) is essentially the same.
> -Greg
I've put release 0.0.2 out there which has the config support, and a few other minor tweaks and fixes.
> For as long as I can remember the end of the summer meant slaving over > some Free Software project before I went back to school. This year > will be no exception. I am currently trying to develop and mature a > pure ruby reporting tool based on a very clever hack that James Edward > Gray II shared with me (along with some great ideas). Basically, I am > trying to make a tool that will allow you to run queries against a > database and then get them to painless output to basically whatever > format you'd like weilding the power of Erb and other great tools such > as PDF::Writer. So far, the system I have built is functional but far > from robust. It allows you to execute SQL statements passed as > strings, passed in from files, or even passed in from the database > itself and then gives you a row by row iterator which can be called > from within a template OR a pure ruby file. I am also currently > working on implementing a simple DSL wrapper around SQL to allow easy > generation of queries. I have a few ideas for functions I'd like to > add, but I figured the best bet would be to ask the community what > kinds of features they'd like to see in a pure ruby report generation > tool. If you let me know what you'd like to see in such a tool soon, > there is a good chance it will end up in Ruport 0.1.0 ([Ru]by > Re[port]s) which will be released on August 28th on RubyForge. So... > if you had your ideal reporting tool in Ruby, what would it be like?
> My job is paying me to work on this project despite the fact that it is > under the GPL, therefore the more requests you make, the longer I can > justify working on this instead of the (gulp) .Net system they've been > developing.
> Below I've posted a little snippet of Ruport calling a query out of > the database itself (config and query not shown) and then generating a > PDF. This is actual functional code which prints out customer labels.
> Also... scouts honor on a first release of Gambit (The game design > software James and I built) before the end of the summer.
> With no further ado, a (rudimentary) Ruport example.
Here are my .02 eurocents about a generic reporting tool:
i would probably split it into 2 modules: data feeders and report generator/formatter. This way you will be able to find feedback from more sources for both modules. Moreover you will have a very clean separation of concerns.
Alexandru Popescu wrote: > Here are my .02 eurocents about a generic reporting tool: > i would probably split it into 2 modules: data feeders and report > generator/formatter. This way you > will be able to find feedback from more sources for both modules. Moreover you > will have a very clean separation of concerns.
> :alex |.::the_mindstorm::.|
This is a great idea and I will do my best to make Ruport model this type of separation. Ruport will be on CVS sometime later this week for a little scrutiny before it's initial release on the 28th, I will post when it is up.
In an effort to make Ruport either a) the most community inclusive project ever, or b) a real pain in the neck to the regulars, I've created a survey that you're welcome to come voice your opinion on how you'd like to see the project turn out. It's really short, 11 questions, mostly yes or no's.
It'll determine a few key aspects of how I spend the next two weeks or so, whether or not Ruport gets up on CVS before the 28th, whether or not documentation will be included with the first release, whether or not it will be split into two modules, and whether or not I'll consider a license that's even less restrictive or complicated than the Ruby/GPL combo. So if any of this matters to you, feel free to come and let your opinion be known in statistical form.
>> Here are my .02 eurocents about a generic reporting tool: >> i would probably split it into 2 modules: data feeders and report >> generator/formatter. This way you >> will be able to find feedback from more sources for both modules. Moreover you >> will have a very clean separation of concerns.
>> :alex |.::the_mindstorm::.|
> This is a great idea and I will do my best to make Ruport model this > type of separation. Ruport will be on CVS sometime later this week for > a little scrutiny before it's initial release on the 28th, I will post > when it is up.
Glad you like the idea.
Also passing through the survey I have noticed the 2nd question that is (again) imho quite tricky :-). Definitely it should be easy to use to gain a community; once you have it you will need to raise the bar and make it more and more customizable. This is something that I would say that fits best: with start small philosophy ;-).
Even if I am a Ruby freshman I would be really happy to be able to see the sourcebase very soon and even more to help.
Greg Brown wrote: > In an effort to make Ruport either a) the most community inclusive > project ever, or b) a real pain in the neck to the regulars, I've > created a survey that you're welcome to come voice your opinion on how > you'd like to see the project turn out. It's really short, 11 > questions, mostly yes or no's.
I've updated this survey and it has nearly double the questions and all the yes or no's have been changed to sliding scale, so you can be a little more wishy washy with your feelings.
A couple important things added to the survey ask about your OS and database just so I can see at of curiosity what systems and databases I should prioritize my support for (though with all luck Ruport will be cross platform). I usually stick it to Windows users when in doubt, but for Ruport this will not happen because the company that's helping fund it is reliant on a Windows farm, so for once I'll cater to you M$ guys out there ;)
I will try to stop soliciting Ruport now, though all of the discussion it has generated has become addictive. Hope you like what I have to offer come the 28th.
I will be releasing the User's Manual for my report generation and templating system Ruport tomorrow. The reason why I am releasing it before the initial release of Ruport itself (August 28) is because I am looking for a few brave souls to attempt installing and running Ruport so that they can help me streamline the installation process. I currently can only be sure that Ruport will work with MySQL and MS SQL. (Though theoretically it should be able to access any DBs that ruby-dbi does, it has not yet been tested) Anyone using other DBs are encouraged to take a look through the manual and let me know how I'd do what I'm doing for your particular system. Ruport is now on CVS and is being actively developed on in the rush for release. I am currently using setup.rb to install it, but James Edward Gray II will be preparing a gem specification for Ruport tonight or tomorrow.
If anyone is interested in taking a walk through the manual to both test out Ruport and help improve it before it's first release, please feel free to let me know on or off list.
I will not post again tomorrow announcing the release of the manual, because I've spammed ruby-talk enough already. But you will be able to find it at:
Any help would be greatly appreciated. I'd love to see suggestions on how to improve the setup and install process but just testing them out to see if they work would be quite helpful. For people fearful that Ruport will be impossible to install, do not run away yet, the features that require excessive effort are basically add on features, and you will still be able to use Ruport for most of your general reporting needs. The special features are cool though, and I'd like to make them easy to enable.
I'll announce Ruport on Sunday when it's complete. Otherwise, please let me know if you're interested in being a test driver and I'll do my best to get the manual up tomorrow afternoon.
|
