[Vtigercrm-developers] Cooperation

Thu Feb 7 20:36:37 PST 2013

> You might want to update your wikipedia page then  -
> http://en.wikipedia.org/wiki/Vtiger_CRM
>
> *"vtiger CRM is an open source CRM application that was forked from
> SugarCRM with the intention of being a fully open source CRM application
> with comparable functionality to SugarCRM and Salesforce.com"*

If i could edit it, it would say "Vtiger CRM carries the most liberal open
license and offers features arguably superior to leading commercial
alternatives, including Salesforce.com"  :-)

*The License*

MPL vs GPL - Vtiger CRM license is based on the MPL license that is the
most liberal of the open source licenses giving users the power to modify,
sell, and the ability to build proprietary applications on it, if they
want. GPL on the other hand carries many restrictions.

*Functionality*

Vendors, Products, Services, Invoices, Pricebooks, Projects, Assets,
Service Contracts - Many of these modules do not exist in SugarCRM or
Salesfore.com.

Regards,
Sreenivas

--
Sreenivas Kanumuru
vtiger Team

Direct: +91 96323-55656
Skype: skanumuru

*Connect with us on: *Twitter <http://twitter.com/#%21/vtigercrm> *I*
Facebook <http://www.facebook.com/pages/vtiger/226866697333578?sk=wall> *I*
Blog <http://blog.vtiger.com/>* I*
Wiki<http://wiki.vtiger.com/index.php/Main_Page>
 *I *Forums  <http://forums.vtiger.com/>*I* Website <http://vtiger.com/>

On Fri, Feb 8, 2013 at 1:39 AM, Adam Heinz <amh at metricwise.net> wrote:

> You might want to update your wikipedia page then
>
> http://en.wikipedia.org/wiki/Vtiger_CRM
>
> "vtiger CRM is an open source CRM application that was forked from
> SugarCRM with the intention of being a fully open source CRM application
> with comparable functionality to SugarCRM and Salesforce.com"
>
>
> On Thu, Feb 7, 2013 at 3:01 PM, Sreenivas Kanumuru <svk at vtiger.com> wrote:
>
>> Christian,
>>
>> Vtiger is a for-profit business. Our mission is to empower businesses
>> through affordable technology solutions. Vtiger CRM open source version
>> originated from this mission. It is also a key driver of our business.
>> Hence, it is critical for us to retain freedom in deciding the roadmap.  We
>> are  thankful for the community contributions (testing, development, ideas)
>> that go back to make the open source version better. We are working on
>> improving the collaboration in the coming months.
>>
>> Regards,
>> Sreenivas
>>
>>
>> On Thu, Feb 7, 2013 at 2:53 PM, Koch, Christian <christian.koch at 4com.de>wrote:
>>
>>>  Hi,****
>>>
>>> ** **
>>>
>>> I agree, it’s a systemic problem. But the bugtracking is only part of
>>> the problem. Vtiger of course is open-source – but it’s not a community
>>> project. Perhaps I’m wrong, but I believe only vtiger employees have write
>>> access to the source code. Why don’t you give some “special” community
>>> members also the right to review patches and integrate them? “Community”
>>> means, that members with enough reputation get the right to decide more!
>>> Today when you have the “not enough time”-problem you have to hire new
>>> employees. But I’m sure there are many people out there who would like to
>>> help you for free – you just ignore them!****
>>>
>>> Today vtiger is a company releasing its own software as open source when
>>> it’s finished. But it does not respect the original open-source-idea of
>>> working together as a community to make things better! If you solved that
>>> problem, vtiger could be developed much faster and quality would get better!
>>> ****
>>>
>>> ** **
>>>
>>> Regards,****
>>>
>>> Christian****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *Von:* vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:
>>> vtigercrm-developers-bounces at lists.vtigercrm.com] *Im Auftrag von *Sreenivas
>>> Kanumuru
>>> *Gesendet:* Donnerstag, 7. Februar 2013 06:41
>>>
>>> *An:* vtigercrm-developers at lists.vtigercrm.com
>>> *Betreff:* Re: [Vtigercrm-developers] Cooperation****
>>>
>>> ** **
>>>
>>> Adam,****
>>>
>>> ** **
>>>
>>> You are right. it is a systemic problem across many open source
>>> projects. We strive to do better. We have more resources in the core team
>>> now. Our QA team is actively reviewing the bugs submitted here<http://trac.vtiger.com/cgi-bin/trac.cgi/report/37>.
>>> Before the Vtiger 6 final code is released, we will be going through all
>>> the Vtiger 6 patch submissions. ****
>>>
>>> ** **
>>>
>>> thanks,****
>>>
>>> Sreenivas****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>>
>>> ****
>>>
>>> --
>>> Sreenivas Kanumuru
>>> vtiger Team****
>>>
>>> ** **
>>>
>>> Direct: +91 96323-55656
>>> Skype: skanumuru****
>>>
>>>
>>> *Connect with us on: *Twitter <http://twitter.com/#%21/vtigercrm> *I*
>>> Facebook <http://www.facebook.com/pages/vtiger/226866697333578?sk=wall>
>>> *I* Blog <http://blog.vtiger.com/>* I* Wiki<http://wiki.vtiger.com/index.php/Main_Page>
>>>  *I *Forums  <http://forums.vtiger.com/>*I* Website <http://vtiger.com/>
>>> ****
>>>
>>> ** **
>>>
>>> On Thu, Feb 7, 2013 at 1:24 AM, Adam Heinz <amh at metricwise.net> wrote:**
>>> **
>>>
>>> ** **
>>>
>>> On Wed, Feb 6, 2013 at 2:13 PM, Sreenivas Kanumuru <svk at vtiger.com>
>>> wrote:****
>>>
>>> We try to integrate as many patches as possible. 5.3 and 5.4 versions
>>> included some patches that we received from community members. But, i agree
>>> that we did not get back to all the developers who submitted patches. We
>>> did not have sufficient time to monitor and close lower priority issues.
>>> ****
>>>
>>> ** **
>>>
>>> I think this is a systemic problem.  I'm a big believer that a bug
>>> tracking system is a general indicator of the overall health of a
>>> development team.  Generally speaking, I lean towards agile software
>>> development, so my personal litmus tests reflect that:****
>>>
>>> ** **
>>>
>>> 1. There should be no open bugs in old milestones.  They should either
>>> be fixed by development and verified by QA, or they should be moved forward
>>> by project management.  If possible, old milestones should be locked so
>>> that new bugs can't be entered against them.****
>>>
>>> 2. New bugs coming in should be assigned to either the current hotfix
>>> branch, the current development branch, the subsequent development branch,
>>> or the heap.  When a development branch closes, the heap is reviewed,
>>> pulling bugs into the development branch, potentially as WONTFIX, INVALID
>>> or WORKSFORME.****
>>>
>>> ** **
>>>
>>> There is nothing wrong with reviewing open source contributions and
>>> throwing them out.  You can use a low level QA person to triage bugs as not
>>> reproducible.  Nobody is going to get offended if a junior member of your
>>> team starts a dialogue with them, asking for help to reproduce a bug.  That
>>> said, I find it insulting that you claim not to have the few minutes it
>>> takes to review what may have taken a developer hours or days to build.  It
>>> takes a lot less time to review a bug than it does to fix it.  When I
>>> manage other developers, I mostly get the hell out of their way, keep their
>>> slop bucket full of bugs, and review EVERY SINGLE LINE OF CODE THEY SUBMIT.
>>>  It takes me no more than thirty minutes to review an entire eight hour day
>>> of another developer's work and svn merge the change from their development
>>> branch into a testing branch.****
>>>
>>> ** **
>>>
>>>
>>> _______________________________________________
>>> http://www.vtiger.com/****
>>>
>>> ** **
>>>
>>> _______________________________________________
>>> http://www.vtiger.com/
>>>
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>
>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20130208/b2527f97/attachment-0001.html 