This is getting off-topic ;D
Agreed, so changed the topic to another subject ;-)
I have thought a long time about if I should post what I have said before. Why? Because it's clear to me that the situation is just like you said: Jahia relies heavy on Open Source software like Tomcat, Lucene etc. It's absolutely clear too, that you can't held be responsible for what bugs these software packages have. And like you wrote before, the support from Jahia and it's R&D centers is good and fast. Most of the time, we got a patch on the same businessday we posted the issue.
Thanks. We try to do our best.
That said, I think that you should also keep in mind that you sell jahia for $$$ and the customer expects the software to be well working.
I agree even if no software is never perfect and free of defaults.
So when PDF indexing isn't working, he expects that someone is responsible to make it working.
Mmmh. Let's be true: the PDF indexing feature is working. Only certain PDF which seems to contain certain closing errors seems to have some problems. So it is not black or white here. The question in this case is: are we for example responsible to detect corrupted PDF generated by another program and then to adjust our code accordingly? Is this really a Jahia bug fix?
But no worries, we are currently evaluating what we can do to solve this particular issue ;-))
Like said before, we got fast error solutions from you. But what makes me anxious is that sometimes I have the feeling that Jahia just fixes these bugs because it can and not because the customer payed for a license... What you said is true, but you still have some responsibility to fix issues which cause Jahia to misbehave... even when they are originated in third party software. That is especially true when you advertize Jahia with features that relly on these packages to work.
I agree but there are different solutions to solve a problem. We may find a short term fix (it would be great but no guaranteed as this may be more complex that just a one line bug issue). We may also find some more long term oriented solution (in such a custom case this would be more to let the end-customer choose another indexation server (Lucene, Verity, Inktomi,...) he may prefer to use .. and such a feature is indeed already planned for Jahia 4.5). So the real question is the adequate way and timing to deliver a solution: buying a license is not buying a support contract (e.g. www.jahia.com/support) and this does never grant a right to get an immediate fix. But the same is ture for other classical proprietary software.
P.S.: Regarding the priority of features you talked about, I think it's clearly up to you to decide which feature has priority. You know your job best :)
Thanks to the Jahia license, we are not the only one any more to be able to decide... You can now influence yourself the vision too (for example by assigning the budget of your license to a feature which seems more important for you than perhaps for other customers...).
Else of course, we will choose ourselves the priority according to the overall needs we see in the community of Jahia users and the ones which looks currently the most problematic... But in such a case, this is perhaps not yours...
Just keep in mind that out there lives a end-user which is just interested in a nice wysywyg editor and searchable word and pdf documents and stuff like this.
Got it. But do not forget that you have the right to influence the direction of the Jahia software. Most of the new incoming features are indeed directly specified by end-customers. So we are clearly not in our ivory tower trying to solve imaginary problems. All the Jahia committers are indeed employed by system integrators with some direct customers ;-) ... This is more the opposite which is happening: with such "open" licenses, the users always want new features but often do not see some required back-end architectural changes (for example changing the peristance layer of Jahia will not bring any new end-user features, so no customer are really ready to point it out, vote for it or sponsorize it. However such a refactoring will bring a lot more of stability and really ease maintenance on the long run).
So we always try to find a right-mix for each release. But please always feel free to send details of your needs and suggestions to improve the overall quality of Jahia. This mailing list is also here for that. Any new good idea is more than welcome while it is proactive on the way we can better things. So if you have some better ideas about "a nice wysywyg editor and searchable word and pdf documents and stuff like this" do not hesitate to share your ideas in more details with the community...
Best Regards St�phane
On Wed, 08 Dec 2004 12:00:46 +0100, St�phane Croisier <[EMAIL PROTECTED]> wrote: > At 11:00 08/12/2004, you wrote: > > > >thank you for the links. But since PDF indexing is a feature of Jahia, > >I hope that the Jahia team is still working on resolving issue in > >their software (pdf support). It's not about performance, but failures > >we talk. If pdfbox is just crap, it would be a good idea to at least > >provide adapters for other engines that support productive > >environments. For me it's like having HSQL DB as a free and instarun > >database for Jahia (which is good) and ALSO have additional support > >from scratch for MySQL and Oracle (which is absolutely required). > > Warning, warning, dangerous ground ;-) : > Jahia is released under an open and community based philosophy > (collaborative sourcing = nearly open sourcing). So the paradigm is to try > to offer the best prices and to commoditize the high-end/mid-range CMS and > Portal market. The cons is that we need to rely on other "open source" > layers which we integrate to avoid certain R&D or OEM costs. Same is true > for RedHat/Suse or others: They can try to help the community improve > certain layers with their own dedicated staff but they are not Microsoft, > they do not have control on the full Linux layers they package. Then they > also have to rely/wait after the work done by the community and follow > their decisions/priorties (or mandate someone to do a custom important > improvement but then indirectly bill it to the end-customers through some > "expensive" support programs). > > So regarding bug fixes in the Jahia core kernel, I think our history (cf: > changelog Jahia 4: http://www.jahia.org/download/jahia4/4_0/pr/history.txt) > speaks for itself and I doubt lots of editors offer better and faster bugs > resolutions. > > Regarding supporting third party layers and/or adding support for other > commercial products, this is more complex. What if there is a bug in > Tomcat. Because we package it by default, this would mean we also need to > support it? So ideally, we should have some neutral abstraction layers > everywhere in the code in order for the customer to use any commercial or > open source layer he wants to replace. Practically this is not so easy to > do especially when the external contributor did not think about it while > developing his extension. Moreover IMHO there are other more strategical > "abstraction layer" we need to implement before the PDF plug-in one (e.g. > the persistance layer with Hibernate or Apache OJB, the search engine layer > with other tools such as Verity, the caching layer with tools such as > Tangosol, etc..). > > So then it is a question of priority... But here again, Jahia is released > under a collaborative source license. If THIS is a priority for you, please > do not hesitate to develop it or sponsorize the integration of another PDF > parsing library in exchange of a license discount... In opposite to other > proprietary license, you have this choice and this right. > > Peace > St�phane > >
