Community to independently maintain Palo Suite?

    Community to independently maintain Palo Suite?

    Do you want to participate in a Palo Suite open source spin-off? 8
    1.  
      Yes, and I can lead it (0) 0%
    2.  
      Yes, and I can help (6) 75%
    3.  
      Yes, but I don't have time (0) 0%
    4.  
      Good idea! But I don't have the technical skills to help (2) 25%
    5.  
      I'm a Palo user, but I'll just upgrade to Jedox when the time comes (0) 0%
    6.  
      The BI field is too crowded, it won't work (0) 0%
    Palo Suite is apparently going to stop being developed/updated by Jedox, but the source code's there for anyone to use,
    Does anyone want to create a separate project that will build on the Palo Web source code and keep it up to date with the latest version of the OLAP server? Maybe someone can re-create user rights in the Web interface, too?


    It won't be me (at least not alone), since I'm not really a programmer. But if enough individuals/groups wanted to, we could make an independent project that leverages the cool benefits of Palo. Anyone interested?
    I think it would be a good idea in general (and yes, I would help). There's plenty of opportunities (no, I don't agree with the last choice) but you would need a (very) good business plan. Even though it's an attractive idea, it is a massive taks to keep up a project of this size and complexity. Palo suite is made up of different pieces requiring very different skills ranging from C to Java to PHP not commonly available in the BI consulting sector. The code that's been currently released doesn't seem to be in an excellent shape. I've done some research and it may be missing some bits compared the available (how critical, not clear - I haven't managed to build yet). Maybe Jedox will release the source from at least the same build (and components) as current CE (or even include some 3.2 service packs) - that would be a tremendous help.


    In end of the day you will need the following:
    • web development resources to maintain and update the web front end
    • Java resources to keep the ETL part in shape
    • C/++ resources for the backend and libraries

    There are other considerations as well. One of the drawbacks is GPL. If you are truly innovative you cannot maintain your competetive edge. If the license were more permissive it would be more attractive for innovativeness and even gain from that. The other side is that you would be attached to SME segment forever - large enterprises do not like GPL very much. Even if Jedox would reconsider its licensing strategy (e.g. replacing GPL with more LGPL) it wouldn't work because one of core dependecies is ExtJS which is under GPL3 currently (I've heard that some time ago it was different license. If you manage to get the source with that one from somewhere you're lucky - and please share. Ideally (in practical terms) at least the API libraries would be available at least under LGPL.

    In any case, if you build your business around a GPL stack you probably will charge for the same thing as closed-source vendor i.e. for improving the code. But you can not guarantee any breakthrough for your customers since you are not likely to invest substantial resources in R&D.
    So a developer can't even take the source code and build it independently of the installer?? In my emails with Jedox I was told "the source code is there for anyone to use". If what you're saying is true, it would be an indication to me as to why it doesn't have a more substantial community support already. (On the flip side, if that were to change, and people could really dig in and do pull requests and all that, then I think a lot of people would be attracted to it.)

    As far as the business model goes: There's definitely more that would need to be discussed about this, but there's a lot of flexibility as long as there's a community there. So I ask again to anyone out there, please indicate if this is something of interest to you...
    I'd like to clarify few statements I made earlier regarding the source code:

    1. Source for Molap server is fine and I am running v3.2 server at 64 bit as we speak.
    2. Source for web core is still under investigation. It has so many dependencies and esoteric tweaks around the build so it takes time to figure everything out.
    3. ETL - I have no idea, I'm not really into Java too much. If someone could try to look into this that would be helpful. Even bare ETL without the full suite would be very useful.


    Madis
    the Excel frontend is programmed in C# and you need an older version of the *commercial* compiler from Microsoft to build it

    I have not seen any newer source code than 3.2 (= what is on sourgeforge ATM) but I have a hunch that Jedox have rewritten the engine to a point where we would not recognize the roots...

    The interesting deed will be the release of the source code of version 5 next month and the license attached to it. If still GPL - fine.
    Since Jedox have not gotten any serious community commits over the years they could still try to change the license of newer versions.
    The other thing that remains to be seen is the scope of the release - where does the "free" version end?

    I would really like some work on the frontend for libreoffice (another Java setup than ETL...) or a frontend for Calligra suite.

    I would help but I am no programmer (can read C++ and php). The Java SDKs and respective buildtools have always been a roadblock for me when trying to rebuild the source from sourceforge.

    I could do testing and have strong opinions on usability ;)