It seems we&#39;re falling into one of two sides of the old argument over design philosophies. One side says &quot;do the right thing&quot;, the other believes &quot;worse is better.&quot; One side builds monolithic jewels, the other side builds simple modular tools that while messy are simple to use and understand. <br>
<br>More here:<br><a href="http://www.jwz.org/doc/worse-is-better.html">http://www.jwz.org/doc/worse-is-better.html</a><br><br>There are also parallels here to a comparison of publishing on the internet and traditional publishing in print. Publishing a magazine or newspaper is expensive, very expensive. So nothing is printed until it passes through an army of editors, fact checkers, graphic designers etc. that mold the content into something special. Publishing on the internet is, on the other hand, extraordinarily cheap. Head over to <a href="http://wordpress.com">wordpress.com</a> and 5 minutes later, you have an international publishing platform -- for free. And millions of people have done that which is why the internet is now full of junk and useless or so critics will say.<br>
<br>But it&#39;s still very easy to find very high-quality useful information on the internet. Why? Because there&#39;s tools which help filter out the good content by mining the collective intelligence of human of human interaction on the web. Google works its search magic by discovering which pages have the most &quot;votes&quot; from incoming links. Collaborative news sites such as digg, hacker news, reddit, and others work by voting. The best news bubbles up to the top. Memetrackers analyze new content and discover which topics are being discussed the most and push those conversational clusters to the top of the news page. And so on.<br>
<br>Both systems of publishing content are filters -- the traditional system says -- &quot;publishing is expensive, so we&#39;ll filter content <i>before</i> publishing.&quot; The second system says &quot;we can&#39;t stop people from publishing -- so let&#39;s devise better filters to help the best content still come out on top.&quot;<br>
<br>Many people will argue against the second system complaining about information overload -- &quot;there&#39;s too much stuff on the internet, we need professional editors to help us know what to read.&quot; Clay Shirky talked about this awhile ago and said &quot;there&#39;s no such thing as information overload, just filter failure.&quot; <a href="http://www.cjr.org/overload/interview_with_clay_shirky_par.php?page=all">He expanded on the argument</a>:<br>
<br><div style="margin-left: 40px;">So, the real question is, how do we design filters that let us find our
way through this particular abundance of information? And, you know, my
answer to that question has been: the only group that can catalog
everything is everybody. One of the reasons you see this enormous move
towards social filters, as with Digg, as with <a href="http://del.icio.us">del.icio.us</a>, as with
Google Reader, in a way, is simply that the scale of the problem has
exceeded what professional catalogers can do. But, you know, you never
hear twenty-year-olds talking about information overload because they
understand the filters they’re given. You only hear, you know, forty-
and fifty-year-olds taking about it, sixty-year-olds talking about
because we grew up in the world of card catalogs and <i>TV Guide</i>.
And now, all the filters we’re used to are broken and we’d like to
blame it on the environment instead of admitting that we’re just, you
know, we just don’t understand what’s going on.<br><br></div>Now I hope I&#39;m not distorting Marcel&#39;s argument here (and if I&#39;m wrong I&#39;m sure he&#39;ll correct me :) when I say <span class="lHQn1d"><img class="f g8" src="images/cleardot.gif"></span><span class="ik"></span>he&#39;s arguing that there&#39;s too many modules, too many &quot;bad&quot; developers, writing too much &quot;bad&quot; code and we&#39;d be all better off if the module landscape was less messy and more prestine. Perhaps this is too neat but it seems his argument falls along the same lines as those who say we need professional editors to filter content before publishing. I think his idea is a bad one (for our situation -- it works great for manufacturing, magazines, skyscrapers, etc.) for many of the same reasons as others have argued. But we do need better filters to help us find the best and right modules to use (and I&#39;m sure some duplicate modules are written simply because the author didn&#39;t *know* there was an existing solution). And I think the drupal community is already working very hard to do just that -- provide better filters to point site builders to the current &quot;best-of-breed&quot; modules for a given situation. Much of the <a href="http://drupal.org">drupal.org</a> design was directed at that problem and the (still coming) Drupal distro revolution will also greatly help at standardizing the module selection and focusing developer effort.<br>
<br>Kyle<br><br clear="all">Research Assistant<br>eBusiness Center @ BYU<br><a href="http://kyle.mathews2000.com/blog">kyle.mathews2000.com/blog</a><br>
<br><br><div class="gmail_quote">On Sun, Mar 8, 2009 at 3:47 PM, Marcel Partap <span dir="ltr">&lt;<a href="mailto:mpartap@gmx.net">mpartap@gmx.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Because 99.9999% of all Drupalers are not really aware of that, I<br>
want to take the chance to publicly say THANK YOU to Andy Kirkham<br>
(AjK), who does an awesome job on carefully reviewing a bloat of<br>
CVS applications - mostly alone. We get several new CVS<br>
applications *each day*. Although there are a few other community<br>
members who are eligible to process CVS applications, he is the<br>
one who takes this on with the required responsibility, discipline,<br>
and motivation.<br>
</blockquote></div>
You&#39;re right, haven&#39;t noticed him although he probably also processed<br>
my application.. KUDOS Andy for bearing with the community ;)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That&#39;s an ungrateful job, because many applicants complain about<br>
the slow review process and in parallel, his hard and<br>
time-consuming work is not recognized throughout the community. :(<br>
</blockquote></div>
Yeah being in the jury just never pay off.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thank you, Andy!  You are one of the most important people for<br>
Drupal. Without you, Drupal contrib would certainly be a pain.<br>
</blockquote></div>
Wow i didn&#39;t realize it could be far worse..<br>
Now on to the more profane stuff.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

It might be difficult and require changes, but in the long run it<br>
will be worth it.<br>
</blockquote>
That&#39;s a nice vision you have there.  But it sounds like you only<br>
want to talk about it.<br>
</blockquote></div>
Well admittedly starting the discussion is only a first small part.<br>
For much of the work i can not be of help simply because i have other<br>
obligations, but i volunteered for reimplementing a mailman/drupal<br>
integration module and would contribute as much as possible.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Merging and rewriting most of those duplicated modules from scratch<br>
(e.g. Notifications/Subscriptions, eCommerce/Ubercart, etc)<br>
requires a lot of development time - much more than simply porting<br>
them to yet another Drupal core version.<br>
</blockquote></div>
Well of course it does, but a) the structural sanity benefit might be<br>
worth it and b) the license doesn&#39;t prohibit code reuse ;)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
To have any effect in the end, it also requires that all module<br>
maintainers agree on the &quot;roadmap&quot;, which means that they will let<br>
 their own, duplicated modules die in favor of the new, centralized<br>
 module.<br>
</blockquote></div>
No. It does require the community at large to do the work of<br>
discussing, drafting and finalizing the structural design of these new<br>
frameworks - module maintainers are not required, but of course their<br>
experience would be of tremendous use.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This has been done before.<br>
</blockquote></div>
Fine. So uhm let&#39;s do.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- Wysiwyg API module is the successor of all client-side editor<br>
integration modules, because someone analyzed the anatomy of all<br>
previously existing modules and thought about a better, generic way<br>
to do it with Drupal. Almost none of the other maintainers and<br>
developers ever contributed to this vision, which is the reason for<br>
why the few developers of this project are completely buried with<br>
work, and Drupal users are (even more) confused about which module<br>
to choose/install.  Because of that, we won&#39;t have better Wysiwyg<br>
support in Drupal 7 core.<br>
</blockquote></div>
Shame on those module maintainers! But still, all is not lost. Let us<br>
try making it suceed and mirroring the process, without leaving<br>
current module maintainers out of the equation.<br>
By the way, a policy change like described would put more pressure on<br>
those maintainers - if they want to have at least some of their code<br>
run on D7 - they better be cooperative!<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

True. How does a more swarm-like approach to code committal<br>
hinder that? That&#39;d just channel the flow more tightly.<br>
</blockquote>
People most often forget that maintaining a project is primarily<br>
about responsibility, once it is in the wild.<br>
</blockquote></div>
Ok now that&#39;s a valid point. Maybe it can be possible for people to<br>
take responsibility without having exclusive access rights to a module?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yet another example: If there was some bad, not carefully reviewed<br>
 code committed to Views module, then 72,799 sites could go down.<br>
</blockquote></div>
So as that has not yet happened it seems responsible developers exist<br>
in the drupal community.. hurray! ;)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have seen issues where 10 or more contributors reviewed and gave<br>
 their thumbs up, but luckily there was this responsible maintainer<br>
 who told them that the entire approach is wrong, followed by the<br>
proper way to do it.<br>
</blockquote></div>
That&#39;s the scenario where the veto vote i proposed comes into play ;)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That is the primary job of maintainers (gate-keepers) and the<br>
reason for why it is both excellent and required to have separate,<br>
 specialized knowledge and vision per project.<br>
</blockquote></div>
Well if it work better, that&#39;d be great. However not all individuals<br>
live up to these standards, which is why i think maybe the drupal dev<br>
collective at large can better fulfill this role!<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Your proposal really boils down to the question whether a project<br>
maintainer is open to improvements by the Drupal community and<br>
thereby takes the required, additional steps to ensure that the<br>
community is able to contribute.<br>
</blockquote></div>
My proposal was to shift the responsibility from individual persons to<br>
a community process, to minimize possible negative influence of those.<br>
The process should promote and support taking responsibility by<br>
anyone, and hinder the opposite.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It&#39;s about following a certain paradigm - or not.  No automated<br>
process or AI will be able to change the paradigms of humans who do<br>
not want to follow a certain paradigm.<br>
</blockquote></div>
True, _but_ individuals who do not want to follow the common shared<br>
values may be excluded from using the community to publish their code.<br>
That will teach them ;)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We can measure quality in contrib (and there are plans to do so),<br>
but putting regulations onto contrib hinders innovation,<br>
evolution, contributions, and lastly freedom.<br>
</blockquote></div>
Yes and no. It restricts freedom, true. But why does experimental code<br>
need to be committed to the central repository, and how does enforcing<br>
an open development process hinder evolution?<div><div></div><div class="h5"><br>
<br>
<br>
-- <br>
 &quot;Obstacles are those frightful things you see when you take<br>
  your eyes off your goal.&quot;         -- Henry Ford (1863-1947)<br>
<br>
  Change the world! Vote: <a href="http://hfopi.org/vote-future" target="_blank">http://hfopi.org/vote-future</a><br>
</div></div></blockquote></div><br>