For several years, postmark only allowed transactional email. This led to them having a very high reputation. They are now cashing in on that reputation by allowing increasingly spammy content.
In a couple years, they're deliverability will be no better than SES.
oh, fascinating, but don't you fix that by having separate infrastructure? they don't say that explicitly, but they do advertise that they have separate infrastructure for transactional and marketing.
My impression is that their "streams" are just ways of segmenting different types of content within an account, not actually using separate infrastructure to send the actual mail.
hey. notice: i work for mailtrap.io but I have domain knowledge
It's always better to separate your transactional and bulk (marketing traffic). We do it as well as it's also best practices recommended by Gmail (use different IPs, and even subdomains).
Also another thing is suppression list: as somebody marks you bulk email as Spam, they still can receive their e.g. pass reset emails.
It's probably nothing cheaper than SES, but you probably need more time with it. And if you have any issues with deliverability - you are on your own. Postmark or we provide support, UI, etc for extra costs.
Well, in this specific case there is source code and it's the source to the website, which now accepts contributions rather than just being "read only." The linked article goes into why they are now open to contributions
It seems to me that the whole concept of an off-the-shelf ERP is misguided. These systems have to be heavily customized to fit the needs of the any particular organization. Why not just hire a couple programmers, build what you need from the ground up, using open source components where appropriate? It might take longer than 18 months to finish, but it sounds like that wasn't a realistic estimate for configuring an ERP, either.
In any ERP deployment there will be at least two major cost sinks that have absolutely nothing to do with software: enumerating actual business processes and training employees. Before you can even think of "hiring a couple programmers, build what you need from the ground up" you need a very detailed and thorough spec of what the business actually does and hopefully transform said spec into something better served by electronic processes.
How much resources do you reckon would it entail to arrive at such spec?
The thing is, you can't agile this. ERP is notoriously hard to deploy. You have warehousing in ERP, but purchasing in paper? Accounting will love you.
There's nothing wrong with applying agile on mature orgs per se.
With all due respect, technical software people usually fail miserably at understanding what deploying ERP is. It's by no means software project. The "ERP" could be a huge physical book with all required templates even if very inefficient one, nevertheless deploying such "ERP" would still face *exactly* the same problems.
Deploying ERP is first and foremost business transformation. All ERP deployment horror stories that I have some inside info on always revolve around reluctance of business to transform and instead attempting to contort ERP to fit some undefined shape. Deploying ERP painfully highlights all the spots where business processes are undefined, overlapping or flat out useless. Those processes need to be cleaned up, there's no way around that.
Every information system follows SiSo/GiGo (Garbage in - Garbage out) principle. Humans can apply common sense heuristics and do reasonable things given garbage data. Information systems cannot. That's the beauty and horror of deploying an ERP. If management is actually willing, it's a perfect opportunity to streamline business processes, but if it is managed as some software deployment over existing business - you get horror stories, reduced efficiency and maintenance hell on top.
> If management is actually willing, it's a perfect opportunity to streamline business processes
This, a million times.
Never try to bend an ERP - they are immense business process templates internally connected in incomprehensible ways. Bend the company instead, drop whatever process cannot be implemented trivially in the system and adopt one that is.
Just mapping the parts that need to be transformed is a huge process.
Yes, there are times when processes/procedures are truly unique to a firm but it usually isn’t and the firm can ‘standardize’ their process so that it fits into the ERP flow.
These ERPs are usually shipped to handle common/different scenarios/usecases and clients simply have to configure them accordingly (configuration is totally different from trying to customize)
The real issue seems to be that donations are going to the wrong schools (at least according oo the stated goals of the donors and schools). There is one paragraph that touches on it:
> The donations also appear unlikely to affect where people practice medicine. The schools that have gone tuition-free are all prestigious programs in major cities. None of them ranks even in the top 100 medical schools with the most graduates practicing in underserved areas. “You can’t take somebody that grew up in the suburbs and transfer them into New York City as a medical student and really expect that they’re going to take a job in Iowa,” Dinerstein told me. “Some will, but just not in general.” Although there’s plenty of need in the areas surrounding elite medical schools, making tuition free doesn’t create any new incentives for students to opt for community health centers over distinguished hospitals. “The medical schools that have gone tuition-free, they take strivers,” Dinerstein said. “And strivers, for all the things they had to do to get to medical school, are not going to stop now.”
Yeah that's a pretty good assessment. There are so many ways to deal with this issue, and so many different implementations of this approach that could have worked better. Just makes you wonder what anyone was thinking here.
That seems like it would be terrible for the open source project and anyone that relies on it. I hope both sides of this dispute deescalate things before something like that happens.
Maybe not. A stern letter from the IRS might be just the nudge for the Foundation to clarify things, and maybe push Matt to choose one or the other. Few things will scare a nonprofit more than the IRS knocking on the door.
Really only one paragraph from the article is needed:
>Meanwhile, when it comes to how often you should wash bed covers, most experts recommend doing so on a weekly basis. As well as washing sheets, ironing also reduces the bacterial count of linen.
These are pretty good. I feel like jargon like "use case" and "business logic" should also have sarcastic definitions. But I can't be clever this early in the morning.
In a couple years, they're deliverability will be no better than SES.
reply