SUGARCRM - getting frustrated by it

[patternreloaded]

Hey and hallo,

after 8 years of up´s and down´s in using open-source (mostly up´s) I reached a new level. This level is affected by thinking about problems not about establishing more effective solutions in sugarcrm.

Sugarcrm hast a lot of features and detailed solutions. We need leads, accounts, contacts, campaigns, emails and activities. But in detail to much functions do not work well or have a very high potential of disruption.

Viewing the items in this forum, I suppose most people think about work-arounds and handling disfunctions.

Don´t know about stability and reliabilty of the commercial-version. The open-source-version of sugarcrm (4.5.1d) does not invite to grey.

Now we have to find another more reliable solution. Sugarcrm is no more an aspirant for further projects. Established sugarcrm-projects are now in phase-out-state.

Thanks.

patternreloaded

[tomek0013]

I agree with You.

We bought sugarcrm Pro version. We have been promised to give us technical support. I sent several e-mails and I haven’t got the answer yet.

Sugar does NOT care about customers. Their purpose is to get new client, get money, and forget.



Best Regards

[Angel]

I know how to use the formatting tools too! Yay!

[tm2000]

this is one of those threads that I'm never sure if one should just let it be - or enter into the debate... so, I choose the later. Have been a user for SugarCRM Open Source since version 3ish.. Currently we are using 4.5.1d and it works GREAT!

Sure, there are a few bugs, but we have been running our biz on it for a long time and it does a great job.. Maybe you should look for others to help you. There are several conultaings within these forums.. and even a board to post for professional help..

In terms of the one person that has paid for Sugar, I would send an email to the main guys.. It does not sound like what I know of the team..

Best of luck to you both..

[malcolmh]

Hi,

As a professional user, use the Support Portal to create a support case. Cases that are created here are usually quickly dealt with!

We have over twenty customers HAPPILY using SugarCRM. Yes there are bugs, but what software doesn't have. Sugar's QA efforts are also not perfect!

To comment the initial post from patternreloaded, don't really understand what you are saying, could you be more specific about what is wrong (you can also write it in German).

[patternreloaded]

Hey,

her are selected examples of current problems/misbehaviour:

1. Duplicate an Campaign
If a campaign will be duplicated, the configurated trackers are not duplicated.

2. Modifiying the label of "Reports to" causes a problem with the pop-up on editview. It does not work anymore...

3. Database-Performance
The generated SQL´s are not suitable for advanced performance-tuning in MySql.

Don´t know about the causes behind this, but it´s frusttrating and time-consuming.

Best regards

[jas0np]

I'm also getting frustrated by SugarCRM in particular, and at the larger PHP open-source community as a whole!!

Addressing the PHP community, there is no excuse (with PHP5 now out for three years, and object-oriented design patterns well documented for thirteen years) for there to be so much horrible, bloated PHP software out there (Joomla, osCommerce, etc., etc., etc.).

As for SugarCRM, I'll start with the good points: 1) It is not SalesForce. 2) It is open source, and 3) It has a pretty UI. Touching on some of the bad points: 1) It has a convoluted database design, 2) In typical PHP open-source fashion, it employs "shotgun includes" spattered here there and everywhere, and an also oh-so-typical procedural "whose scope is it anyway" coding style, 3) It's API is bloated and documentation is non-existant. The API returns the XML equiv. of MySQL describe table on every... single... call, and there's no option to make it stop, 4) What's all this bean stuff? This ain't Java. 5) The whole app is slow, 6) The app becomes buggy and unreliable upon customization. Something as simple as removing a tab from the tool bar can crash the app. 7) It's complexity makes writing my own CRM system very appealing at this point.

For those of you contributing to or leading open-source PHP projects, I highly recommend a look at how the folks at PHP themselves are doing things with their own open-source PHP project: the Zend Framework. These are actual software engineers doing things the right way and demanding quality work. Please learn object-oriented programming techniques! Please learn about the SPL! And, please, please, please stop with the shotgun includes!

[eggsurplus]

My take on your "bad points":

1) Huh? I've been doing database work (with existing systems as well as designing new systems from scratch) for years and this is in no way a convoluted design. It's actually pretty elegant. I'd like to hear your thinking behind this. It's normalized pretty close to as much as it can without trading off too much of a performance hit.

2) Seems more of the flame-war type argument.

3) True, it does need to be rid of deprecated functions but other than that it's not bloated. I do agree that it returns too much each and every time. I've had to custom code some settings to prevent it from doing so for the purpose of preventing timeouts there we were getting.

4) You can't complain about includes, php style, etc and then complain about an object oriented approach.

5) Usually due to an administrator not knowing how to optimize Sugar. All systems that I've worked with have needed optimizing. This is a necessary evil of application systems. Each organization needs to optimize it specifically to the way that they use it.

6) Odd, I just tested this and it worked even better than I expected. Perhaps you just had a bad install? Other issues with things happening after code-level customizations are usually due to the developer not understanding how Sugar needs to operate. Overall, the critical show stoppers have been minimal. In fact, we haven't come across one in our instance in quite some time.

7) There is always a trade-off between what an application can do and it's complexity. Once someone has gotten over the learning curve though the possibilities are endless. This can't be said of more simple systems although those systems may be able to meet your needs.

[Tristanlogd]

Just thought I would give my 2 cents, for one thing Sugar is Elegant on the front end. The developers have done a great job at making the application look and work fantastic. However I have to agree that the Database and Backend is spotty at best. And adding or changing anything to use sugar with an in house system is not for the feint of heart.

* I have to agree on the Database structure. Mixing foreign key type structure with linking multiple database tables together using bean ids is slightly convoluted when you could make it work so much better in a much simpler way. When developing with sugar I had to literally do data dumps to find where data was going to, and what tables were being effected. This should never be the case when working with software, there should at least be documentation that clearly tells the end user how certain tables interact with each other. Sure, I can sit and figure it out, however that eats up development time.

* Then we have the API, written haphazardly in a procedural style I assume. It works, however its slow, bulky, and again written in a convoluted manner. Using the API to select from multiple tables, take those results, run statements on them, and then insert back into multiple leads, contacts, or cases takes longer than it really should. Not to mention the little to absolutely zero documentation available that isn't from 4 years ago.

* As for complaining about includes, you can complain about shotgun includes as he stated, as that's exactly what sugar is in alot of places. Files placed randomly with random includes with little to no documentation as to why the includes were added or what they do. Modules, that if removed, break the system.

* Optimize sugar? Where does one start? If you remove or change anything the system appears to fall apart. How have you optimized the system, and how long did it take you? A good system allows you to change and optimize it quickly and easily because the code is well structured and easy to work with.

Sugars great as long as you dont do to much under the hood, or you have the time to take a few months to understand every bit of the system. You might say as a developer you should be able to know a complete system before developing on it, however a truly great system allows a developer to adapt almost instantly, because code is clean simple to understand and uses common standards. Sugar is not one of these systems.

[jas0np]

Just to clarify, SugarCRM is an excellent system. It's the best CRM I've ever used from a user's standpoint. It's just not elegant "under the hood." I'm not trying to flame. My post was really just venting. I'm happy for those who have the time to learn the ins and outs of Sugar. Perhaps I'm too impatient, but when I need to use the API of a third party system, I need it to be intuitive and well documented.

I'll re-address the bad points in order:

1) I've been designing databases for years also. The fact that Sugar has an inconsistent foreign key implementation is one of the biggest problems, really. With such a complex system, I would recommend a more intuitive naming scheme, and perhaps utilizing the MySQL native InnoDB foreign key implementation which I have found to be excellent and a great way to simplify the Model code.

2) Not flame-war at all. I understand some people prefer procedural programming, and others prefer object-oriented programming. At the same time, logistics must win out over preferences when it comes to such a complex application as Sugar has become. Procedural programming is unwieldy for large systems, period.

3) The API needs serious cleanup, and I know the lead API developer has no plans to document the API because he said as much in a screen-cast I watched on the Sugar website. He simply said "look in the code to find out what is available." That's not really acceptable. Also, the SOAP server is a custom job and quite slow. The native PHP SoapServer allows you to make any object into a SOAP API very simply, and it's lightning fast because it's compiled into the Zend core.

4) Includes become a non-issue when dealing OO PHP when employing an autoloader (or a stack thereof). When you instantiate a new object, you know it's including that class definition file. You know that class definition file contains only one class definition. Neat. Clean. Simple.

5) The server is well-optimized. Is there documentation for optimizing Sugar? Optimization should mean little more than changing settings. If you have to modify the application code to optimize it, you're asking for trouble when you then need to update to the latest version.

6) It breaks on several installs, but I'm sure these are simple bug fixes

7) I won't argue with you on this point. The issue is that the learning curve need not be so steep. Documentation would go a long way to improve this for SugarCRM.

I don't mean to flame... I'd just like to see serious improvement.