
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p>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?</p>

<ol>

<li>

<p lang="en-US"><strong>About us</strong><br />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. </p>

<p lang="en-US">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.</p>

<p lang="en-US">But this isn't my point …</p>

</li>

<li>

<p lang="en-US"><strong>About our fork [idea]</strong></p>

<p lang="en-US">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.</p>

<p lang="en-US">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.<br /><br />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.</p>

</li>

<li>

<p lang="en-US"><strong>About Vtiger</strong><br />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.</p>

<p lang="en-US">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 :<br />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.</p>

<p lang="en-US">b) determining the development direction of the OS version and what it depends on.</p>

<p lang="en-US">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?</p>

<p lang="en-US">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.</p>

<p lang="en-US">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].</p>

<p lang="en-US">f) to what extent does Vtiger really want to add new functionalities to the OS version?</p>

<p lang="en-US">g) generating prefixes for tables [like Joomla does]<br /><br /></p>

</li>

<li>

<p lang="en-US"><strong>But what is this all about?</strong> <br />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!<br /><br />a) <strong>Vtiger CRM security</strong><br /><br />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. <br />Key aspects:<br />- 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.</p>

<p lang="en-US">- 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!</p>

<p lang="en-US">- 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!</p>

<p lang="en-US">- 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.<br />- 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.</p>

<p lang="en-US">- 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.<br /><br />b) <strong>Modules and components safety</strong> <br /><br />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?<br /><br />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?<br /><br />c) <strong>Development</strong> <br /><br />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.</p>

<p lang="en-US">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.<br /><br />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.</p>

<p lang="en-US">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.</p>

<p lang="en-US">I realize that cooperation is practically no longer possible [for YetiForce, Vtiger, coreBOS], but I think we all lose out because of that. <br /><br />d) <strong>Migration</strong> <br /><br />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:<br /><br />1. We take version A [clean<br />2. We fill version A with data [it's best to have a ready script that always generates the same data]<br />3. We migrate to version B<br />4. We copy the files and the database<br /><br />5. We take version B [clean]<br />6. We fill version B with data [it's best to have a ready script that always generates the same data]<br />7. We copy the files and the database <br /><br />8. We compare the copies from steps 4 and 7 using for example WinMerge or some other tool.<br /><br />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.<br /><br />e)<strong> SVN changes</strong><br /><br />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:</p>

<p><span><br />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 [!?!]<br />2. You use require_once even though, you got the vimport function [http://trac.vtiger.com/cgi-bin/trac.cgi/changeset/14538/]<br />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<br />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]<br />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]<br />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...<br />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]<br />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.<br />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<br />10. Templates can't be installed, the "Invalid File provided for module import! Try Again." error message appears. It's obvious nobody tested it. <br />11. The validation of dangerous extensions doesn't work while installing templates<br /><br />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.</span></p>

<p><span>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?<br /><br />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:<br />https://github.com/YetiForceCompany/YetiForceCRM/commit/ef79e4ecb492f7322448b8ad9ea45a4aa65b8e5c. I'd also add a few things from 4a on code.vtiger.com. </span><span><br /></span></p>

</li>

<li>

<p><span><strong>Summary</strong><br />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.</span></p>

<p><span>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.</span></p>

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

<p><span>Thank you.</span></p>

</li>

</ol>

<div>-- <br />

<div>Z poważaniem / Regards</div>

<div> </div>

<div><strong>Błażej Pabiszczak</strong></div>

<div><em>Chief Executive Officer</em></div>

<div>M: +48.884999123<br />E: <a title="Mail do Błażej Pabiszczak" href="mailto:b.pabiszczak@yetiforce.com">b.pabiszczak@yetiforce.com</a></div>

<p> </p>

</div>

<p> </p>

</body></html>