[Vtigercrm-developers] Cooperation - part 2

[IT-Solutions4You]

+1 for all points

Losing big partners last years (beacuse of cooperation) which create own 
CRM:
VTE - CRMVILLAGE
VTC - Different Solutions
corebos - tsolucio

D. We didn't have a plan to decode our source but in first versions the 
customers modify it and then the next upgrades was not compatible with 
their modification. So we decide make some easy decoding of PDF Maker 
and another our extensions. But yes it's really important point too.

-- 
S pozdravom / Best regards / Mit freundlichen Grüßen
Ing. Matus SOPKO

IT-Solutions4You s.r.o.
SLOVAKIA
Tel./ Fax +421/ 51/ 7732370
email: sopko at its4you.sk
http://www.its4you.sk/en


Dňa 30. 7. 2014 15:45 Pabiszczak, Błażej  wrote / napísal(a):
> (Infact, i emailed you a month ago to get your feedback but didn't
> receive your reply)
>
>
> I didn’t reply because you don’t understand any of the following issues:
> changing the way of installation, a requirement to attach a credit card
> or the business processes. I will list a few examples so you can
> understand what I’m writing about:
>
>
> A.  Who is responsible for the installation of modules in Vtiger
> software in your company?
>
> In 95% of all cases it is the company that deploys the software (e.g.
> OpenSaaS) and usually different employees are assigned to different
> modules. For example: an employee, who knows how to do it best, will do
> a module for integration with LDAP. Who will do the task depends
> strongly on what needs to be done. That’s how it works in our company.
>
> There are some cases in which users install modules themselves but it is
> very rare. This usually are implementations for small companies from 1
> to 5 people.
>
>
>
> B. Who will make their credit card available to buy amodule?
>
> Neither I, nor an employee will do it. We will not pay with a private
> credit card and we do not have access to company’s credit card so who
> will buy a module? A customer? Will any customer hand over to us
> confidential data of his/her credit card while we are a deployment
> company that has a full access to all information?
>
>
>
> C. Module installation
>
> Before we install anything on the server of our customer, we first
> install it on our testing server, then we upload it to SVN and after
> that we upload it on the server of our customer so they can accept it.
> At the end, we install it on customer’s production server. How can you
> imagine a properly functioning shop in this case?
>
>
>
> D. Module coding
>
> Currently, there is no option of coding a module in such a way that it
> cannot be decoded. What type of coding will you be using? If the one
> that is in PDF Maker, then decoding will take about 5 minutes.
>
> Secondly, as a deployment company, we often have to modify modules (even
> if they were bought at outsourced partners) so how do you imagine a
> modification of such an encrypted module?
>
>
> What is the purpose of such coding? Is it security? Surely, it doesn’t
> secure from piracy because one person can decode a module and publish it
> but I can assure you that it will cause more harm than good.
>
> Vtiger isn’t designed for the use at home, but it is a business
> application. We often send complete modules to other people or companies
> for testing. There are many people on this discussion forum that
> received over 100 modules for testing. We don’t have any problems with
> the dissemination of our modules.
>
>
> E. Access to server
>
> Most of large customers have their Internet connection disabled on their
> server (in firewall) so they cannot download anything from the shop (and
> it will not change!).
>
> F. Lack of access to CLI
>
> Small customers use hosting, usually without the access to CLI
> (console). You can’t even imagine how you‘re making their lives even
> more difficult by applying your bizarre elements.
>
>
> G. Lack of possibility to install from a file
>
> The fact that you planned to remove completely the installation from a
> file is an act of sabotage on the community and a sign of business
> thoughtlessness (obviously you will benefit from it in short-term
> perspective but if you look at it from a long-term perspective, you will
> loose loads of customers and partners).
>
> Obviously, under the pressure, you decided to bring it back (and hide it
> from a user), but this only gives us an overall view on where you are
> heading with your product.
>
> We wrote our first opinions (probably on the same day when the
> information was published) thinking that it was some kind of a joke and
> saying that it is unacceptable. Only when we did put more pressure on
> you, you decided to change your attitude, but it all seemed to be imposed.
>
> Other problems
>
> I could list many more problems and spend a whole night doing it, but my
> time is precious and I’m not going to waste it, because it seems that
> you have already made up your mind anyway.
>
>
> While more remains to be done, I am pleased with the progress we have
> made since January on several aspects
>
> Extensions Store coming soon to make it easy for publishers to
> distribute modules to more users
>
>
> The only thing that you have achieved during all these years is
> discouragement. You have discouraged many partners and haven’t published
> hundreds of modules. You are loosing partners one by one and the effects
> of it are already tremendous
>
>
> Dedicated team in Vtiger, for resolving trac issues.
>
>
> Congratulations on that! Finally someone is going to resolve errors, but
> how many people will do it in fact? 1? 2? It is not a team for sure,
> unless you think that 2 people already form a team.
>
>
> Focus on improving APIs to allow developers to write powerful extensions
>
>
> You are concentrating on something you shouldn’t.
>
>
> Although our company – as one of a few Vtiger providers – integrated
> Vtiger with large software systems such as SAP, Dynamics CRM, SAGE, we
> never ever used your API. In 99% cases we created our own solutions
> based on SOAP, because your solution was able to fulfill only about 10%
> of our needs and requirements.
>
>
> Focus on better Documentation  - New site - community.vtiger.com/help
> <http://community.vtiger.com/help>
>
>
> We appreciate it, but unfortunately, it’s your third attempt to write
> the documentation. It still satisfies only 5% of the actual needs of
> programmers
>
>
> With the new marketplace, our goal is to respond to new submissions,
> within 2 business days. We didn't do a good job on dealing with
> submissions last year, but that will change now.
>
>
> We understand that you are going to create many modules such as “hello
> world” or “world clock” and they will be published within two days, but
> it is impossible to do a professional module in two days. It is fiction
> and has nothing in common with the reality. If you don’t believe, I can
> send you modules, and you can try to publish them in two days.
>
>
> Our average response time for On Demand service is 2 seconds. We measure
> it daily because we take it seriously. Vtiger CRM open source has the
> same code base. We are on a mission to improve the performance to get it
> under 1 second. I know in some cases, such as Reports, Calendar,
> response times are unacceptable when you have over very high number of
> records. We have an On Demand customer for who reports are taking 2
> minutes. We are working on addressing this in the product.
>
>
> An average response time of 2 seconds? It might be possible for the
> cloud because you have clients for 10 users maximum and your servers are
> quite slow. However, it has nothing in common with the reality:
>
> Add 100 users to your cloud and add 100 records per month to every user
> and then do the same for a whole year. Later, try to go to a “Shared
> Calendar” tab and you will understand the problem.
>
>
> In the past 6 months, we have closed 100+ trac issues. 94 of the 170
> issues on 6.0 are closed. More fixes are yet to be committed to SVN.
>
>
> I can add 100 new errors in 5 days time. We stopped adding errors to
> trac. Now, there are only a few people who still continue doing it. If
> you have taken a good care of the community for the past 10 years, then
> the situation would be completely different.
>
> We often asked for software patches and recently we asked for patches to
> the Google Sync module, but unfortunately the bugs have not been fixed
> for the period of 8 months. So, what is the point of submitting them? I
> can understand if it happened once, but we hit the wall each time we
> require to change more than one line of code.
>
>
>
> Summary
>
>
> You have done everything you could to discourage us from continuing our
> dialogue and from your product.
>
>
>
> Z poważaniem / Regards
> Błażej Pabiszczak
> M: +48.884999123
> E: b.pabiszczak at opensaas.pl
> <mailto:b.pabiszczak at opensaas.pl>
>
>
> _______________________________________________
> http://www.vtiger.com/
>