On Monday, June 23, 2014 10:34:00 AM UTC-5, Alessandro Franceschi wrote: > > First of all, let me thank you, John, for replying to this post and giving > a sense to the discussion. > At times I wonder if PuppetLabs' guys read the forum and, if they do, why > they don't express an opinion on these matters. > I might be obsessive about modules, but I think that it's here where we > play the most important game on user code reusability. > > On Friday, June 20, 2014 5:04:28 PM UTC+2, jcbollinger wrote: >> >> >> I have never accepted the premise that "reusable" as applied to Puppet >> modules has to mean "usable in any context, to achieve any end related to >> the module's area of application, via any conceivable style," which is >> pretty much how I read your reusability criteria for component modules. >> Certainly a module that satisfies those criteria can serve pretty much any >> purpose within its domain, but what matters to me at any given time is >> whether a module can serve *my* purpose, whatever that happens to be. >> > > Reusability is definitively a relative concept, and I agree it can have > different nuances, still, IMHO, there are a few reusability patterns that > are easy to introduce and add a great value (for example the possibility, > for the module's user to provide custom templates for configuration files > instead of the ones proposed by default by the module. This is easy to > introduce and should definitively be common practice). >
I think it's great that you are thinking about such questions, discussing them, and promoting your conclusions. And I agree that there are reusability patterns that can be applied fairly easily and add substantial value. But I suspect that if we compared lists, mine would differ from yours. > >> >> If some third-party modules are (re)usable for me but not for (say) >> Felix, and vise versa, then that doesn't change the fact that both our jobs >> are made easier by not having to write everything from scratch. If that >> means I need to study a module a bit before I decide whether to use it, >> then fine -- I ought to do that anyway. >> >> Moreover, I think it is harmful to the module ecosystem to promote a >> position that only Cadillac modules are "reusable," because that sets the >> bar very high for potential contributors. I don't think it helps anyone to >> tell people that their contributions are unwelcome (which branding them >> "not reusable" does). Most people who write modules do so for their own >> purposes first and foremost, and if the community is unwelcoming to them >> then they will just keep their work to themselves. >> > > I understand the point, but at the same time I find it harmful also to > have hundreds of modules, that are published on the forge but work only for > a specific case and are practically useless for others. > I disagree. It is not at all a problem -- in itself -- to have hundreds of narrowly-scoped modules on the forge. More modules means more chances to find something that serves my needs, or something I can learn from. The concern is presumably about how easy or hard it is to find 'the' right module for me, but I don't think the solution is to try to ensure that all modules published there meet specific, high API and functionality criteria. Rather, the solution is the same as ever in an open-source community: documentation, reputation (both of the code and of the author), popularity (mostly of the code), and support and recommendations from the community, especially (but not exclusively) from thought leaders. I daresay, for example, that many people choose *your* modules in large part just because they are yours. You and your modules have strong reputations, which are reinforced when users find that your modules work well for them (or undermined in the unlikely event that they find otherwise). Perhaps the Forge platform could be enhanced to make those tools easier to apply in its context, but at least some of them are already reasonably accessible. > It's not a matter of preventing or discouraging users from publishing > their work, but to have a good overall quality of public modules and to > encourage good practices. I'd rather work on trying to convey and promote > basic reusability patterns that can be used and embraced by everybody. > I understand that it's not your intention to discourage authors, and as I said, I think it's great that you are thinking about these things and promoting the practices you find good. But if the point of publishing a module on the forge is for others to be able to (re)use it, then how we characterize whether a module is "reusable" has deep influence on participation and the community dynamic. Reusability is not a boolean condition, it is a qualitative, analog measure. > Also, I don't think that a reusable module is necessarily a good one or > viceversa, actually in most the cases reusability features add complexity > and overheads. > I agree. But if you say that my module is not "reusable" then why should I not take that as a rebuff -- an assertion that my module is not useful to the community and therefore should not be shared? If someone else were to use it in any way, then would that not be "reuse"? If there's a reasonable chance of that happening, then does that not on its face prove that the module is indeed reusable? John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ec939bc5-b5e3-4752-9490-565aa7867c46%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
