Shorewall Developer Tom Eastep Quits

Flaming Foobar writes "Tom Eastep has announced that he is quitting all development and support of my favorite iptables front-end, Shorewall. In his e-mail to the Shorewall Users mailing list he states that 'just cannot deal with the support and documentation frustration any more -- support, the documentation and the web site consume an order of magnitude more of my time than does Shorewall development.' I can't help but wonder if this could happen to more OSS projects in the future - will people get tired of donating huge chunks of their life to free software?"

Comments

Flaming Foobar

[myspys]

More like "Flameboy" or "Flamewar starter"?

Of course there will be OSS developers that get tired of donating huge chunks of their lives, but there will always be others who will step up and take their places.

Everyone is replacable (yeah, know, it sounds sad), but it's true (at least when it comes to OSS development).

If the code is out there, free, someone else can pick it up and continue where the last person left off.

And if no one does, then it either means that not enough people were interested in keeping the software alive/needed the software OR the software had implemented almost everything that people needed from that piece of software.

It's life, get used to it, and don't try to start flamewars.

Re:Flaming Foobar

[dcowart]

The point you're missing is that he actively supported the software himself. He also provided quality support for the software. Don't think that just b/c it's GPL'ed that someone can or will even provide the same level of support.

This same thing happened to the linux router project. And it's still dead. Yes everyone is replaceable, but someone highly qualified and actually helpful (without a jacka$$ ego) in the OSS world is a rare thing that should be appreciated.

Re:Flaming Foobar

[Anonymous Brave Guy]

Of course there will be OSS developers that get tired of donating huge chunks of their lives, but there will always be others who will step up and take their places.

Everyone is replacable (yeah, know, it sounds sad), but it's true (at least when it comes to OSS development).

I'm afraid that, one day, you'll eat those words.

I've been in a similar position to this guy, volunteering lots of my spare time to help a community I cared about but ultimately finding it too much. The one time I did say I'd like to stand down and pass the job on, no-one stepped up to take over, even among a group of very dedicated volunteers who each gave up a lot of their own time to help already. It was just too much at that time for anyone else to accept. It took a few more weeks of very hard work to clear up some of the bigger things and reduce the workload before I could find someone who was willing (though hardly enthusiastic) to take over, and I could hand the job on without feeling like I was dropping my friends and those I was supporting in the brown stuff.

"Everyone can be replaced" is a great sound-bite, until you're the one trying to find the replacement. Then it's simply wrong.

If the code is out there, free, someone else can pick it up and continue where the last person left off.

Sorry, but it really doesn't work that way. If the codebase is at all complicated, then even if it's pretty well-written and well-documented, you inevitably lose a lot if you bring in a new developer and don't have the old guy around to train him up. This is true whether your code is open source, closed source, shared source or tomato sauce. All you can do is hope that your code is well enough written and documented that the new guy can get the job done.

Re:Flaming Foobar

[Allen Zadr]

Yes and no. Both are necessary, and often features that would be "wanted" at the User Guide level are both shaped, and or made redundant at the Requirements Document level.

Having very good "call" trees is even more important (for human portablility).

It's amazing how far a simple comment block can go if it's ACTUALLY kept up to date, and available on every function:

/**
** foo
** returns: int - value is a count of modified foo
** accepts: int foo - value initializes foo
** calls: foo.c:foohelper()
** called from: foo.c:main()
** - foo2.c:whatTheFoo()
** - foo2.c:fooYou()
** - foomodule.c:whereArtFoo()
*/

bitten by the power of 3 rule

[timdaly]

effort to develop software

1 unit = code for yourself
3 units = code given to someone else (library probs, config probs)
9 units = code given to a group (HOWTO, ifdefs, tar-gzip, etc)
27 units = FOSS code (cvs, mailing list, configure, make, docs)
81 units = product code (legal, sales, market, packaging, distribution)
243 units = viable software for 30 years (literate pgms, deep documentation, research, major redesign, etc)

The effort to get real software to be viable is hard, long term, and thankless.
How much code are you writing that will be useful 30 years from now?
What are you doing to make that happen?

Re:So the myth is true? And that's ok.

[IamTheRealMike]

It depends a lot on what the project is, Shorewall clearly isn't one that has commercial backing (in which case the pain of support and documentation is balanced by money).

I work on two open source projects, one I do as a hobby and one I get paid for. For the one I get paid for, a significant chunk of time is spent doing technical support. This can be quite demoralising: there are always people for whom it simply Does Not Work and you aren't entirely sure why (usually because their system is broken or hopelessly exotic). But when you get a support ticket closed as fixed, it's quite a nice feeling. I wouldn't do it unless I was paid to though.

The one I don't get paid to work on, most of my time is spent on "boring" stuff as well like debugging, investigating other peoples goofs and writing documentation. I do that because I'm the maintainer and I like to see the project thrive and grow. It's like gardening. It can't all be planting pretty flowers all the time: somebody has to do the weeds. Well, that somebody is me, and the reward comes in the form of the final result rather than the process of getting there.