You'll find that we are quite willing to incorporate open-source software that has an established community and demand within the Solaris customer base that's paying for support contracts.
For what it's worth, I'd suggest that most customers want to use a scalable IMAP service for mail access. POP doesn't work so well in the modern multi-client world.
You are correct. I did find the campaign "Oracle Developer Champions":
They do claim to encourage open source.
But they prohibit comments there. And conduct the campaign outside of Oracle: on Twitter.
They ask to write to Jennifer. But she never replies.
You confirm their failure, as you reject the very open source that they promote.
established communityof developers will not come about on such basis of failure. You reject it before it can even begin.
established communityof users is already there. And it is huge. Every mail client software does have POP. It is the easiest to set up both in client, and, with my invention, on server too.
A customer will not pay for support, if everything works. Right? So, an absent POP is a way to make customers pay. Is this what you mean?
If we follow such logic, I suggest you strip Solaris of everything, and introduce deliberate faults, cripple it, in order to force customers pay.
In fact that's what you did already: both POP, and IMAP were present in Solaris 10. - However, they had flaws of security. You removed both from Solaris 11. - Even the IMAP, which you now claim is so good.
Solaris is free. This is good. You can't expect it to pay for itself. You get money from elsewhere. We should just improve it. POP is an improvement.
You should understand without saying that by missing POP I also mean IMAP. So, it can't be an argument against POP.
You missed my point: POP is essential because there is nothing in Solaris that would allow to retrieve mail remotely.
Let us provide at least something now. - The minimum.
Then your customer, or an
established communitywould have plenty of time to look for alternatives, if they are not satisfied with this one.
I think an
established communitywill not emerge, as it was lazy to emerge so far, regardless of supposed advantages of IMAP.
There is a better, and more complex alternative to IMAP: file sharing. In fact IMAP is a kind of file sharing itself.
It is not worth the while to invent the same, or inferior complexity time and over again as IMAP.
We already have simple POP. Lets us just install it.
I know it does not answer your question but why not install https://www.dovecot.org/ which install without any problems on Solaris. Yes, it would be great Solaris came with all great open source software, but on the other hand it is good to know that so much software works on Solaris.
Well, Oqelu, I can't comment on what's done in the program you point to, as I don't know the person running it or what criteria they use in determining the qualifications. A quick Google finds me nothing about your proposals to sendmail and so on. Perhaps you should get it up on github and start promoting it. Who knows, maybe I'm wrong and there are thousands of people interested in a simple POP server.
Because "Dovecot" is just one more software out of many. Not easy to find.
Web site of Oracle too does not mention POP. Hard to know what to choose.
Package installer in Solaris does not offer POP. This is the easiest way to get a compiled program.
To compile on ones own is the last resort for any user.
Why choose "Dovecot" at all?
Most POP servers I saw are of poor design.
Most important reason for my POP is that it is not a separate program. It is part of sendmail(). No additional process, memory. Minimal extra configuration; almost none.
I don't know the person running it or what criteria...
You mean the "Champions"? How come Oracle does not know Oracle?
A quick Google
Use Google less. It is evil.
finds me nothing about your proposals to sendmail
There is nothing to find. Keepers of sendmail() simply refused to publish my POP.
thousands of people interested in a simple POP server
Truth is not in quantity. Even 1 user is enough to include it in Solaris. 1 person may be correct, and all others may be wrong. This happened many times in history.
Maybe some frustrated users already use alternative POP, and would be lazy to switch to mine. We would never know about them.
I think there's no need to advertize it wider. My post here is enough. If anyone wants POP, one may find it here, and ask me.
Oracle's mail server offering, including IMAP, POP, and much more, is at https://www.oracle.com/industries/communications/enterprise/products/messaging-server/index.html.
We are not going to ship a fork of sendmail that upstream is not supporting. Solaris used to do that and it caused much pain for administrators and everyone was much happier when we removed the divergence and adopted the upstream sendmail.
That is a big, complex program for serving, viewing, and manipulation of messages. Isn't it? It is paid. It just happens to contain POP. It may not be worth to buy, and install the entire program just to obtain a small part of it - POP.
Maybe you could extract POP from it, and provide it separately, free.
I think you are wrong. Solaris 11 still does contain a fork: VENDOR_NAME Sun. You could make POP part of the fork.
The environments where Solaris is used and where being a mail server is part of that are best served by allowing the customer to choose what suite of mail delivery and access protocols and programs they want. As such there is no business case for Oracle Solaris to provide a POP and/or IMAP server as part of the core OS packages.
It doesn't even make sense for us to have to maintain packages for one of the well known and widely used IMAP serves such as Dovecot. Including 3rd party software (FOSS or not) into Solaris has a significant "paperwork" overhead for us that is required so we can track license and upstream changes for security vulnerabilities etc, even if no changes are needed to build the component on Solaris.
As for the changes to the upstream sendmail for Solaris 11.4 Beta you can see exactly what we have patched here:
Darren J Moffat
Senior Software Architected