[Vtigercrm-developers] 2016 thoughts & reflections

Thu Dec 29 12:48:21 GMT 2016

@Błażej,

Hope this game have changes for 2017!
I still believe in Vtiger but I must admit you are right in many aspects.

How can vtiger team justify impossibility of porting some functionalities with the diverge of the on demand version and community version if they just published  vt7 ignoring the old version vt6?
Lets be honest: they had this code (beta vt7) ready years ago, I would say 2 years ago and we spend 2 years asking for some fixes and functionalities (I’m not talking about print templates etc because we have the comercial modules) for nothing.

They introduced multiple layout in vt6.5 and now they removed in vt7

Vt 7 should be developed from vt6 and not as a separate version. This means they don’t care about community suggestions and commits made in vt6.

I know the answer. As Błażej said, vt team doesn’t have time and resources to develop community version.

My honest opinion: I do prefer vt6 with some improvements / missing functionalities instead vt7.

Best Regards.

Manuel

> No dia 28/12/2016, às 10:54, Błażej Pabiszczak <b.pabiszczak at yetiforce.com> escreveu:
> 
> I never thought you would publish Vtiger 7 code :] I must admit that you surprised me.
> 
> I don’t know why but I was certain that people who had developed 6.0 version also worked later on 7.0, in particular, because Vtiger claimed to have about 30 active developers. I reviewed the code from Vtiger 7.0 in detail and I can see that there aren’t too many changes and most of them are related to the interface, new look and feel and a few new functionalities.
> 
> In practical terms, there haven’t been any new changes between 6.1 and 6.5 [maybe just multi-template support] and trac.vtiger.com and code.vtiger.com are still being forgotten/ignored. Therefore, I thought that Vtiger put much effort into Vtiger OnDemand. When I evaluate version 7, I look at it from the perspective of 3 years because only OnDemand version has been developed. If I revised it as changes from version A to version B, I would say changes are alright. However, I revise it from the perspective of 3 years, so changes aren’t satisfactory, especially for me. If I had to estimate the work time for people, I would assess it as 1-2 developers [what about the remaining 28 developers?] who have developed OnDemand version [I don’t count the changes that haven’t been also added to the community version].
> 
> When your human resources for the project development are so limited, you should resort to work or help of others. When I reflect on the development of the community version, I see hundreds of bugs which haven’t been fixed for years, and basic functionalities that don’t work [e.g. migration between versions - nearly every migration pack has errors that weren’t fixed in the subsequent versions]. 
> 
> When you published v7 I saw that all the changes published at code.vtiger.com were completely ignored [as if they never existed], the community’s work has been disregarded, and many great changes won’t be moved to the new version. Many of you, who are happy about the release of v7, should first of all understand that this is a marketing move [first they make you wait for a few months for a new version, then they publish a version that has nothing to do with community, and then you got months of stabilization in front of you]. When I recall the migrating script 5.4 -> 6.0 I get chills and I can already imagine what the migrating script 6.x -> 7.x is going to look like, even though there are just a couple of changes. Because how can you prepare a decent update package when you don’t even use it yourself?
> 
> The new version has been published, but apart from that nothing has changed, because there’s still nobody to update it, all the questions, comments and errors from community still won’t be taken into consideration. The community doesn’t know what to do, so some will wait, some will move on, some are happy with what they got [which means they’ll sell paid modules and the fewer changes the better for them]. For the community members to be able to introduce changes into the system, they’d have to be able to actively communicate with the developers, and this hasn’t changed for years.
> 
> I look at projects from a completely different perspective - the quality of code - which hasn’t improved in the 7.0 release. That's why I’m also disappointed because 6.0 version introduced a lot of changes in quality and it should be continued. Unfortunately, I don’t know why [maybe lead developers resigned] but the quality hasn’t improved since 6.0. However, it doesn’t mean that 6.0 was perfect code-wise but it introduced new quality and if it was continued, then after 3 years there would be some really good code in 7.0. Unfortunately, Vtiger 7 is a blend of 6.0, 5.4 and in some places even older versions such as 5.1, 4.x etc.
> 
> Vtiger has the greatest amount of errors in code [over 42 thousand, including 532 Critical, 4889 Major, 20021 Minor, 17102 Info - https://insight.sensiolabs.com/projects/302bc9b8-5a04-4405-ac50-ba10d2bc953c <https://insight.sensiolabs.com/projects/302bc9b8-5a04-4405-ac50-ba10d2bc953c>] from all the projects I know [Vtiger, coreBOS, SuiteCRM, SugarCRM, EPESI, oroCRM, ODOO, YetiForce], and these errors influence the development, security and transparency. Over 70% code requires refactoring and 7.0 version only generates additional code instead of fixing bugs which sometimes have been in the system for 10 years. I don’t know why Vtiger doens’t follow any standards in designing PHP applications that have been described for example here: http://www.php-fig.org/ <http://www.php-fig.org/>. You may think that it doesn’t matter, but when you aren’t selected for a very large project only because of the low quality of the system, you will understand that if you don’t invest enough energy into the quality, it will influence your business sooner or later.
> 
> What if you stop at one version and just focus on fixing and stabilizing it? Maybe a custom fork whose only purpose would be to deliver a stable version? 
> 
> A great example would be coreBOS, which for almost 3 years [since March 2014] has been concentrating on fixes only. What effect did they achieve? Unfortunately at Github they only got 11 issues, 27 people watching them, and 332 downloads at SourceForge. From the practical point of view, coreBOS is Vtiger 5.4 with hundreds of fixes as far as code formatting is concerned, and some minor changes that don’t impact code quality at all, because this project doesn’t comply to any standards whatsoever, ie. http://www.php-fig.org/ <http://www.php-fig.org/>. It also includes over 35.000 errors [659 Critical, 10050 Major, 8278 Minor, 16594 Info]. Additionally, just like Vtiger, this project requires code refactoring [more than Vtiger does, because Vtiger 6.0 brought many positive changes, which were not included in coreBOS].  
> 
> VTE CRM is the same example as it was forked from 5.2.1 version but they haven’t changed it since then, so all security vulnerabilities are still present. What novelty has this fork introduced, except dividing the community and creating a little monster which won’t be developed? SensioLab 50.000 errors [3300 Critical, 13774 Major, 9386 Minor, 23475 Info]. It introduced some commercial modules… and nothing more. I don’t know how many forks like that have been created but if I haven’t heard about them, they probably weren’t successful. I understand that these companies try to earn money from paid modules but, as a result, customers receive a worse product without any perspectives for the development and on a low degree of security. I’m trying to understand why Vtiger pushes us away and those, who can develop a modern CRM system, build semi-finished products that have no perspective for the highest possible development level.
> 
> Creating a product that keeps evolving requires a team of programmers who develop their coding skills on a daily basis, a team that grows together and has adequate financial resources to be able to keep going on, regardless of the number of clients in the first years. If you think you can take Vtiger 7 and start developing it independently, then you will most likely not be capable of dealing with the burden of development and responsibility, because it requires looking at it from the perspective of several years, not just from a one month perspective.
> 
> Currently, a few systems are developed very dynamically [especially commercial systems] because they have enough financial resources. These systems are Base, SalesForce, Dynamics, SugarCRM… Do you consider where you are going to be in 2, 3, or 5 years time if Vitiger’s community is already so divided, there are hardly any financial resources and no one takes care of the quality and security? Last 6 months I have been negotiating with 2 very large companies that want to deploy a CRM system on a large scale. Do you know what are their opinions about open source? In order for us to take part in the procedures, they had to conduct functional, performance and security tests. We had to make a lot on changes in the engine over many weeks, so that we wouldn’t be ashamed and our system could pass the tests.
> 
> I understand that the current situation is very satisfying to 2-3 companies that sell Vtiger modules...and they won’t be too keen on accepting changes, because the more flawed the system is, the easier it gets to sell some tiny feature for 100€. However, in my opinion, this attitude is not only harmful to the Vtiger community, but to the entire open source community.
> 
> I’m no longer as active here as I used to be, and I guess this is how it’s going to be, and it’s due to the fact that Vtiger doesn’t have much to offer anymore. I wish I was wrong, and I wish you could surprise me in 2017.
> 
> -- 
> Z poważaniem / Regards
>  
> Błażej Pabiszczak
> Chief Executive Officer
> M: +48.884999123
> E: b.pabiszczak at yetiforce.com <mailto:b.pabiszczak at yetiforce.com>_______________________________________________
> http://www.vtiger.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20161229/6c16cb12/attachment.html>