Thanks to the three quality responses to my request for a status update. All respondents clearly know about which they speak, which is certainly more than I can say for myself.
From the excellent quality and quantity of the recent messages going through this mailman-users group, it's easy to be excited about the wonderful, thriving development & implementation community. Wow! [Technical term]
As a casual, very interested observer, it's nice to see this up-tick (IMO) in activity, suggesting great advances are imminent:-) in this software, originally started over a decade ago.
In this environment of ever increasing rate of change with a corresponding increase in complexities, number of dependencies, etc, I continue be impressed how Barry et al can stay the course, moving slowly and steadily (hopefully) towards the objective of 'having everything in the box' that 'just works'. That may be a somewhat unrealistic goal for such a multi-faced program, configurable for the myriad of user requirements.
My own goal is to implement and train others (once I learn how to do it myself) to use Mailman3 for various cottage and/or condo/HOA associations, each with their own lists of members, an executive board, (sub)committees, special interest groups, and so on with many common communication/data processing requirements.
Your point regarding security of messaging is appreciated but until the average email incorporates something like PGP, then messages themselves will be insecure. Since I am not contemplating a banking system, I am not unduly concerned direct about fiscal consequences such as revealing credit card numbers and/or social insurance numbers..
Regarding financial contributions, until I have a regular revenue
stream, anticipated to be priced out at approximately $25 per month per
organization, given that we will be operating as a not-for-profit
entity, I only spend/invest my own money only to specifically move
towards that goal. I was referring to money in exchange for specific,
targeted, measurable goals designed to get us going but can see how that
would not be feasible with the vast scope of this immense project.
Once up and running with a critical mass of users, we anticipate spending/returning about one third of revenue to various OSS software projects, of which Mailman3 is expected to figure prominently.
Personally, when it comes to contributing, I like to have my funds tied or directed to specific, measurable, delivered goals such as frequently seen with crowdfunding applications, rather than simply contributing to an open pool of cash, not earmarked for something specific. Just me, perhaps, but tying the dollars to results makes me feel good, even if it's awkward for those who simply want to delve into the code to fix an irritating bug or work on the next inter-application interface, etc.
As an example of identifying specific, identifiable goals to motivate donations, I helped start a charity poker run fund raiser for our local hospital, with all funds allocated to purchase specific items, including a digital mammography unit and now stretcher beds for the emergency room, with our four year total contribution approaching CDN$50,000. And all this money from a rural community numbering under 4,000 people.
I gather that with the high quality of the talent pool contributing to this user group that volunteer programmer time is more important than money, recognizing that having more money is never a bad thing.
I started this message, and plan to end it as well, with many thanks to the various respondents and expressed how impressed I am with the quality and knowledge apparent from both those asking and answering questions. The progress leads me to believe that in the foreseeable future, that this suite of programs will workable for me, with a little/lot of help from my friends:-).
Keep up the great work.
Your cheerleader,
Dave Wilson
On 17-07-23 09:53 PM, Stephen J. Turnbull wrote:
Adding a slightly different perspective to Abhilash's and Barry's.
ddw David Wilson writes:
From my perspective of being an senior (ie overaged) person desirous of implementing fully-featured, capable, scalable, reliable, secure
I'm not sure if "secure" is a real requirement, a nice-to-have, or intended as a compliment to Mailman, but "secure" is not something we can claim. Mail is inherently a security problem, because there is no universal way to authenticate senders. It's possible under certain conditions to configure a system to be secure in the sense of allowing only authentic senders, but even when possible it is not easy. Ask John Podesta (for a well-known example) or Matt Tait (aka Twitter's @pwnallthethings, a security expert who has publically admitted that he's come "this close" to clicking on spear-phishing attachments).
Mailman itself is a complex application with a very large attack surface. If containerized, it will be rather difficult to exploit the rest of the system, but Mailman itself contains a lot of private data (email addresses and associated display names, which are frequently real names), and in enterprise situations may have access to enterprise databases "containing the whole store".
applications such as Mailman, I am convinced that I am thoroughly over my head.
That's what we're here for! Of course we're volunteers, so our availability is less than 99% reliable and time is limited. I don't know of any consulting services providing Mailman 3 consulting yet, but given the activity of this list I believe we'll see them soon. If you have funding to offer and want to kickstart the process, you could go to the vendors page on our website and talk to some of them.
From my limited perspective, it would seem to me that a 'nice to have' system would incorporate the following.
- An open container standard configurable system install, compatible with different web & mail servers, DB utilities, etc;
We have a container system which is configurable. However, IMHO "standard" and "configurable/compatible" are incompatible goals. What we can reasonably provide is a full system-in-a-box for people who only want to configure Mailman itself (ie, add lists and users, and configure their settings in the web interfaces). For people with specific desiderata such as a particular mail transport agent or web server different from those provided by our "Mailman-3-in-a-box", they're going to need somewhat advanced sysadmin skills for the forseeable future because the configuration requirements of web services and mail services must be coordinated, and have subtle, implementation-dependent interactions.
We hope that the vendors referred to above (including mail hosts, mail consultants, and system management framework vendors like cPanel) will soon start providing more "Mailman 3 in a box" services (both software distributions and as VMs in cloud services), as well as consulting services for those with specific needs not served by existing containerized versions.
- Python 3 version Django utilities for archiving and mail list name management;
In progress.
- A design/plan from an inside expert perspective stating costs, time and resources to implement the plan, incorporating crowdfunding to pay for project.
We don't have spare cycles at the moment. None of us actively consult for money on Mailman, which means neither direct engineering capability nor management capability are available. I'm considering this, but since I'm currently a life-long academic with a full-time job for the next few years, I'm not in a big hurry, and would need to acquire skills/partners for the aspects I've no experience in. :-) (I guess that's :-( from your perspective.) With a two-year timeline, if I decide to do it, likely I'd actually open for business in about 1.5-2 years (based on seasonal cycles in free time). I don't know offhand of anyone else even thinking about it.
This could change at any time with entry of new developers, of course, but it's only fair to warn you that this is the current status.
- As a backup incentive to the crowdfunding plan might be the offer of an expert to set up a system for each significant amount donated, say US$1,000, such as might be accomplished by an SSL session on the target computer/server after the user has specified all necessary detail as required in a template.
We do have ways to donate via our relationship with the FSF, but the same issues described above (no reliable gobs of available time for project oversight or actual development) apply.
I am sure that the program author and other major contributors could greatly enhance this list.
In summary, I guess what I am requesting is an overview forecast by half year period and out for the next two years?
For 6 and 12 months out, Abhilash's summary list, and Barry's, all are goals I support. We should also have a plug-in implementating the ARC protocol which improves authentication capabilities by allowing a list's subscribers (more precisely, their mail hosts) to extend transitive trust to senders that the list has authenticated. Although providing such authentication services *in Mailman* is suboptimal and sometimes impossible, we can provide containerized Mailman with that service.
Steve