Guys (this is to all of you), you are all doing good work.<br>A little less guilt-tripped bowing down to some god of open source will go a long way here.<br>Don't let anyone guilt-trip you into stuff.<br>I am relatively new to the Drupal community (only a year and a half) but I think the Drupal way is marked by three words: cooperation, selflessness and above all intelligence.
<br>Cooperation: If you see someone carrying a load, help her.<br>Selflessness: Take due credit for stuff, but don't do stuff to get credit.<br>Intelligence: The beauty of Drupal is, speaking broadly, separation of model/view/controller and software reuse.
<br><br>On that last point, what you can see is people coming into Drupal thinking that "module" is a block of functionality appearing somewhere on a page. Here, in Drupal-land, a "module" is a group of files mainly concerned with controller logic and the resources necessary for the implementation of this logic, totally separated from general theming, and relying on a database abstraction layer for its persistence. So people generally try to use the accepted standards in accessing the database, and try to use the theming function conventions so that any theming decisions can be overridden.
<br><br>That keeps things clean.<br><br>And, people try to reuse modules, and that keeps things clean.<br><br>If, in your Sandbox, you want to play around with some functionality, no-one should stop you, just go ahead and have a ball. Of course, before starting, it is simply good, intelligent software practice to attempt to reuse an existing module rather than inventing the wheel.
<br><br>This is not only to keep things clean. This is to keep things strong by reusing proven code rather than slapping non-proven code into our machines.<br><br>Then, when it comes time to say, hey this deserves to be a module, common sense would say look around and see what module integration is possible (two examples here are jstools and swftools, among many); talk to people who are doing similar stuff; if you think it is original and useful, publish your module.
<br><br>Then, let people vote with their feet: if two or three similar modules are out there, people will vote with their feet, which is much more effective than having some incipient bureaucracy deem what is fit. Then, usually when a new release comes out the unwanted and unloved modules usually don't get updated, and nature has its course.
<br><br>Case in point: Salesforce module.<br>1. My client needs salesforce integration urgently for a current project.<br>2. I prefer to see that done in the form of re-use of a module rather than hacking stuff together individually, so that my client can benefit from community code while the community benefits from my client's project. My client understands this and applauds it.
<br>3. I find a perfectly neat salesforce module in a fellow drupaler sandbox; I see his wishlist saying "gosh darn it, wish I could find someone to take this pesky salesforce module off my hands". I pm him, saying "I'm your man".
<br>4. With Steve McKenzie's permission, I take his sandbox module and import it as a bonafide module.<br>5. I am now testing it, have corrected some things and will publish shortly 4.7.x and a 5.x releases.<br>6. I will then extend the module with the additional functionality my client needs (views support for online queries, to name one). Exciting!
<br>7. Then, I get mail and messages saying: hey, what about unifying this with access and integration modules with other CRM's, including CivicCRM, etc. and I answer, cool, let me get this on the road, then let's discuss how that can be done. The more discussion we have on that the better.
<br>8. It's the year 2008. My client decides to switch to CivicCRM or its on-demand (proprietary) version instead of the bad proprietary Salesforce. It is a totally painless operation since all that needs to be done is switch a configuration setting and do some import/export (a feature of the module itself hahaha). So, any Salesforce diehards can stay with the bad proprietary Salesforce, whilst do-gooders can go with the good proprietary CivicCRM on-demand version. Sweet!
<br><br>Drupal does it again!<br><br>saludos,<br><br>Victor Kane<br><a href="http://awebfactory.com.ar">http://awebfactory.com.ar</a><br><br><div><span class="gmail_quote">On 5/13/07, <b class="gmail_sendername">FGM</b> <
<a href="mailto:fgm@osinet.fr">fgm@osinet.fr</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi all in this thread,<br>
<br>Just to clarify some points, which I think may be needed to spare some<br>anguish, seeing how the thread appears unduly long:<br>- When I saw this announcement, I was indeed surprised to see the<br>duplication, and checked the three issues mentioned by John but, alas, I
<br>overlooked part of 54990 and thought he had not taken into account my remark<br>on that issue, that pointed to the module in my sandbox. My fault.<br>- I certainly do not attempt to deny anyone the idea of creating such a
<br>project. Indeed on the page where I announce the themesettings module I had<br>in my sandbox, I explain rather clearly that it is just a "proof-of-concept"<br>module, until something appears in core (which I hoped for
5.0, seeing how<br>garland had its own settings mechanism, although done differently). So,<br>since this<br>- As John said, "we are all writing Open Source software", so I answered to<br>the announcement to point to potential duplication, as Earl Miles initially
<br>remarked, not for a rights issue, as some others seem to have thought.<br>However, John apparently was aware of this existing module, and indeed uses<br>the same mechanism, in a much more developed code, in his function
<br>themesettingsapi_form_alter, so apparently there is no duplication, just a<br>(very significant) functionality and packaging extension.<br>- In the end, I think I was a bit miffed to discover a module by the same<br>name as mine in the dev list, after the fact without any personal mail from
<br>the author especially since we had indeed exchanged some emails five weeks<br>ago. So I think that to avoid similar problems for future occurences like<br>this, John's latest suggestion in this thread makes sense:
<br><br>"Code duplication:<br>Perhaps it needs to be a requirement that module developer's announce their<br>project on this list BEFORE any code becomes public on the d.o website.<br>[...] perhaps just documenting it in the appropriate places in the handbook
<br>would be enough."<br><br>As far as I'm concerned, that's all there is to it, and I'm now pointing<br>users of this sandbox module to his project (I know some exist, because I<br>had received mails about it), because this being a project, it is supposed
<br>to be maintained and evolve, unlike a sandbox, which in this case fulfilled<br>what IMHO seems to be its role: show ideas until they become ready for prime<br>time. I'd actually have done it earlier if the module had been preannounced.
<br><br>Frederic<br><br><br>----- Original Message -----<br>From: "John" <<a href="mailto:drupal.user@albin.net">drupal.user@albin.net</a>><br>To: <<a href="mailto:development@drupal.org">development@drupal.org
</a>><br>Sent: Friday, May 11, 2007 10:16 AM<br>Subject: Re: [development] Custom Theme Settings<br><br><br>> On May 11, 2007, at 12:27 AM, FGM wrote:<br>> > Funny how you created a "themesettings" module that duplicates my own
<br>> > "themesettings" module..<br>> ><br>> > Is it the same mechanism/code ?<br>><br>> Federick, head on over to the Theme Settings project and take a look<br>> at the themesettingsapi.module
code yourself: <a href="http://drupal.org/">http://drupal.org/</a><br>> project/themesettings<br>><br>> Also, look at the project home page under "About the Project" and<br>> you'll see I referenced issue #54990 where you announced your sandbox
<br>> module. It's not the same code, but even if it was... aren't we all<br>> writing Open Source software? :-)<br>><br>> - John<br><br></blockquote></div><br>