On 12/13/2016 11:45 PM, Rich Shepard wrote:
On Tue, 13 Dec 2016, Adrian Klaver wrote:
This killed the community(Open Source) edition going forward:
https://community.sugarcrm.com/thread/18434
I'd like to comment regarding this paragraph from the above-referenced
blog post:
"In the course of the past five years, we have surveyed tens of
thousands of
Sugar Community Edition users and found that we see two types of users of
Sugar Community Edition: 1) developers that wish to build on an open source
CRM platform, and 2) users, generally first time CRM users, that are
looking
for a free/inexpensive CRM solution. We don’t believe that the current
Sugar
Community Edition serves both audiences effectively. We envision an open
source solution targeted exclusively for developers. And, we also
envision a
simpler way for first-time CRM users to find and use CRM."
This is an interesting perspective, but not surprising for a large
for-profit corporation like SugarCRM.
I'm an environmental consultant sole practitioner and have been looking
for years for a postgres-supporting CRM that I could use. There is none.
Every business is different and has different needs. This is why a generic
CRM like Sugar that tries to fit every business regardless of type or size
forces its customers to fit into their generic model rather than supporting
a developer _and_ end-user framework that can be customized for each
business's specific needs and way of working.
This reminds me of Drupal and the companies driving its development again...
Drupal was interesting because it was a packaged product and a framework.
Most SME can't afford customization of ERP and accounting programs (if
you're not including invoice formatting).
SalesForce is not offering custom products and it is still pretty
successful.
While at least here in Italy I think most accounting programs are a
trap, I've realized that most of the times SME should learn from the
procedures proposed by CRM/ERP/accounting programs and adapt rather than
customize.
Processes are generally not scientifically planned, rather built up as
they go. A program that has been built to serve many through years may
not be optimal but at least tend to be more rational.
Still I'm not looking for something perfect, but something simple with
low maintenance.
*Postgres in this case is one of the ingredients of low maintenance or
at least maintenance I'm familiar with.*
That's why I'm developing my own using PyQt5, Python3, psychpg2, and
postgres-9.6.
I have the postgres schema that works for me and am willing to share it
with others because of this thread. I had not planned on putting it on
GitHub, but see no reason not to do so if there's interest by others. I'm
starting to learn PyQt5 and Python3 after a decade of wxPython use with
Python2 and am just about ready to start creating the UI.
Unfortunately I don't want to depend on something I'll have to put
developing resources in and I need something that work reasonably quickly.
But I admit that considering the few requirement I have I spent a couple
of seconds considering the idea to write one.
Nothing bad could come out by publishing your code on Github and if not
to contribute I'll surely give a look to learn something.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it http://www.borgonovo.net
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
