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@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
