target userspace utils (rtsadmin) project is dysfunctional

target userspace utils (rtsadmin) project is dysfunctional

[Andy Grover]

Hi Jerome and Nick,

I happened upon this website:

http://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html

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

Re: target userspace utils (rtsadmin) project is dysfunctional

[Douglas Gilbert]

On 11-09-09 03:07 AM, Andy Grover wrote:
> Hi Jerome and Nick,
>
> I happened upon this website:
>
> http://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html

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.

> 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.

One reason from the above link:
   "Your code is a fork of another project [ +10 points of FAIL ]"
:-)

Doug Gilbert

Re: target userspace utils (rtsadmin) project is dysfunctional

[Nicholas A. Bellinger]

On Fri, 2011-09-09 at 00:07 -0700, Andy Grover wrote:
> Hi Jerome and Nick,
> 

Hi Andy,

> I happened upon this website:
> 
> http://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html
> 
> 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.

> 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

Re: target userspace utils (rtsadmin) project is dysfunctional

[Jerome Martin]

Repost including target-devel and linux-scsi lists.
Sorry for the noise.

On Sat, Sep 10, 2011 at 10:30 PM, Jerome Martin
<jxm@risingtidesystems.com> wrote:
> 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,
> Jerome
> On Fri, Sep 9, 2011 at 10:07 AM, Andy Grover <agrover@redhat.com> wrote:
>>
>> Hi Jerome and Nick,
>>
>> I happened upon this website:
>>
>>
>> http://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html
>>
>> 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
>
>
>
> --
> Jérôme Martin
>



-- 
Jérôme Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: target userspace utils (rtsadmin) project is dysfunctional

[Andy Grover]

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


On 09/10/2011 10:37 PM, Jerome Martin wrote:
> Repost including target-devel and linux-scsi lists.
> Sorry for the noise.
> 
> On Sat, Sep 10, 2011 at 10:30 PM, Jerome Martin
> <jxm@risingtidesystems.com> wrote:
>> 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,
>> Jerome
>> On Fri, Sep 9, 2011 at 10:07 AM, Andy Grover <agrover@redhat.com> wrote:
>>>
>>> Hi Jerome and Nick,
>>>
>>> I happened upon this website:
>>>
>>>
>>> http://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html
>>>
>>> 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
>>
>>
>>
>> --
>> Jérôme Martin
>>
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html