Hi Matthieu, My apologies for be absence. I expect to continue to be absent for the next couple of weeks, but I wanted to respond to your email.
> I'm not sure which message to answer in the thread so I start a new > thread to summarize my thoughts on the various topics discussed. No problem. However, you touch on so many points that I am not sure of the best way to organize this type of complex discussion. In absence of any good ideas, I will just respond to everything in this one thread. I will start with one important point, then move on to the conclusion before responding to the rest. > James already works for a lot of use cases, there's nothing really > lacking in term of code, we should stop thinking the software should > be better before being happy with it. A lot of successful softwares > are less mature than James. Yes, I agree. My problem was that I was never able to actually use it. So, my natural reaction was to try to figure out why, but I was lacking the documentation to do that. That got me digging into the documentation much more deeply than I expected to do, and took me further and further away from just trying to use it. đ > My conclusion is that this project is a very valuable one, written by > some very talented developers for something like 20 years or so. Absolutely!! > This legacy is putting us in a very difficult situation: the codebase > is huge, the test suite takes ages to execute, a lot of things are here > for historical reasons but as we are careful about not breaking too > much people deployments we don't remove enough things. Yes, it is a difficult situation, but I think we can overcome this. The first step is recognizing the problems, which I think you have quite well. > In short: we are not able to move fast, to simplify the codebase, to > implement new things easily and finally it's hard to have fun for > newcomers or even James veterans. I agree. I was initially excited about using James, but I realized along the way that it would be a long-term commitment. I was not able to accomplish what I wanted because I was not able to use it, and I was also unable to understand it enough to make changes to be able to use it. So I was not able to complete my project with any success. I have changed tactic to try to accomplish this over the long term instead. I hope to continue to invest maybe an hour or so each day, but that is easier said than done. > What I would really like is to break things! Let's remove all > these anachronic modules, or even better: let's build James 4 by > adopting only well selected modules, ones that are here for a purpose. Yes, great idea. > People could either jump to this fresh version of James or keep > maintaining the 3.x branch. If they lack some modules that were not > selected for James 4, they could just port these modules to the new > APIs. Speaking for myself, my preference would be to jump into this version I think. > By doing such a move, we could focus to finally solve our longstanding > problems like: developer experience, newcomers welcoming, having a > decent and up-to-date documentation, very easy first deployment, etc. Ok, nice. > What would you think of such a move ? 100% agree. > 1. About Roadmap > > Having a roadmap is a very good way to deceive users. It's ok for a > company because you can somehow foresee what you'll be able to > achieve in the future if you care about but when it comes to people > and their spare time, well, life is unprecdictable. > > The less we say about the future, the better. People interested into > the future can always get in touch with the community and ask. I understand your argument that we donât want to make false promises. Hopefully it is clear by now that I totally agree with that idea, and that is why I have been pushing (hopefully not too hard) to be more âhonestâ about the state of James. I think it is still possible to provide a âroadmapâ while not making false promises, though. I donât think it is an either/or. It is a âfactâ that âat this time, this is our intentâ. It does not mean that we are making any âpromisesâ. So long as we make this clear, stating the current thinking of the community as a fact is not at all deceiving. In fact, it is helpful (1) for the community to have an agreement, and in writing, and (2) useful for new members to better understand the current thinking. The roadmap can always be changed. > 2. About documentation > > You definitely deserve much praises for what you did already. We > know that it's the missing piece for James to shine. Ahahaha. Thanks, but I feel badly about not completing it yet. I have not given up, just changed gears. > I would just like to list what I think we lack the most: > > * examples of working setups > * easy-to-search documentation for details like configuration or > mailets > * guides for the most usual things: configure some mailets, write my > own, how to debug a mailet pipeling, how to plug my app in James > efficiently Yes, all good points. > James already works for a lot of use cases, there's nothing really > lacking in term of code, we should stop thinking the software should > be better before being happy with it. A lot of successful softwares > are less mature than James. > > TL;DR we have to explain how it already works đ > 3. About versioning (3.x vs 4.0) > > Like roadmaps, major version numbers give people expectations: there > must be something very new and/or very different because the > community decided to increment major version number. Yes, you are absolutely right that a version number sets expectations. And so it should. That is actually kind of the purpose. If possible, we should consider moving away from soft requirements and use semantic versioning. I think that the concept of semantic versioning is specified well enough to be considered as being quite objective. Hopefully that should avoid this type of debate. > Last time the community tried that (3.0) the projects almost died > because too many things had to ship at the same time and then was > never ready. It took years to finally release it after Linagora > started to invest a lot it and by the way, we never finished what > was supposed to, we just decided that, no software being perfect, we > had to release this much-better-than-2.x version. Oh, that is interesting. It is always good to learn from experience. > I would like to take the Linux Kernel path: > > * only increment minor version for the time being > * don't build a backlog or any list of things we want to achieve > before incrementing Can you explain this point more? > * release 2 to 4 times a years with what is ready > * increment major version when what will be ready deserves it or > when minor number get to big This seems a bit arbitrary. Maybe we could instead figure out what semantic versioning means to James, so we can have a more objective criterion? > > 4. About defining a vision > > You defined different kinds of software project styles and it's > interesting to try to define where James is. > > Let me define how I see it. > > The community and the project doesn't have a vision yet. The > community is small, mostly composed of people using James in > enterprise context or paid to work on it. > > Apache Foundation projects should not be led by a single company so > Linagora is not taking the lead on this side. Why do you state this? Is there some rule? Or you are worried about appearance? There is indeed a really heavy Linagora presence here. I think itâs great, and I really appreciate your caution. Without yet agreeing to this point, I donât mind acting like a moderator to capture the vision. As a moderator I can stamp my name on it to assure the community that it is not too biased in favor of a single company. > It means to me that the best we can do as contributors is to > contribute to the project in a way that is useful to us and try to > welcome newcomers as well as we can. > > If the project is valuable to us, it will eventually be valuable to > others. We have to stay commited to it for the time being, continue > as we did for the past years. > > I can't see any vision that the community would be able to commit > to, so let's say it's just a project that wait for its hour of > glory. đ Well, I think weâll have to be a bit more proactive, but letâs continue this discussion to see where it takes us. I think from what we experienced over the past few months that for a slowly evolving project like this, the Documentation actually seems to be a great way to capture all these ideas. We can debate the contents of the docs and as a nice side-effect resolve issues like: should there be a roadmap, and if so, what should it contain? Thanks a lot for always putting in so much effort and thought into this. I hope we can have another live chat soon. Cheers, =David --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
