Well, I am no mail expert and I am not confronted with the distributed
case. As a user, my modest use case is that I want to have control of my
private email, and as I know Java, I like to be able to work with the
server if I like to implement something.
Respect the first point, I need some solution to keep a few gigabytes of
email which I can deploy in a Linux server easily. For me, ideally I
would want a mail James package that I could upgrade to new releases
easily.
And respect the second one, the code base makes the product work, and
gives the chance to adapt for whatever case is needed among many of
them. The code base is huge because of the great amount of choice, and
makes understanding of the parts more complex. Therefore, I am for
simplifying the code base by removing less used options, or having them
separate. And of course, documentation is helpful as a new user to start
with the server. As developer, quickly setup an environment to start
hacking is welcome. In my case, I have no docker experience, and I am
used to run applications the old way.
I think the simple mail server use case is important for single
developers to try and test new features. The distributed use case with
kubernetes makes it a bit harder for me (I do not have experience with
that technology). Requirements for companies are at another level,
indeed. But many marketing features for James would sell both groups
fine, single users and companies.
I do not think current capabilities of the server are well promoted so
better communicating the current features would be good to get more
users to try the server. Maybe a sort of marketing campaign releasing
some smart things people could quickly do with the server would be nice.
That was my 2 cents.
El 06/05/18 a las 08:31, Eric Charles escribió:
Hi James Community,
We have just discussed on the private list actions to further gain
users and developers on the Apache James mail server.
The discussion started as we are slow to convert new contributors to
committers and we have a slow release schedule.
I will summarize key points we have discussed. This is just a base to
start the discussions and we really would love and need to hear your
voice on this.
1. DOCS and TUTORIALS
- We have a new website but no easy tutorials.
- Which platform to use (readthedocs...?)
- Migrate/Close Wiki.
2. NOT ENOUGH HANDS? DROP NOT ENOUGH USED COMPONENTS
- We may have to do some choice: Drop some Mailbox implementations
(JCR, HBase), some data backends (JCR, HBase, JDBC)
3. FULLY DISTRIBUTED
- Today James features (multiple mailbox implementations, configurable
mailets, jmap access...) may not be enough to make the diff.
- It sounds like a fully distributed solution (potentially running on
Kubernetes) could be a better differentiator. There is still work to
achieve this (especially on the queuing level).
4. GSOC
- GSOC is an great way for new contributors,
- Any other options to attract newbies?
5. COMMUNICATION
- We don't use enough the available communication channels: Twitter,
Apache Blog...
- We also don't communicate between us about the plans, pipeline...
This is an action to fix this. Do we need to put a kanboard in place?
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org