target userspace utils (rtsadmin) project is dysfunctional
Hi Jerome and Nick,
I happened upon this website:
According to my calculations (available upon request), rtsadmin comes in at 220 points: "so much fail, your code should have its own reality TV show".
I could also add some more like "primary developer never responds to email", "CLA discourages external contributions", and "uses executable name as corporate marketing tool".
Admittedly rtsadmin is a nice piece of code, thanks btw, but your company is falling short of accepted standards for stewardship of a FLOSS project. Please tell me why we all wouldn't be better off if I forked rtsadmin tomorrow.
Regards -- Andy
Quoted 5 lines · Andy Grover
Hi Jerome and Nick,
I happened upon this website:
I totted up 70 each for my open source packages so I reckon that list should be taken with a large grain of salt.
This one amused me:
"Your code tries to install into /opt or /usr/local [ +10 points of FAIL ]"
Installing into /usr/local is the default for autotools.
Quoted 4 lines
According to my calculations (available upon request), rtsadmin comes in at 220 points: "so much fail, your code should have its own reality TV show".
Quoted 8 lines
I could also add some more like "primary developer never responds to email", "CLA discourages external contributions", and "uses executable name as corporate marketing tool".
Admittedly rtsadmin is a nice piece of code, thanks btw, but your company is falling short of accepted standards for stewardship of a FLOSS project. Please tell me why we all wouldn't be better off if I forked rtsadmin tomorrow.
One reason from the above link:
"Your code is a fork of another project [ +10 points of FAIL ]"
:-)
Doug Gilbert
Quoted 2 lines · Andy Grover
Hi Jerome and Nick,
Hi Andy,
Quoted 4 lines
I happened upon this website:
Quoted 8 lines
According to my calculations (available upon request), rtsadmin comes in at 220 points: "so much fail, your code should have its own reality TV show".
I could also add some more like "primary developer never responds to email", "CLA discourages external contributions", and "uses executable name as corporate marketing tool".
I don't think it's fair to say that the primary developer never responds to email. We have had summer vacations and being a small company our email + work load is very high. If you don't get a response please keep pinging us.
Quoted 5 lines
Admittedly rtsadmin is a nice piece of code, thanks btw, but your company is falling short of accepted standards for stewardship of a FLOSS project. Please tell me why we all wouldn't be better off if I forked rtsadmin tomorrow.
We are always open to constructive criticism, so I would hope that you would share your perspective with specifics for us to consider wrt to improvements to make your job of integrating easier before wanting to fork rtslib/configshell/rtsadmin.
Can you share with us your primary points of frustration that are making you consider this..?
--nab
Repost including target-devel and linux-scsi lists. Sorry for the noise.
Quoted 66 lines · Jerome Martin
Hi Andy,
I am not so much interested in your "calculation" than on having a list of checkpoints that you feel would be important to improve in order to have a better OSS project. In all good faith, I can assure you this is all I (we) are looking for, within the limits of time & resources available. As for the emails I did not (never, really ?) answer, apart from the vacation pointed out by Nic, I guess I must have erased part of my mailbox inadvertently then, because I do not have them in my todo box, in which I normally have everything not handled yet.Anyway, thanks for saying rtsadmin is a nice piece of code, I hope we can improve it with as much enlightened (read from people using it ;-) ) input as possible.
And again, I really am eager to take your suggestions about how to improve the docs and processes, these are vast topics and the best places to start might not be always intuitive when you are deep into the code itself. I engaged huge efforts in making rtsadmin self-documenting as possible, with a lot of documentation in the code itself, but clearly this is not enough. I assume there might be some easy to do pieces of doc that could improve dramatically the user experience, but am unsure what they are (install ? packaging ? building from source ? quickstart ? so many things to do...). As for what's planned, the next items on my community todo are to adapt the build process to export a versioned tarball so distros and everyone else can get a fixed version release without having to go through the git-dependent build process, fix the tags exports to the community repository (some script is blocking somewhere in the chain of autocommits) and write a quick "how to build packages" howto. Do those sound reasonable to you or would you put something higher on the priority list ?
One last thing I need to say is that the company as a whole as a very favorable view of anything that can improve the community experience, so every misimplementation of that policy is to blame on me. Unfortunately I might have a hard time managing priorities and workload, and this apparently led to regrettable effects on the OSS project.
Thanks for both the kind and critical words, but now you've said too much to withhold the constructive mentoring any longer ;-)
Kind Regards,
JeromeQuoted 16 lines · Andy Grover
Hi Jerome and Nick,
I happened upon this website:
According to my calculations (available upon request), rtsadmin comes in at 220 points: "so much fail, your code should have its own reality TV show".
I could also add some more like "primary developer never responds to email", "CLA discourages external contributions", and "uses executable name as corporate marketing tool".
Quoted 6 lines
Admittedly rtsadmin is a nice piece of code, thanks btw, but your company is falling short of accepted standards for stewardship of a FLOSS project. Please tell me why we all wouldn't be better off if I forked rtsadmin tomorrow.
Regards -- Andy
--
Jérôme Martin
Signature · 5 lines
Jérôme Martin -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Jerome,
You have released the code and publish repos using a GPL-compatible license. These are the good things, but you're doing almost everything else wrong.
* Lacking FOSS infrastructure. No dedicated list, no releases, no bugtracking, no roadmap or communication on future plans.
* CLA is a barrier to external contributors. I can't fix things that are important to me but you've rated a low priority. e.g. removing lio-utils dep for saving state. Even if I was willing to sign the CLA, you've positioned rtsadmin "community edition" as the little brother to your proprietary product. I'm betting features I would want to add (remote API?) would conflict with features you've slated for your EnterPrise Edition, and likely would be rejected. FOSS development is supposed to be mutually beneficial, but requiring a CLA and restricting external contributors' rights by using a restrictive AGPLv3 license means things are tilted too far in your favor.
* You named the utility after your company, not the project name. This obviously isn't a huge deal (I can patch it to have a better name) but it seems to say you'd rather take all the credit for the utility, and will make decisions for marketing reasons that are not in the best interest of your users.
I can fix all these things for myself and the rest of the FOSS community by forking the project. Here's what needs to happen:
* Set up proper infrastructure. This is a simple as rehosting on github or sf.net. Set up a mailing list. Release something. TALK about your plans. You need to do these things before you can expect to get serious external contributor attention.
* Change your patch acceptance policies. The CLA must go. Proprietary value-add is ok but it should be a separate component. (If you can't do this, it means you're slicing things too thin.) A BSD license instead of AGPL may be more suitable. You cannot limit the FOSS project based upon it duplicating features from your proprietary one - yesterday's special sauce is today's commodity feature.
* Rename it. lio-utils was a decent name -- a user thinks "hey that must be utils for using LIO, I should install it!" but rtsadmin == "where is this rts thing I am admining?" Fail. I'd suggest tcmadmin or targetadmin. Feel free to use rtsadmin for your EE version.
Finally, let me say I have had positive experiences working with both you (Jerome) and Nick. I've worked at places where sometimes the company's interests (at least as it perceived them) did not align with the FOSS way. Your code is valuable enough to fork rather than start over, but not so valuable that the current state (of licensing, especially) is acceptable.
Regards -- Andy
Quoted 74 lines · Jerome Martin
Repost including target-devel and linux-scsi lists. Sorry for the noise.
Quoted 66 lines · Jerome Martin
Hi Andy,
I am not so much interested in your "calculation" than on having a list of checkpoints that you feel would be important to improve in order to have a better OSS project. In all good faith, I can assure you this is all I (we) are looking for, within the limits of time & resources available. As for the emails I did not (never, really ?) answer, apart from the vacation pointed out by Nic, I guess I must have erased part of my mailbox inadvertently then, because I do not have them in my todo box, in which I normally have everything not handled yet.Anyway, thanks for saying rtsadmin is a nice piece of code, I hope we can improve it with as much enlightened (read from people using it ;-) ) input as possible.
And again, I really am eager to take your suggestions about how to improve the docs and processes, these are vast topics and the best places to start might not be always intuitive when you are deep into the code itself. I engaged huge efforts in making rtsadmin self-documenting as possible, with a lot of documentation in the code itself, but clearly this is not enough. I assume there might be some easy to do pieces of doc that could improve dramatically the user experience, but am unsure what they are (install ? packaging ? building from source ? quickstart ? so many things to do...). As for what's planned, the next items on my community todo are to adapt the build process to export a versioned tarball so distros and everyone else can get a fixed version release without having to go through the git-dependent build process, fix the tags exports to the community repository (some script is blocking somewhere in the chain of autocommits) and write a quick "how to build packages" howto. Do those sound reasonable to you or would you put something higher on the priority list ?
One last thing I need to say is that the company as a whole as a very favorable view of anything that can improve the community experience, so every misimplementation of that policy is to blame on me. Unfortunately I might have a hard time managing priorities and workload, and this apparently led to regrettable effects on the OSS project.
Thanks for both the kind and critical words, but now you've said too much to withhold the constructive mentoring any longer ;-)
Kind Regards,
JeromeQuoted 16 lines · Andy Grover
Hi Jerome and Nick,
I happened upon this website:
According to my calculations (available upon request), rtsadmin comes in at 220 points: "so much fail, your code should have its own reality TV show".
I could also add some more like "primary developer never responds to email", "CLA discourages external contributions", and "uses executable name as corporate marketing tool".
Quoted 6 lines
Admittedly rtsadmin is a nice piece of code, thanks btw, but your company is falling short of accepted standards for stewardship of a FLOSS project. Please tell me why we all wouldn't be better off if I forked rtsadmin tomorrow.
Regards -- Andy
--
Jérôme Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html