[Vtigercrm-developers] Community help needed

[Dennis Grant]

 >c) We need information on who all have done integration with any accounting> softwares out there as it seems to be the most commonly asked query

Some sort of integration between vtiger and Microsoft Great Plains (aka Dynamics) is on my list of requirements.
 >d) Make the product smaller in size still. I feel, the product is even now 
> too big. 

I don't see the value here.... The size isn't currently a problem, and there are bugs to fix and features to add.

>e) Language packs. We are running in circles with this issue. 
> We have tested and tested and still not able 
> to reach a point where we can rest relaxed. We need help in this. 

More to the point, vtiger needs to support per-user localization. I need to be able to have the interface present Japanese to the Japan office, German to the German office, etc etc **while still pointing to the same core database** Jens' work on multiple sales offices is the start of this.

>k) More information needed on where all vtiger lacks so that we can start 
> working on those areas

You can start by making it easier for those of us with custom code forks to merge our improvements back into the core. There has been some movement in this area (I noticed that some of my patches made it into 5.0GA) but we still don't have a good process for getting patches into core. I keep getting conflicting answers on what the process is, and movement on some fronts (I still don't have a Trac ID) has been slow.

>p) Achieve twice the popularity by the end of this calendar year. 
>vtiger needs to spread virally to all the corners of the world. 
> Tell me what can we do to achieve this. I have been spending sleepless
> nights for far too long on this.

It's a total non-issue. It's not important. The better the product is, the more people will use it. Word of mouth is your best friend - look at Linux
In my experienced opinion, the reason why Linux has been so successful is that Linus has been very good at establishing working development practices that let anybody hack on the kernel and see their improvements make it back into the core on a very short timeframe - assuming they meet his non-trivial quality requirements. The easier you make it for community members to add functionality to the core, the more people will work on the core, the better the product gets, and the more end users use the product.

It's a positive feedback loop that brings nothing but Sweet Crunchy Goodness.

Here are my suggestions:

1) Adopt this mailing list as THE SINGLE LOCATION for vtiger developers to discuss the code. Shut down the corner of the forums for developers. Shut down any place other than this list for users to talk to developers about bugs. Effectively, make this list the vtiger equivalent to linux-kernel. That's not to say that maybe in the future there will be sublists... but for now, the developer community is too fragmented and there's no single accepted common discussion clearing house. Make it this list - good enough for Linus, good enough for us.

2) Develop a procedure for patch submission. There needs to be a way for Joe Random Developer, who has been maintaining his own installation of vtiger for God knows how long, to submit a patch that fixes a bug and get it into the main trunk with the minimum amount of overhead on his part. In the Linux kernel, it is possible to send a patch to linux-kernel or even direct to Linus, and if it fixes a problem, it gets applied with no other interaction save an acknowledgement that the patch was applied - no bug in Trac, no login IDs, no nothing. In order to make effective use of community developers, you need to make getting their work into the main trunk as effortless as possible.

3) That's not to say that bug trackers like Trac or Bugzilla ***CANNOT*** be used (they can be very useful) but don't ***REQUIRE*** their use.

4) Work out a best practice for the use of Subversion, document it in extreme, trivial detail as a HOWTO, and publish it on the wiki. Take the point of view of a developer hacking on a live install of vtiger - how can Subversion be best used to make his life easier? That probably means modifying the core tarball installer deal so that it puts the vtiger code into apache/htdocs/vtigerCRM/trunk

5) Go through the current codebase, and fix all the bugs you can. This takes priority over themes, advertising, and all the rest.
6) Comment, comment, comment! Things have improved on this front, but could still be better. I know that some of my patches that were applied preserved my comments (this is GOOD) but at least one was re-implemented (using a odd method) and not only was the new method NOT commented, my comments were stripped as well. So now there is new functionality in the code with NO record of who added it, what it does, or why a given method was used in preference to any other method. My rule of thumb is that NO change is made to the code without a corresponding comment - ENFORCE THAT.

DG