At 7:16 AM -0500 2005-11-17, Kevin McCann wrote:
> For what it's worth, the kind of tool that I'm hoping to see--from a
> functional point of view--has already been created. At Bellanet (my
> former org.) we created something called Dgroups (see www.dgroups.org)
> several years ago. The problem is that it relies on commercial software
> (Lyris, ColdFusion, MS SQL).
And the folks at Kabissa.org have put together a somewhat
comparable system based on open-source components (including an old
version of Mailman), primarily for the people on the African
continent. I'm sure it's much more kludgey than your stuff, and I
know it's a hell of a lot more brittle than anyone would like, and I
know it doesn't do anywhere near as much stuff as people would like.
However, there's a great deal of integration work that has been
done there and part of the reason I agreed to volunteer my time with
the group and help run the mailing list side of their site was to try
to learn as much as I could about what they had done and how they did
it, and then bring that back to the Mailman project.
If you look at the Mailman FAQ Wizard entries related to this
subject (and the threads that they link to), most of the useful
information regarding integration with CMSes, web board discussion
systems, etc... has come from Tobias Eigen at Kabissa and various
things that he's said on the mailman-users mailing list.
If you had information that was useful in these areas and you
were willing to share it with us, I guarantee that this would go into
the FAQ and would benefit the larger community.
> We wanted other international development
> organizations, especially in developing countries, to be able to have a
> dgroups for themselves. Essentially decentralize the service and build
> capacity in the south. But commercial software was not practical, and we
> really had moved toward open source policies by this point, anyway.
The folks at Kabissa have taught me that commercial stuff can be
practical, if it is the best way to achieve the desired goals. They
have commercial hosting. They have commercial support for their
platform. They have some commercial software that they have used as
part of their system.
It's not forbidden to spend money. They try to avoid commercial
stuff and use open source where possible, but sometimes the only
viable solution is commercial -- and that's okay. What's important
is to minimize the overall total cost of development and support of
the system, and sometimes to keep TCO down it's better to spend a bit
more money up-front.
Of course, Kabissa is just one organization that is trying to
help under-privileged groups in more impoverished nations, and there
are presumably other groups that don't have as much money to spend as
Kabissa has had.
But I would hope that these other groups would take the same
approach -- don't just look for open source solutions to the
exclusion of everything else, but instead try to keep a lid on TCO as
a whole, and make use of what services are available from what
sources when and where possible.
> So, yes, I'm disappointed in the lost opportunity but for exactly two
> reasons: 1) it means missed resources for MM3, 2) it means that
> international development groups will wait longer for the tool we had
> hoped to provide them with. In international development, time is an
> issue because quicker solutions means less suffering.
From the sound of it, you've already got a tool that does the
job. Okay, it's based on commercial software, but one thing that
using commercial software does usually buy you is speed and improved
time-to-delivery.
So now you're going back and trying to re-work things so as to do
everything with open source, and you're frustrated that it's not as
easy to do with open source as it was with commercial software.
That's easy to understand -- a lot of stuff can be frustrating with
open source if you're trying to compare it to commercial software.
> But I want
> you to know is that my interest is solely in the greater good and
> nothing else.
Fair enough.
> So, go ahead, kick me in the head again if it'll make you
> feel better, but you should know that you completely misunderstand my
> motivations and my agenda.
You meant well, although you chose a method of expressing
yourself that I found objectionable. I think we can get past this.
I still feel that there's going to be a great deal more work that
needs to be done to integrate any version of Mailman into a larger
community collaboration system, and tighter database integration with
future versions of Mailman is going to be just one small part of this
overall picture.
The database integration is a necessary, but not sufficient, condition.
That integration is coming, albeit slower than anyone would like,
and with less regularity than anyone would like. But it is coming.
You can choose whether or not you believe in that, and you can choose
your level of involvement in helping to make that happen. You can
also ask for perspective or guidance with regards to the best way
that you can help make that happen.
But none of this changes the fact that the improved database
integration is going to be just the first step in a long road towards
that combined community collaboration system.
--
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
SAGE member since 1995. See <http://www.sage.org/> for more info.
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
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-developers/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
