Hi Benoit,

Please understand how feeling is when the docs get disappeared and require
to look at source while studying on configuration. It made me think that
open source James was not the sense of freedom anymore.

I do understand your team's efforts to build open source James and how does
it feel about my declaration. I highly appreciate such efforts.

And finally, I hope this is just a confusion, bug.

Best regards,
Huy

Vào 13:26, T.2, 6 Th3, 2023 Benoit TELLIER <btell...@apache.org> đã viết:

> Hello Huy,
>
> On 06/03/2023 00:50, Huy Van wrote:
> > Hi everyone at open source Apache James,
> >
> > This is to notify that James is similar to a closed source project.
> > Necessary documents at
> > https://james.staged.apache.org/james-distributed-app/3.7.3/operate/ are
> > currently not found (404). Documents on James website are outdated with
> the
> > latest build.
>
> We are using a multi-repository build with Antora and it seems there is
> a mis-functionning that causes this build to sometime not include
> distributed resources.
>
> I was aware of this bug for some time now but did not have the time to
> investigate it. I created
> https://issues.apache.org/jira/browse/JAMES-3894 for it and might plan
> it in my team backlog.
>
> Contributions on this topic are of course welcome too.
>
> In the meantime the doc is still on github:
>
> https://github.com/apache/james-project/tree/master/server/apps/distributed-app/docs/modules/ROOT/pages/operate
>
> >
> > Configuring James now for new users requires to look into source code,
> > logic, which is a crazy idea.
>
> James is a technical piece of architecture that mostly addresses
> enterprise needs.
>
> There was the topic of having a simpler set up for individual/small
> business which eases its configuration, but we really received few
> contributions on the topic. Hence no real progress was made.
>
> Please note that documentation is a collective effort and, might you
> want to help us improve it, we would very happily accept those
> contributions.
> >   Yes, it's always easier with technical
> > services behind James, but how to be sure that there are no "unexpected"
> > errors occur during operation in the future, when valuable data going
> huge.
> > I concern this because james's been contributed & maintain mostly by
> > companies providing technical services on James.
> Free software is free as in free speech, not as in free beer.
>
> Having companies doing business is by the way a sign of good health of
> an OpenSource community.
>
> James community itself have several actors proposing services.
>
> > If any companies are not at Google, Microsoft, etc level, it's better to
> > build own distributed business-logical mail system based on postfix,
> > dovecot, familiar db shard & replication, etc. It's peace of mind and
> > faster building than current document-hidden Apache James.
> I feel offended by such a declaration and of course it depends on your
> use cases.
>
> James has a real value for injecting components at the heart of the mail
> server, for scaling, for the JMAP protocol.
>
> I agree it might not fit everyone use case.
> >
> > It's not too difficult unless you want. Hope James project is great in
> the
> > future.
> Thanks ;-)
>
> Best regards,
>
> Benoit
> >
> > Regards,
> > Huy Van
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
> For additional commands, e-mail: server-user-h...@james.apache.org
>
>

Reply via email to