Will SuiteCrm always be a a fork of SugarCrm?

SuiteCRM Forum - English Language Developer Collaboration
1

Hi,

I have found quite a lot of technical information on the forum but very little indication about the future of this project.
I have contributed to the code base of SuiteCrm these couple of months but my feeling is that you guys working really hard on issues and PRs are going in a circle. That is, you are fixing the infinite number of holes/bugs on a project that is NOT maintained at all(https://github.com/sugarcrm/sugarcrm_dev/commits/master) but at the same time you are not redesigning anything because it would make SuiteCrm incompatible with SugarCrm.
So my question is: seeing that between 5 Aug 2015 and 9 March 2016 the only commit on the upstream fork was to remove a license.txt and update sugar version info, will this project always stick to be a fork of SugarCrm or will it at one point be a project of its own and be free to implement new technology available to us today?

a\

2 Likes
2

This is only my personal opinion: At some point we will add features that will more than likely break compatibility with Sugar CE.

1 Like
3

The advantages of breaking compatibility is the freedom to do whatever we want in the future.

On the other hand, what are the advantages of keeping compatibility?

  1. Making life simpler for add-on developers, who can write once and run both on Suite and Sugar

  2. Making use of the documentation out there, written for Sugar

  3. Smoother upgrade path from Sugar into Suite

  4. …?

Can anybody list more reasons? Right now, the reasons I came up with, definitely seem important enough to justify keeping compatibility. I wonder how long the strength of these reasons will last…

1 Like
4

@andy - Well, I just did. I have a PR in queue which is a console installer (using symfony/console and monolog/monolog) which, on its own is not breaking the compatibility with Sugar, but to finish the job the web installer should be completely rewritten to use this console installer code base.
To do that, the entire project should use the composer autoloader (well, not really but unless we want to include the vendor folder into the project [which would be just silly], it should).
So, to do that the SuiteCRM project should become a composer project… and we would have easy access / update facility to a wealth of good and solid code around.
Wouldn’t it be nice to be able to:

composer create-project salesagility/suitecrm && cd suitecrm && ./console app:install --database-host=localhost --database-name=suiteCRM ...

and when you want to update the project:

composer update

I’d love that. Obviously, this would completely break SugarCRM compatibility.

The question is: What would we loose out on by doing this? I’d say nothing. Probably the next commit on SugarCRM CE will be around 2020 where we will get another version info update.

The other question is: What would we gain from this? Well, the list is long: PSR-0 PSR-4 autoloading, access to ~95K HQ packages such as swiftmailer, ORM, DBAL, monolog(which in turn would mean stipping out ancient code from our codebase for which we have more advanced [and better tested] alternatives === which means less work), easy install, update, ecc.

This is my personal opinion :wink:

2 Likes
5

@pgr - I cannot add anything to your list. As a matter of fact, I’d question even the ones you listed.

True but at what a price!? I am a php developer from day one - I customize and make add-ons for a variety of projects and I can tell you I have cold sweat when it comes to SugarCRM. The concept of vardefs and logic_hooks are ancient and php4-like - the extensive usage of $GLOBALS (like $current_user and $GLOBALS[‘log’]…) makes things in an advanced code editors like phpStorm impossible to track (and therefore no method suggestions and tons of warnings), the improper static calls to non-static methods, the numerous functions thrown into the application without a class, the missing (or even worse badly written Docblock comments) on methods, the modified smarty templating engine plays bad tricks on your brain, the fact that the custom folder is a mix of custom code and cached(autogenerated) files - there is nothing simple about writing code for sugar…so one looks for documentation…

Documentation is to support code and not the other way around. If we refrain from introducing code changes because we don’t want to rewrite documentation than this project will soon be dead. Furthermore, the documentation you can find out there is extremely fragmented and is a collection of examples of how to write arrays. Have you ever tried to make modifications to the history subpanel? I did yesterday … ALL OF YESTERDAY! to add two columns and to remove another two. I consulted around 30 blog posts all around the web all saying things without version reference whilst the official SugarCRM documentation was of no use - it is a mess.

Well, if we don’t support Sugar we don’t upgrade from Sugar. But we can make a rock solid importer bundle to do that for us.

I don’t think any of the above reasons should be a stopper. On the other hand, the ‘freedom to do whatever we want’ side - to which I don’t think you gave much consideration - should be a puller. Let’s imagine how we would like SuiteCRM to be and let’s make it that way!

1 Like
6

I appreciate your reasoning, and I never said that I stood behind those reasons I listed… I just listed them!

The way I see it, it’s a matter of time: as time passes, the “pull” of freedom from SugarCRM will increase; and the force of the reasons in my list will diminish. Eventually we will come to a tipping point.

But I don’t think that time is now; it would be a mistake to try and do it too soon. Initially, the strength of SuiteCRM was precisely the name SugarCRM, the dozens of available add-ons, and yes!, the lousy documentation of dozens of incoherent blog posts, which are still far better than no documentation at all!

Let’s just hope this project moves fast, we might not have to wait that long… : - )

1 Like
7

and I do appreciate yours!
And I agree with you that we will eventually come to a tipping point - what I think you and me see differently is when. I would agree that we already have.

Yes, I do realize that but I think SuiteCRM has made itself a name by now because this project is ALIVE and responds to developers/users. The one you forked out from has 15 closed issues, and 36 open ones and if you sort them by date you’ll find unanswered issues from Dec 21, 2012 onward - for me it means DEAD.

In my opinion, to get detached from Sugar is not just about freedom but more about doing things correctly, better and looking ahead.

Why do you think it could be a mistake to try and do it too soon? What negative effects could it produce?

thanks @pgr

8

Well, there are many degrees of “breaking compatibility”. If you change things that don’t break currently developed add-ons, then that is more acceptable, sooner.

But if you do something that puts us in a position of asking all 30 or 40 add-on developers to change their code for us, you will find out some are gone, some won’t bother, some will, some will take too long, etc.

For example, the change you proposed, it won’t have any effect on add-ons, or will it?

So I suppose the first things that break compatibility will be carefully selected to deliver advantages while keeping, say, 95% of the relevant compatibility. It’s a path of progressive, predictable, deprecation (every project does that anyway, as it moves through versions).

9

The short answer is that “No, it won’t always be a fork of SugarCRM”.

There were three strategic imperatives when we forked:

  1. To prove to the market that we were an open source company, not another version of SugarCRM who would eventually monetise and put code behind proprietary licenses. I think we have managed to establish that.

  2. To offer a migration path to the millions of SugarCRM users globally once Community Edition was truly dead. The second part of this condition is not true yet.

There are probably hundreds of thousands of instances of SugarCRM across the globe who will need a home in the next 12-18 months. We need to give them one. We need to make it easy for users to migrate and find a home for the future. SugarCRM Community Edition is now dying. With the release of 7.7, CE is in the last 12 months of support.

So, yes we will break. Yes we will forge our own identity. No we will not be constrained by SugarCRM’s architecture.

It’s a matter of when, not if.

And of course - we absolutely must bring our community with us on the journey.

1 Like
10

Thanks - I have to admit I was basing all my considerations on improving code quality and I did not think about the ‘hundreds of thousands of instances of SugarCRM across the globe who will need a home’. It must be because I am a developer and just do things without questioning if something is possible or not.
And you’re right, if we do not provide a migration path for those users who currently use SuiteCRM/SugarCRM CE - we will lose them - something we do not want to do because SuiteCRM exists because there are people who use it, otherwise the entire project would be pointless.

But still, I think there is, at the end of the day, two ways of going about to do this.

A > start from current code base and work our ways up towards a solid application

B > rethink everything, start from scratch, build a HQ application and provide a solid migration tool (and service to rewrite custom code)

I think you are currently thinking about A) - as far as I can tell from the roadmap with the 7.7 LTS by July we will have completed Bug Blitz & Code Clean Up. Well, just yesterday I made a PR on the devel branch which produces the following results:

In short, there are:
Critical Issues: 18
Major Issues: 745
Minor Issues: 2108
to be resolved and our test coverage is 7%(extremely low!).

IMHO, the effort to be put into resolving the Critical and Major issues and to bring test coverage to an acceptable 50% (without which a project of this size cannot be correctly managed[meaning: when i merge something do I know if I am breaking something?] is comparable to B.

Also, the fact is that if we want to keep compatibility to whatever custom code users might have put into their custom folder we will never be able to change certain things because they are dependent on how Sugar/Suite works today. But, if you look at them, the majority of custom code (vardefs, layoutdefs, viewdefs, mod_strings) are trivial array codes (not all of them: logic_hooks and probably other stuff)

So, we are all saying ‘when time comes we will do it’, but when it will come to it how will we do it?

My point is: Either way, sooner or later, A or B, we will have to create a Migration Module of some sort that will help users to migrate to our new ‘non-sugar-compatible’ release, don’t you think?

I don’t know, maybe I am not explaining myself too well. When I speak about solid php application I see HttpKernel, Services, Dependency Injection, Routing, Asstet Manager(js/css/less), Twig templating Engine, Event Dispatcher, Console - and yes you’ll say you are listing all components of a Symfony application. True, I am. But you know what? All this stuff is already available, thoroughly tested and widely used and when you base your application on them you “only” have to write the connecting logic…(Ooops, I forgot to mention: Doctrine, ORM, DBAL!!!) This is why before, when I was saying the effort needed to do A and B are comparable, becuase the B way (using composer and these components) we’d have the most complex and boring parts already build and external to our code and we could concentrate to make modules(bundles) which is basically what users see and use and through which they identify SuiteCRM.

Is that something you’d take into consideration?

11

Thanks @jakabadambalazs2 for bringing up this excellent topic.
I found this thread while searching for Doctrine DBAL and SugarCRM !

The compatibility question is super important.

I have to say that the push to update the architecture of the app and the libraries used by the app is noble and should increase efficiency of development and maintenance substantially.

Updates can, and really should, be done in a way that maintains compatibility with existing 6.5 add-ons.

in fact, it’s possible to support both the Sugar 6.5 API and the Sugar 7.x API.

Did you know, Sugar 7.x uses all of these Symfony components you mention - Doctrine DBAL, Composer, etc. So it doesn’t necessarily break anything to add these to SuiteCRM in a way that is compatible with both Sugar 6.5 and 7.x. Composer doesn’t prevent an add-on module from installing or running using the old Sugar 6.5 API, for example.

The best way to go about this, is to visualize this app as two separate pieces. The Front End, and the Back End.

SuiteCRM can and should be updated to support both Sugar 6.5’s REST v4.1 Back End, and Sugar 7.x’s REST v10 Back End.

From that point, you’re golden. All Sugar 7.x add-ons connect only through the REST v10 Back End, and will work.

As far as the front end goes, this is where most of the undesirable junk is. Repeated code, modified Smarty engine, view code that tries to build SQL queries, etc.

All in favor of creating new front end web user interface, compatible with existing 6.5 and 7.x, using new front end frameworks such as responsive CSS3 and not having any access to do things like build SQL queries, and because it talks only to the REST API, also causes no breakage of compatibility.

In summary, SuiteCRM needs to continue to safely debug 6.5, introduce composer, phpunit, dbunit and other helpful packages, and refactor the underlying poor design of SugarCRM 6.5, all the time maintaining compatibility with modules and the entire SugarCRM 6.5 API, essentialy making the app perfect. It’ll then become more and more easy to see the forest for the trees, get up to 80% test coverage, build a universal responsive mobile/desktop theme and views that are truly pure views and not mucking around deep in the data layer. At this point it becomes simple to add the REST v10 API for total Sugar 7.x compatibility, which allows for the user base to grow and welcome users who rather not be paying the high fees for commercial CRM software.

First however is getting test coverage up. For this, it’s essential to add composer, all the phpunit tests from Sugar 6.5, and activate all of the testing tools used by Sugar 7.x (and pretty much every open source app on github). Jasmine, PHP-cs-checker, PHPCS, there’s a list of about 8 of them I posted on the relevant github issue. These would run tests and allow you to test see whether a change you propose would break compatibility. And then change your code so compatibility is maintained.

1 Like
12

Chris, what is missing in order to integrate the SugarCRM 6.5 tests? Have you tried it in your forked repo?

That seems to me a measure that would quickly bring many benefits, we would be taking advantage of many hours of work already done, but frankly I don’t really understand the technical challenges of this integration.

13

The SugarCRM 6.5 tests run with little to no modification. https://github.com/sugarcrm/sugarcrm_dev/blob/master/tests

The tests are being added now: https://github.com/salesagility/SuiteCRM/pull/3600

1 Like