The unending story of cdrtools
The unending story of cdrtools
Posted Aug 20, 2009 8:41 UTC (Thu) by ledow (guest, #11753)In reply to: The unending story of cdrtools by schily
Parent article: The unending story of cdrtools
I was going to quote the relevant bits that you've posted on this thread and show you what I mean about the "only ever talking negatively about criticism levelled at you" but it actually made this comment too big. My point is: Not once have I seen you say... "I understand people's concerns, but..." or "I think X may have a valid point" or "Okay, let's try to meet in the middle" or something similar. It always seems to be *their* fault for not understanding you. With one or two people involved, I could see that, but I've only ever read negative comments from yourself.
From my point of view as a user... I want someone writing the software that actually understands people's opinions/concerns and tries to work with them. Otherwise it is, effectively, unmaintained. You can add all the fancy features you want, but if I think that tomorrow the downloads might disappear because you have *another* dispute with someone, I can't rely on that software - or that you might switch off feature X, or provide horribly unnecessary large warnings in the utitity's output, etc.
You are producing a piece of software and giving it away for free. The reason you do this, I assume, is to benefit your users (or else, why would you do it?). For that, we are grateful, but the benefit seems to stop heavily at that point - you make something useful and then stop it being distributed, create legal concerns where there are none (your understanding of *international* copyright law appears flawed) and stop additions that actually make it better for the user. Individual patches, sure, you can reject, but the ideas *behind* the patch are often greatly needed (the whole /dev/devicename debacle from years back, for example... did we ever resolve that one because it's at that point that I lost interest in cdrtools).
Personally, the whole "personality" of cdrtools makes me avoid it now and I don't want to have to do that. I rarely have to interact with the software on the command-line anyway but out of principle, I remove it from the distribution of my choice and use alternatives. Not because it eases my use of the computer (the exact opposite) but because I disagree with propogating the personality that appears indefinitely attached to cdrtools.
You have a great tool. You can obviously code really well. But the fact that you can't see *anyone* else's point of view, including distributions, users, lawyers, etc. mean that you've shut the code off into its own little political area of unmaintained code (you still patch for it, but nobody cares because people don't want to use your licensing / patches, etc.). I'm just a user, looking for a great Open Source utility to bung some data on a CD occasionally, not some marvellously complicated commercial project. I want a nice command-line interface to do so, I don't want to have to think or deal with legal issues (that's why I prefer GPL licensing - it takes care of that side for me), I don't want my distribution to have to patch and fight with the maintainer, and I want a maintainer that will fix bugs and add features that I (and many others) need.
I don't remove *any* other software from my setup... only cdrtools. That speaks volumes to me. Maybe it should start speaking volumes to you. When an OS project forks, it means that the people who use the fork have different needs... needs that aren't being met by the original software. I hope that in continuing to write Open Source software you recognise the #1 driver behind the entire movement - let the user do want they need to do.
Posted Aug 20, 2009 16:22 UTC (Thu)
by foom (subscriber, #14868)
[Link]
I really don't care about the rest of this mess (although it makes amusing reading sometimes), but
it was really irritating that cdrtools' cdrecord bitched at me (or worse, didn't work) if I used the
device's normal name (e.g. /dev/cdrom), and instead wanted me to use a cdrecord-specific name
("0,0,0" or something).
I'm just glad that misfeature was fixed in the fork, and I hope that if people ever switch back to
cdrtools from cdrkit, they make sure that that irritation gets patched out again if it's still present.
Posted Aug 20, 2009 23:06 UTC (Thu)
by wolfrider (guest, #3105)
[Link] (1 responses)
--I've only corresponded with him once over email, but he got back to me pretty promptly and answered my question. I gotta respect the guy for what he's done for the community by providing cdrecord, and hope this all gets resolved for him some day.
--Thanks for cdrecord, star, etc Joerg :-)
Posted Aug 30, 2009 21:26 UTC (Sun)
by schily (guest, #60311)
[Link]
There is still not a single OSS CD writing software for Linux
If you like to fork OSS software, you need to have the right
I do not let my projects become orphaned. I give continuous support
The interesting question is: "Why do major Linux distributors
It would be interesting to see a related cover story on lwn soon..
Posted Aug 25, 2009 11:11 UTC (Tue)
by asdlfiui788b (guest, #58839)
[Link]
And given your mentioning of open-source software you probably want it free. And be able to give orders what to do and not to do to the creator?
Well if that does not sound like your average commercially maintained software. Maybe you should try their offers and be relieved of the stress opensource software imposes on you.
Let us take Microsoft:
Or you could take a different cd-burning utility out of the multitude of offers. Hm. Wait, all the others are less good? What a pity!
And what makes you so sure Mr. Schilling does not have access to qualified lawyers to counsel him on this matter? Maybe he could be right with his opinion on the GPL after all?
Cheers...
> /dev/devicename debacle from years back
The unending story of cdrtools
The unending story of cdrtools
The unending story of cdrtools
that is not based on cdrtools. Some programs may claim that they
are not based on cdrtools but they are based on cdrtools - just
carefully check the sources to prove my statement.
skills for this software, you need to be addicted to spend
a lot of time for working on the software and you need to
carefully listen to problems of the users of the software. None
of this is true for the fork "cdrkit". There may be a few "loud"
people in the net that try to make you believe that there are no
problems in "cdrkit". If you carefully listen to the net and look
for real users, you will see that a lot of people are really
disappointed about the current situation.
for "star" since 1982 and I give continuous support for "cdrtools"
since January 1996.
ignore the demands from their userbase?"
The unending story of cdrtools
"I don't want my distribution to have to patch and fight with the maintainer, and I want a maintainer that will fix bugs and add features that I (and many others) need."
- [x] Fixes bugs.
- [x] Adds features that you and others need. Well, based on their market study, they do. And if you pay them enough they will probably implement your stuff.
- [x] Most likely will not complain, only take more money.