Author Topic: Planning to drop ebox-egroupware support, volunteers for maintaining it?  (Read 34501 times)

Sam Graf

  • Guest
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #15 on: August 17, 2010, 07:10:05 pm »
For what it's worth, the openSUSE Build Service appears to have up-to-date eGroupWare packages for Debian and Ubuntu:

http://download.opensuse.org/repositories/server:/eGroupWare/

I use the openSUSE repository for our eGroupWare installation.

EDIT: The instructions for adding the correct repository to sources.list are here:

http://www.egroupware.org/download
« Last Edit: August 17, 2010, 07:13:22 pm by Sam Graf »

centaur5

  • Zen Monk
  • **
  • Posts: 61
  • Karma: +1/-0
    • View Profile
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #16 on: August 17, 2010, 10:01:08 pm »
My concern is this; how long after we choose the replacement whether it be Zimbra or Zarafa are we expecting to have a usable module?  I used to manually configure all the services offered by Ebox a couple years ago.  Now that I use Ebox I don't want to manually configure services because if I manually modify a file that I don't know Ebox depends on then all my changes will be gone.  I've been using Egroupware for a year now and although I would rather have better client sync support on Linux I've been able to deal with it.  I don't want to use a web interface for groupware.  I've been using the Ebox platform for a couple years and have anticipated every release hoping for a complete solution for everything I need and for more stable functionality.  After 2.0 is released I was going to see if it was good enough for me to stick with instead of finding an alternative project.  If I did decide to keep Ebox I had every intention of purchasing support to help contribute.  I understand this move needed to be done but if a new solution takes too long to implement I'm not sure what I'll do. 

J. A. Calvo

  • Zentyal Staff
  • Zen Hero
  • *****
  • Posts: 1986
  • Karma: +67/-3
    • View Profile
    • http://blogs.zentyal.org/jacalvo
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #17 on: August 17, 2010, 11:02:59 pm »
Hi,

First of all, thank you very much for your feedback. I see that there is
a huge interest in Zimbra being integrated in eBox. This is not
surprising as we already saw that in the poll about the 2.0 features in
this forum. Because of that, we already evaluated the feasibility of the
Zimbra integration as the first choice for an eGroupware replacement.
Sadly, we concluded that it wasn't easy at all, as Zimbra includes its
own packages for ldap, web server...

Anyway, if any of you can contribute with detailed instructions on how
to do a good integration or even code it would be great.
Zentyal Server Lead Developer

Svein Wisnaes

  • Zen Samurai
  • ****
  • Posts: 325
  • Karma: +5/-0
  • A Norwegian living in Brazil
    • View Profile
    • Oceanwatcher Media | Svein Wisnaes
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #18 on: August 17, 2010, 11:41:47 pm »
In fact, when I was supporting sync for staff personal devices within Outlook, we had calendars and address books cluttered with personal information. What a pain. I requested that we not support personal devices when we implemented eBox--and the "excuse" that it was a pain to do in the Linux world was actually an asset! :)

But even in a small group, building a corporate intelligence is VERY important. None of us lasts forever, and an accumulation of shared knowledge is a tremendously valuable legacy. So it baffles me a little that so few people here value the knowledge-building tools of a groupware product.

About syncing personal devices... How do you differenciate? For some, a mobile phone is a personal device, for others it is an essential tool for doing the job...

I totally agree with you regarding building a bank of knowledge. Which is why I suggested this:

http://forum.ebox-platform.com/index.php?topic=4556

I am not too happy to use tools that claim to do EVERYTHING. I prefer specialized tools that are able to work together with other tools. This also makes it easier for those that do not need one particular tool - they can just drop it and use the rest.
Regards,

Oceanwatcher
Do NOT use PM for support. This is a community forum and support is not on a one-on-one basis.
READ BEFORE POSTING - How to make a good post - click here

Sam Graf

  • Guest
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #19 on: August 18, 2010, 01:57:33 am »
How do you differenciate? For some, a mobile phone is a personal device, for others it is an essential tool for doing the job...

So an organization is obligated to support personal mobile devices of whatever sort on a business network? That sounds problematic on several levels. So it's reasonable to differentiate by ownership, it seems to me.

I totally agree with you regarding building a bank of knowledge. Which is why I suggested this:

http://forum.ebox-platform.com/index.php?topic=4556

I am not too happy to use tools that claim to do EVERYTHING. I prefer specialized tools that are able to work together with other tools. This also makes it easier for those that do not need one particular tool - they can just drop it and use the rest.

eBox, of course, as a modular turnkey solution is a product that claims to do everything in the same sense that a modular groupware product claims to do everything. And in the case of eGroupWare, there is no reason to enable modules an organization doesn't need.

I'm not saying that eGroupWare is indispensable to a satisfactory eBox experience. It isn't, IMHO. At the same time, a product that has a wiki here, some webmail there, etc., isn't obviously easier to manage, IMHO, either from an end user point of view or from an eBox integration and maintenance point of view. A case can be made that eGroupWare is not an ideal solution without insisiting that half a dozen or more specialized tools makes more sense. That would be like trying to argue that a CMS is an inherently bad idea relative to individual software packages that do what the CMS tries to cover in a single product. I don't see the benefit to eBox either as a product or as a community of that kind of argument.

Svein Wisnaes

  • Zen Samurai
  • ****
  • Posts: 325
  • Karma: +5/-0
  • A Norwegian living in Brazil
    • View Profile
    • Oceanwatcher Media | Svein Wisnaes
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #20 on: August 18, 2010, 02:30:55 am »
I was not arguing anything regarding devices :-) Merely trying to figure out how to differentiate, thinking it might be difficult... Is it possible to block someone from syncing their phone if the sync feature exist? If someone in management have a job phone (Nokia of some sort) and this model can be synced, how can I block someone with the exact same model from syncing? I absolutely understand what you mean, I am just curious on how to achieve a different treatment.

Regarding modularity etc - yes, eBox as a WHOLE would probably try to do at least everything (did not see any coffee making module yet  ;D ), but you can even avoid installing some of them if you do not need it.

For the most groupware solutions I have seen, you have to install everything. You do not need to use everything, but it will still be active and will be running in the background. So a real modular approach would be appreciated.

Regarding eGroupWare - anything that is not sufficiently maintained should go out. That totally makes sense. I see this as a big opportunity to go through whatever is available in the market and get something in that

1. Has a big userbase
2. Has a solid developer base and no uncertain future
3. Support desktop clients, handheld devices and has a good web interface for those that prefer that.
4. Has a good administration interface

And definitely not in that order ;-)

I am looking forward to the outcome of this. I think that a good replacement for eGroupWare can be a solid plus for eBox and a reason why people would want to set up an eBox server. I don't know all possible solutions out there and I am checking all the different ones that come up in this thread.
Regards,

Oceanwatcher
Do NOT use PM for support. This is a community forum and support is not on a one-on-one basis.
READ BEFORE POSTING - How to make a good post - click here

Sam Graf

  • Guest
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #21 on: August 18, 2010, 02:47:02 am »
For the most groupware solutions I have seen, you have to install everything. You do not need to use everything, but it will still be active and will be running in the background. So a real modular approach would be appreciated.

PHP scripts take up disk space, not RAM, when not in use. A PHP script has a relatively short time to do whatever it is that it's going to do before it times out. :)

Regarding eGroupWare - anything that is not sufficiently maintained should go out. That totally makes sense.

Agreed. eGroupWare, of course, is still in active development and up-to-date repositories are available, as I mentioned above. The fact that neither Debian nor Ubuntu kept up with recent eGroupWare releases doesn't mean the product doesn't have recent releases or isn't in active development as a community product. :)

EDIT: Just to provide some eGroupWare usage data, let me add this:

http://www.egroupware-server.org/usage-statistic

Carry on. ;D
« Last Edit: August 18, 2010, 02:58:18 am by Sam Graf »

bbking

  • Zen Monk
  • **
  • Posts: 97
  • Karma: +2/-0
    • View Profile
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #22 on: August 18, 2010, 10:38:32 am »
To some extent I have to agree to the above. On the other hand, whom does a built-in wiki disturbe if he doesn't use it?
Just a short story from real life:
At my recent employer we are doing customer acquisition and we keep all our contacts in a single excel file (which has some nice macros), shared over a windows share. Can you image how often I was getting mad, because somebody overwrote my changes after syncing his/her laptop in the network?? I could explode, but that's no use, the boss refuses to change the system.
Then, yesterday I checked out the Zarafa/SugarCRM demo (http://zmdemo.zarafa.com/) and I thougth I gonna fall from my chair. The two systems share address books and calendars. In our case that would mean: no more double-entering of contacts, no more forgotten appointments because you haven't checked the damn excel sheet for a day.

I know, this is an extreme example, but I am aware of not only one company who work like that. Such a solution would speed up the acquisition in our case approx. 10-15%. To me, this is a consistent solution that lets you focus on your work and not on the tools you are using. THAT is a big difference.

Regarding mobile devices: it would be the whipped cream on the cake to have the system above available on the mobile devices. At least in the Blackberry Enterprise Server you can control everything: what kind of information the device is allowed to sync, you can even wipe the entire device remotely, if it gets stolen. I know, this may sound as a bit of an overkill, but I'm a fan of *complete* solutions.

Mammut

  • Zen Apprentice
  • *
  • Posts: 24
  • Karma: +0/-0
    • View Profile
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #23 on: August 19, 2010, 05:50:02 pm »
How about kolab? I use it elsewhere and it is for mail, calendar, addressbook, antispam, antivirus extremly good. For webmail kolab uses horde. And it is fast!

azteech

  • Zen Apprentice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #24 on: August 20, 2010, 01:03:29 am »
I too am not surprised that eBox is dropping eGroupware, due to it's complexities in setting it up properly through eBox. I have been trying for several days to get this properly working, and have met with little success.

Having reviewed what others have stated in previous entries, I have to echo their sentiments; though I don't have an adequate solution/recommendation for a suitable replacement; we are still evaluating several other options/solutions but have not found any of them truly suitable, mainly due to little quirks here and there.

What I believe eBox developers really need to do is request input from the community at large -- maintainers and users alike.
Put together a survey letter and ask system integrators, current customers, potential customers, and users of the product

1) what they would like to see in all-in-one management package,
2) what they would like to see in a all-in-one user desktop package solution,
3) what they are currently using to accomplish their job today,
4) what are the future plans for further applications that each one will require,
5) does the customer/future prospect already have a groupware solution in place, that eBox needs to be integrated with?
6) If they have their own groupware solution in place, will they need outside assistance to develop integrated package front-ends, or just ide's/API's/modules that interface with said package that their in-house staff can take and make work, easily?

If the survey is crafted right, what may be derived from it is snap shot of the current market requirements and future trends that eBox may need to go. Does the customer want a solution that integrated all that eBox has to-date, but add to that, the requirements for modules that interface with third party groupware/CRM/ERP/ticketing systems as well.

While the development cycle may be increased, once the requirements have been determined, I believe in the end run you will have a much better product to offer the community, commercial and otherwise.

For now, IMHO, drop the groupware package, and concentrate on the remainder to get 2.0 out the door soonest; then develop the rest.

One other item that sorely needs addressing - Adequate, accurate, and up-to-date documentation. While it would be nice to have it when the product is released, if it followed with-in a few days that would be tolerable.
IMHO, complicated, all-in-one products that are released, without adequate, updated documentation, is just as worthless as software that has not been adequately tested/written/documented. A good example of how not to do this, is the 1.5/1.5-1 release that points only to the 1.4 documentation, even though the 1.5 series is clearly heavily modified, screen snapshots dont' match what product screens show, and customer is left to try to figure things out on their own -- you lose customers/prospects that way.
« Last Edit: August 20, 2010, 01:32:30 am by azteech »

Marcus

  • Forum Moderator
  • Zen Samurai
  • *****
  • Posts: 395
  • Karma: +12/-0
    • View Profile
    • Professional IT Service
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #25 on: August 20, 2010, 03:48:45 pm »
I and my customers will be happy as long that there is an integrated groupware solution that comes with eBox.  

Something that will be supported by either Evolution (Gnome), iPhone and RiM.


nachico

  • Zentyal Staff
  • Zen Samurai
  • *****
  • Posts: 338
  • Karma: +31/-1
    • View Profile
    • Learning To Fly
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #26 on: August 23, 2010, 08:37:59 pm »
One other item that sorely needs addressing - Adequate, accurate, and up-to-date documentation. While it would be nice to have it when the product is released, if it followed with-in a few days that would be tolerable.
IMHO, complicated, all-in-one products that are released, without adequate, updated documentation, is just as worthless as software that has not been adequately tested/written/documented. A good example of how not to do this, is the 1.5/1.5-1 release that points only to the 1.4 documentation, even though the 1.5 series is clearly heavily modified, screen snapshots dont' match what product screens show, and customer is left to try to figure things out on their own -- you lose customers/prospects that way.

As you should know, and as it is clearly specified in every 1.5/1.5-1 announcement, those are just beta versions, not intended for production environments. You should not use them with your customers.

Keeping the documentation up-to-date is a very time-consuming task and should only be done when it is really needed. At this moment, we are spending a lot of sleepless nights and fun-less week-ends to get the 2.0 doc out as close as possible to the 2.0 release date. Once it is ready, we will still need to translate it to English. We will do our best to have it as soon as possible, but our resources are limited.
CEO at Zentyal

elishughes

  • Zen Apprentice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #27 on: August 23, 2010, 09:34:58 pm »
...

Anyway, if any of you can contribute with detailed instructions on how
to do a good integration or even code it would be great.


While Ebox / Zentyal is based around tight integration of components, perhaps in the case of something as complicated / full-featured as Zimbra, it would be easier to only integrate the basics and delegate to the normal web UI for any advanced features? http://wiki.zimbra.com/wiki/LDAP_Authentication covers using an external LDAP server with Zimbra, which would allow authentication and Global Address List lookups to happen against the main / central / master LDAP in Zentyal, while Zimbra's LDAP is only used for Zimbra-specific things. The Zentyal web interface could be used for managing usernames, passwords and email addresses, while the user would use the Zimbra Admin UI for anything else, including email quotas, domains, away messages and all the other little options Zimbra has in the admin interface (like theme preferences for the Zimbra Web UI, distribution list membership, allow/disallow access to features like briefcase, etc ). We've found Zimbra to be easily the most professional / enterprisey solution for our needs, and will be looking to get it authenticating against Zentyal in our setup. Even if an easier-to-integrate option is chosen for the groupware module, a smaller module that just allows using the Zentyal LDAP to manage the mail attribute for a user without pulling in the entire dependencies for the alternate groupware would be useful.

bbking

  • Zen Monk
  • **
  • Posts: 97
  • Karma: +2/-0
    • View Profile
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #28 on: August 25, 2010, 10:05:00 am »
How about doing an online survey among the Zentyal users and see what their needs really are? A couple of people are favoring this or that solution, without looking into other products deeply.
If we'd have the result of this survey, we could take a look at different solutions and take the one fitting best.

Come on, don't let this be a biased decision, let's do this well!!

Sam Graf

  • Guest
Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« Reply #29 on: August 25, 2010, 05:46:49 pm »
I agree that this is an excellent opportunity for Zentyal to collect detailed information on actual user needs and/or implementations. That way the trends would emerge and informed decisions could be made.

On the other hand, at the production end of things, it's not always so easy changing user-facing products just because Zentyal adopts (or drops) support for a given groupware solution. If nothing else, as you mentioned earlier, organizational inertia is a major factor in these kinds of things, for good or ill. Those who need or want "just" a back end for Outlook/Evolution obviously are in an entirely different circumstance than those of us who are already using a more comprehensive knowledge worker approach and solution.

That's partly why I eventually opted to separate out my eBox and groupware solutions. eBox (along with Debian/Ubuntu, despite all the fuss over Ubuntu's dedication to the cloud) clearly wasn't focusing on being a fully-integrated, comprehensive groupware server solution, and I needed continuity and reliability (not to mention support) to keep the peace with the people I work with every day. It was just easier to split the tasks and leave eBox--the "middle man"-- out of it altogether.