<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - UI: Branding: LibreOffice Personal edition" href="https://bugs.documentfoundation.org/show_bug.cgi?id=134486#c60">Comment # 60</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - UI: Branding: LibreOffice Personal edition" href="https://bugs.documentfoundation.org/show_bug.cgi?id=134486">bug 134486</a> from <a class="email" href="mailto:miles@filmsi.net" title="Martin Srebotnjak <miles@filmsi.net>"> Martin Srebotnjak</a> <pre>Hello, I am trying to look into future, so can someone please explain to me how this will work (let's say there are the "community" (or whatever it might be called) and a vendor version ("professional" or whatever it might be called): Who decides what features will get into the "community" version? Will this be a board/developers decision where also vendors will participate and could block the community developers changes of core code? I think that if vendors have a say what will be exclusively in their versions (which I think is great), they should not block features that community developers are introducing into the "community" version, even if they are counter-productive for their commercial offerings. And this could lead to actually three versions: - core LibreOffice code that is developed by the community and vendors alike (and tested by both, bugs squashed by both, translated and documented by the community - as the vendors do not spend many dimes on it etc.). - community LibreOffice (additional features developed, tested, localized, documented, promoted - by the community) - probably some community features are useless or even overhead for the vendors; - professional LibreOffice (additional/paid features developed, tested, localized, documented, promoted by the vendors themselves). This could lead to a point where the added features either by community or vendors would require changes in the core LO and where the other party would not agree with such core changes (a rewrite or use of another open source library that would make some features obsolete etc.) - so there should be a veto possibility for both the vendors or community representatives in the TDF bodies. regarding the changes in the core ... This could lead also to double implementations of same functionality (one offered by vendors and the other for free by the community - surely the community would have the right to develop and include its own versions of vendor features? Or not? Would they be blocked? Also, the role of TDF changes with this and as such should probably the structure of its bodies. TDF becomes a promoter of the LibreOffice brand and tje free version (and not the promoter of professional versions by vendors, as is now in every public statement of the TDF). Or will keep being promoter of paid versions of vendors, funded by donations as donations to an open-source, free project? This becomes kind of fuzzy to me. If the community will not have absolute freedom of what of its ideas/code/content gets into the community version, this could probably lead to a general schism. On the other hand, this development is not so bad. The new version system will free many community resources - a lot of developers now working on testing and patching vendor-proposed/developed features will be free to code and test their own, community features and this could lead to a rise in brand new functionality of community LibreOffice.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>