Hi, 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.
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. 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. 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 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. 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. 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 * 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 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. 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. My conclusion is that this project is a very valuable one, written by some very talented developers for something like 20 years or so. 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. 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. 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. 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. 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. What would you think of such a move ? Cheers, -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
