[Vtigercrm-developers] Don Quixote – final reflections

Błażej Pabiszczak b.pabiszczak at yetiforce.com
Fri Oct 23 12:26:24 GMT 2015


 

My posts are always controversial and it won't be any different this
time. My long-time "fans" will definitely feel appreciated, and I'm
happy I'll get to smile reading their posts again. Generally it's a
quite negative post, don't read if you don't want to, why should you get
upset? 

	* 

ABOUT US
I've personally known the Vtiger system for 8 years, our previous
company - OpenSaaS began offering solutions for Vtiger in 2011 [polish
versions, modules] and we also had a Polish forum on vtiger. We oriented
our development towards Vtiger partnership. There are many companies
that don't return what they took, we were always different. We provided
free language packs, some modules, support, ready solutions [we also had
commercial solutions]. At the same time we ensured that the system
worked properly by reporting hundreds of bugs. 

Although we were just small company with a tight budget and we just had
started learning, in my opinion we significantly helped the open source
community [as much as we could]. A year ago we decided to set up our own
fork, and, as some of you might remember, it was caused primarily by
Vtiger's lack of cooperation, as well as not uploading fixes to the
system. As a result of that we couldn't develop due to too many
limitations. 

But this isn't my point … 
	* 

ABOUT OUR FORK [IDEA] 

I don't intend to advertise our solutions in here, there are better
ways, I would like to focus on the idea of cooperation itself. If I were
interested in marketing, I'd advertise using all the means possible
[mailing list, forum, direct e-mails] and in the vtiger related topics
on linkedin. I don't do that, because that's not my goal. 

I thought that to some extent Vtiger and YetiForce will be able to
complement each other [similar concept, common goals], maybe it could
even be possible to merge other projects, ie. CoreBOS, because all of
these solutions are based on the same engine ... Because who needs
another fork? A large part of the functionalities is similar.

I even thought that once "competition" pops up, Vtiger would change
their approach for everybody's benefit, even ours. Ours- because we
didn't really abandon Vtiger, we keep adding changes that are common to
both projects. I naively thought that if we had combined a number of
projects, ie. Vtiger, YetiForce, coreBOS we could've been able to create
real competition for solutions like Salesforce or Microsoft Dynamics.
Now I know that waiting for others and exchanging experience only slows
us down, particularly because these actions are one-sided. 
	* 

ABOUT VTIGER
It isn't my purpose to defame Vtiger as a company, in my opinion they
chose their course of development and it's none of my business. I also
appreciate everything they gave to the open source community, because
they gave a lot. 

I think that Vtiger should be honest with their community [whether you
want it or not - we are a part of it too], since the direction they
chose will sooner or later affect everyone on the mailing list. What I
consider important for the community :
a) defining the role Vtiger wants to play for the open source version
for the upcoming years - little involvement in the OS project indicates
doing what SugarCRM did, which is abandoning the OS version. 

b) determining the development direction of the OS version and what it
depends on. 

c) what real impact can the community have on the OS version
development? Will the attitude or cooperation policy change after
publishing code.vtiger.com? 

d) to what extent does Vtiger really want to develop the OS version to
be compatible with the HTML5, CSS3, PHP standards, and additionally
OWASP, W3C, WCAG, PAS. 

e) to what extent does Vtiger really want to increase the OS version's
security level [the current one is unacceptable for any larger company
or organization]. 

f) to what extent does Vtiger really want to add new functionalities to
the OS version? 

g) generating prefixes for tables [like Joomla does]

	* 

BUT WHAT IS THIS ALL ABOUT? 
To make it completely clear - the issues below apply also to our fork,
it's not my purpose to show we have a flawless system, my goal is to
show what we have some common problems that need to be addressed
together, because they also apply to our solution!

a) VTIGER CRM SECURITY

If someone considers Vtiger secure - the person is completely wrong.
Over the last 5 years we've reported to Vtiger many security issues.
Some of them are still in the system, part of them was removed after a
few years. What's certain is that many new ones appear. Due to the fact
that Vtiger ignored our emails, we stopped reporting them, but they
still exist. 
Key aspects:
- Turn off all the functionalities for external communication by default
- ie. webservice, customer portal, mobile, etc. It is a basic principle
of safety, first turn off all of them and then turn on only those
elements that we need. 

- Remove the monstrosity called modules/Mobile which is enabled by
default. This module is full of holes and it should be removed , or
written from scratch! 

- The new code that you release should be verified by the best
programmer in the company! Currently, the new code contains a lot of
logical and safety errors! 

- Security audits should be scheduled, if Vtiger has no funding for
that, then some fund raising should take place, for example using
kickstarter or community collection, like Wikipedia does.
- I don't know who, when and why came up with the idea to combine the
Administrator's interface with the User's interface, but it is one of
the main design errors, it significantly reduces the system's security
level. 

- Implementation of the OWASP policy - Currently, after installing the
system, you don't know absolutely anything about what is happening in
your system, you have no security logs, you don't record any important
information. You have no control over this system, and it's only a
matter of time when it negatively affects a company that has implemented
the system, and customers who use it.

b) MODULES AND COMPONENTS SAFETY 

The modules and components safety level is very low. A few months ago we
showed you the problem with vtDebug which contained many security flaws.
Also, a few months ago we wrote to the MYC portal creators, they have a
lot of critical errors in the customer portal - as long as I've been
watching their github account they haven't fixed these errors. We access
various systems practically every week, they include many different
modules; we look through them with curiosity, and I got to tell you that
what we see is wrong. If Vtiger doesn't fix errors, if the module
creator doesn't fix errors, then to whom and why should we report them?

When we created modules a few years ago, we made the same mistakes; they
resulted from both - programmers who just started learning, and the lack
of the producer's support, who published modules that contained errors
and didn't manage to notice them[it was enough that the module worked
somehow]. Why during these 12 years nobody managed to develop good
practices, standards, and documentation that could to help new
businesses? Why aren't the changes published in SVN not verified in
terms of security?

c) DEVELOPMENT 

Currently Vtiger is not developing, it's standing still. The amount of
code that Vtiger released over the last 12 months can be summarized as
"one man's half-time work". In addition to that, recent changes show
that people who have started adding improvements to the system are still
learning. Excluding the community and partners from the development will
impact everyone in a negative way. 

Even though standards were not that essential a few years ago, they are
currently crucial while designing any system. Every change in the system
should move towards standardization, ie.W3C, PHP 6, PAS, WCAG. For
example, every government application in the EU must support the WCAG
standards.

This market is very competitive, so it's important that Vtiger is honest
with us, and sincerely describes its plans and intentions. Clear
objectives and priorities should be defined, so that each company could
know how to build their future with Vtiger - we want to know that as
well. 

It would be better for us if Vtiger stopped developing, we'd gain more
customers, but in the long run nobody - including us - would benefit
from that; because our product would be much better if it were created
together. Therefore, I believe that cooperation can bring more benefits
and I still try to cooperate, but with less and less enthusiasm. 

I realize that cooperation is practically no longer possible [for
YetiForce, Vtiger, coreBOS], but I think we all lose out because of
that. 

d) MIGRATION 

What Vtiger does in migrating scripts since beginning of the project is
amazing for me. These scripts contain so many errors that you could
write a book about it. What Alan published is just the tip of the
iceberg. I can't understand why you can't implement good practices or
standards for migration from one version to another. The verification of
the migration process is very simple:

1. We take version A [clean
2. We fill version A with data [it's best to have a ready script that
always generates the same data]
3. We migrate to version B
4. We copy the files and the database

5. We take version B [clean]
6. We fill version B with data [it's best to have a ready script that
always generates the same data]
7. We copy the files and the database 

8. We compare the copies from steps 4 and 7 using for example WinMerge
or some other tool.

I'm not talking about a few mistakes, there are hundreds of errors, and
the number keeps increasing, and they aren't fixed. Therefore something
should be done about it, something like developing standards and
sticking to them. If someone doesn't believe me, I can send you our
fixed migrating scripts that we use internally. You can also check the
code on GitHub and compare the original code to our code, we simply do
not have anymore energy to report this to vtiger, since nobody is going
to take care of it anyway.

e) SVN CHANGES

Creating our fork, we decided to use Vtiger's energy and apart from
introducing our own changes, we also included changes sent by the
Vtiger's community and the developer himself. That is why we update our
engine to the current Vtiger version from time to time, [for example we
implemented the changes to Vtiger rev. 14548 (6.4.0)]. Unfortunately,
fewer and fewer changes are suitable to use, a few general observations:


1. The variables aren't cleared properly
[http://trac.vtiger.com/cgi-bin/trac.cgi/changeset/14540/], the
getRequestSmartyParam function that gets data directly from $_REQUEST
[!?!]
2. You use require_once even though, you got the vimport function
[http://trac.vtiger.com/cgi-bin/trac.cgi/changeset/14538/]
3. Code written on a napkin, not thought through
[http://trac.vtiger.com/cgi-bin/trac.cgi/changeset?reponame=&new=14538%40vtigercrm%2Fbranches%2F6.4.0&old=14537%40vtigercrm%2Fbranches%2F6.4.0]
and it's enough to use strtolower just once
4. You use outdated mime_content_type functions
[http://trac.vtiger.com/cgi-bin/trac.cgi/changeset?reponame=&new=14525%40vtigercrm%2Fbranches%2F6.4.0&old=14524%40vtigercrm%2Fbranches%2F6.4.0]
5. You write low quality code
[http://trac.vtiger.com/cgi-bin/trac.cgi/changeset?reponame=&new=14524%40vtigercrm%2Fbranches%2F6.4.0&old=14523%40vtigercrm%2Fbranches%2F6.4.0]
6. You fail to comply with the PSR standards [you use spaces and tabs
interchangeably] :/, it must be a nightmare for a programmer who makes
migrating scripts...
7. You use global variables even though you have a special function for
that
[http://trac.vtiger.com/cgi-bin/trac.cgi/changeset?reponame=&new=14507%40vtigercrm%2Fbranches%2F6.4.0&old=14506%40vtigercrm%2Fbranches%2F6.4.0]
8. You increase the script execution time indefinitely
[http://trac.vtiger.com/cgi-bin/trac.cgi/changeset?reponame=&new=14506%40vtigercrm%2Fbranches%2F6.4.0&old=14503%40vtigercrm%2Fbranches%2F6.4.0]
despite the fact that in other places some mechanisms depend on that
time [eg. workflows], plus it's not secure.
9. You added multiple Layout support and there are references to the
"vtiger_layout" table which doesn't exist by default. It's created
during the template installation or removal. It's enough to go to the
"Configuration Editor" and the " Table 'vtiger_layout' doesn't exist"
error will pop up
10. Templates can't be installed, the "Invalid File provided for module
import! Try Again." error message appears. It's obvious nobody tested
it. 
11. The validation of dangerous extensions doesn't work while installing
templates

These are comments concerning several revisions; from the 1 year
perspective, the number of problems you generate for yourself is huge.
It's a bad practice not to verify the code prior to its publication, it
may happen in case of a new project, but Vtiger has been around for
several years and has been downloaded several million times. 

Is this what the OS version is supposed to look like? Do you think that
the users can't see that? That this has no real impact on how others see
your product? Or can't you see the problems that multiply this way?

I'm not a programmer, but it seems to me that the described in point 1
is a serious security flaw [I could be wrong]. I'm not vain either,
we're not looking forward to what Vtiger answers, each of these issues
has been fixed and implemented into our system, whether or not someone
uses our solution depends solely on you. If I were you, I'd add these 8
points on code.vtiger.com, ready-made solution can be found here:
https://github.com/YetiForceCompany/YetiForceCRM/commit/ef79e4ecb492f7322448b8ad9ea45a4aa65b8e5c.
I'd also add a few things from 4a on code.vtiger.com. 

	* 

SUMMARY
Vtiger will cope without YetiForce and YetiForce will cope without
vtiger, that's obvious. However, we should remember that we have some
common problems and we can't escape that. A few hecklers, who don't
bring anything substantive to the discussion, will most likely come
here, but even if I'm not completely right, I'm sure you'll notice the
problems that have to be dealt with. 

YetiForce cuts off from the Vtiger community, we will still observe,
upload suggested fixes, analyze reported problems, but we don't see the
possibility of dialogue, cooperation, and partnership. In my opinion
both parties have a lot to offer. 

If some substantive discussion starts I can engage in the dialogue,
otherwise we should focus on our own goals and community objectives. 

Thank you. 

-- 

Z poważaniem / Regards 

BŁAŻEJ PABISZCZAK 
_Chief Executive Officer_ 
M: +48.884999123
E: b.pabiszczak at yetiforce.com 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20151023/e9a310e3/attachment-0001.html>


More information about the vtigercrm-developers mailing list