At 2:07 AM +0200 2006-08-31, Bretton Vine wrote: > (locally) it's been referred to as a "be strict in what you send, relaxed in > what you receive" approach but not everyone adheres to (or is aware of) this > way of looking at things and it seems antiquated to some.
It's called the Postel Principle, and some of us are old enough to remember when the term was first coined. While there are cases where it is not always appropriate to apply the Postel Principle, there are still plenty of us around that firmly believe that using "safe defaults" is a better way to go. > I *know* the developers develop according to their needs, and needs change > with time and input. And the openness of the GNU approach allows anyone to > modify at will (provided they have the skill), and heck no-one likes > documenting stuff but someone has to do it. The methods of open source development pre-date Richard Stallman and his GNU followers. Some of us remember those days. > But many people will choose a Mailman solution on the basis of cost and > relative availability of help and support. Plus Mailman has largely > dominated what was previously a majordomo or listserv orientated world. I think that Mailman has become the leading open-source mailing list management system for the small to moderate size lists, but we still have some issues with larger lists that preclude us from taking the complete title away from programs such as Listserv. That said, there are multiple choices in this field and I think that's a good thing, because Mailman will not be a perfect fit for everyone, and probably won't even be a good fit for a significant number. There's always room for improvement, and our biggest problem is that we've identified many different areas where we already recognize the room/desire/need for improvement and yet we still have a limited amount of time available to fix those things. > Just because a 'default option' seems sensible and obvious to implement from > a developer perspective doesn't mean you can avoid having to explain it. That may be true, but in this case the answer is pretty simple -- it's safer that way. No further explanation is required, or likely to be provided. > No matter whether you're a core developer, patch developer, documentation > person, or verbal user, people are going to use your product. It's either > going to be good, or outright crap. And even when it's the best solution > available, and all the right decisions have been made in implementation > design, users may choose something else because it's *more shiny*. That's perfectly fine by me. We don't require that everyone use our software. Indeed, I would say that we probably don't want everyone to try to use our software. We're relatively happy with the user community we've got, and we know that there are a lot of ways that we think that this software needs improvement. We don't need (or want) to be all things to everyone. > And sometimes users may become irate at your implementation of a solution on > their behalf and decide they can do it themselves, only to repeat all the > same mistakes you made and end up at the same end result -- feeling like > fools but too embarrassed to return and ask for your help. That's fine, too. If they want to go off by themselves and learn their lessons the hard way, then that at least gets them out of our hair. If they choose to come back and share their experiences with us, I'm happy to listen to what they've learned to see if there is anything we can take from their experience, so that the entire community can benefit. > In a commercial environment this is quite costly to both parties so avoiding > that situation leads to more successful/stable product iterations (not to > mention $$$) We're not a commercial environment, and we've actually had pretty bad experiences with people/companies that are in commercial environments taking our software and making unapproved modifications to it, or providing the software to their customers but *not* providing adequate support to those customers. I just recently wrote a FAQ entry on this subject -- see FAQ 1.32. > Ok, granted, no-one's specifically 'selling' anything here. That doesn't > negate responsibility for the default options though. No, we're not selling anything here, but we are still obligated to create safe defaults for the options within our software. Failure to create safe defaults would be negligent behaviour, and potentially legally actionable. > It's insufficient to > give people an "option" to change something. Some need to know why/how/what. Balance the need to know against the issue of legal actionability. Trust me, the latter will win every time. Especially when the answer is as simple as "because it's safer that way". > I have lots of experience with non-list savoy people, from list-owners to > list-users. Few of them are inclined to actually /look/ for an answer. It's > much easier to ask someone else. And in many cases a sheep-like mentality > occurs where people do things a certain way because "that's just the way > it's done" or "things _may_ go wrong if we do it differently". As one of the principal people in the community who has gone through the FAQ entries and tried to clean them up and correct them as much as possible, I also have plenty of experience with people who are not list-savvy. I know all too well that the default action for most people is to ask others, as opposed to actually going to look for answers in the FAQ or in the archives. A little searching through the archives looking at my typical responses to most posts would clearly demonstrate that. > Think of a lowest-common-denominator list user. What would you recommend as > an OS interface to them? osx or windows or linux or even dos? None of the above. I would recommend a rock. Well, a pebble, since a rock would be large enough that they could throw it at something or hit something with it, and cause a fair amount of damage. At least a pebble would be small enough to be less likely to cause damage if abused. > Now apply the > same basic principle to a web-based list-administrative interface. For the lowest common denominator? None. Even the simplest possible web interface would be too complex for them. > Seriously, what's the worst that can > happen -- someone learning from mistakes, something we do naturally? Entire sites being blown off the 'net, because they're not able to keep up with the e-mail flood? Entire businesses going bankrupt because they weren't able to do their regular work because of the e-mail flood? Remember that you're talking to the guy who was personally blamed for taking down all Internet e-mail across the entire world when AOL went dark for nineteen hours in August of 1997, and I know for a fact that a number of businesses went bankrupt because of that outage and the resulting aftermath, and I personally received more than a few death threats as a result. So, you're asking me what the worst possible case would be? > But at the same time you > have a market that wants a one-size-fits-all solution. Catch-22. Yup. We do the best we can, and that's all we can do. > A mailing lists key function is to act as a list. Not as a spam filter. Sure > it's a useful extra, perhaps even pretty-bells-and-whistles useful. But does > it actually contribute anything to the core function, or add any value that > can not be achieved from within the mail system itself? A mailing list is not useful if it is used as an amplifier for spam, so that more spam goes out than real messages. > If not, why is the default set to "on"? You're asking me whether or not we should have all the software defaults set to their safest mode, when Windows machines default to being insecure and have an average life expectancy of about five minutes if left unsecured on the 'net? Where you can start installing a machine and have the machine already be compromised and subverted to be part of a bot-net before you even complete the installation and download all the OS patches? Excuse me? > Another school of thought evident in many .conf files I've seen is something > like the following: > > # Uncomment the following line to enable $functionality. This setting is > # disabled by default because it is important you understand why it exists > # and actually turn it on purposefully (which is what we suggest you do) > # See http://..... for full explanation > # > # Functionality = 1 I don't see how this is any different from what we're already doing today. Please elaborate. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See <http://www.lopsa.org/>. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp