From darrylc@fudosys.com Thu Mar 11 23:34:39 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 11 Mar 2004 15:34:39 -0800 Subject: [Calendula-devel] data migration Message-ID: <1079048079.1306.13.camel@dhcppc4> Does anyone on the list have experience with migrating data from FileMaker and/or MS Access? I am looking ahead to import/export issues. And are there any more comments on the diagram? -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From creede@penguinsinthenight.com Thu Mar 11 23:48:26 2004 From: creede@penguinsinthenight.com (Creede Lambard) Date: Thu, 11 Mar 2004 15:48:26 -0800 Subject: [Calendula-devel] data migration In-Reply-To: <1079048079.1306.13.camel@dhcppc4> References: <1079048079.1306.13.camel@dhcppc4> Message-ID: <20040311234826.GE9809@igor.penguinsinthenight.com> --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I don't have experience, but I do have Google. http://starship.python.net/crew/bwilk/access.html This page admits to being somewhat outdated but might give some pointers as to how to read an Access database from Python. Unfortunately you apparently have to do this on a machine with a Jet DB engine running, which means Windows; fortunately it looks like SQL is available in the queries (at least the example given contains a SQL query). Ideally there would be a native Python module that would read Access and FileMaker tables (maybe even entire databases) and spit them back out in CSV or some other easily exportable format. On Thu, Mar 11, 2004 at 03:34:39PM -0800, Darryl Caldwell wrote: > Does anyone on the list have experience with migrating data from > FileMaker and/or MS Access? >=20 > I am looking ahead to import/export issues. >=20 > And are there any more comments on the diagram? >=20 > -D >=20 > --=20 > Darryl Caldwell darrylc@fudosys.com > Fudo Systems www.fudosys.com > 206/567-5802 "Free Your Computers!" >=20 > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * .~. ( : Creede Lambard : Never rush a miracle man. . / V \ . :------------------------: You get lousy miracles. /( )\ : creede at : --------------------------------^^-^^----: penguinsinthenight : =20 Linux. Reliable and free. Pick any two. : dot com : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAUPrK6RaRqmjNX/0RApXIAJ9tjqt9hNsflkXIdbQVWF9W6Lfu0gCeIYVQ eFKxBqMC+tphAFhEI9+yI1M= =QbxA -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From TPanzarella@fcny.org Fri Mar 12 13:31:47 2004 From: TPanzarella@fcny.org (Thomas Panzarella) Date: Fri, 12 Mar 2004 08:31:47 -0500 Subject: [Calendula-devel] data migration Message-ID: I'm not familiar with FileMaker (and only vaguely familiar with Access), but on the Access front you could use a product like http://www.mysql.com/portal/software/item-98.html to convert the Access DB to MySQL and then from MySQL you can pretty much take it anywhere (or leave it there since MySQL is mature and robust -- IMHO). Also, I know Access can be used as an ODBC data source (maybe file maker can too???) -- so why not "roll your own" export utility? -- for example in Java you could use the freely supplied JDBC/ODBC bridge and pull data from access to whatever you want using standard JDBC. Does Python have some type of bridging driver to ODBC? Since it seems Python is your lang of choice, I'd check that out. t. > -----Original Message----- > From: Creede Lambard [mailto:creede@penguinsinthenight.com] > Sent: Thursday, March 11, 2004 6:48 PM > To: Darryl Caldwell > Cc: caldev > Subject: Re: [Calendula-devel] data migration >=20 >=20 > I don't have experience, but I do have Google. >=20 > http://starship.python.net/crew/bwilk/access.html >=20 > This page admits to being somewhat outdated but might give=20 > some pointers as > to how to read an Access database from Python. Unfortunately=20 > you apparently > have to do this on a machine with a Jet DB engine running, which means > Windows; fortunately it looks like SQL is available in the=20 > queries (at least > the example given contains a SQL query). >=20 > Ideally there would be a native Python module that would read=20 > Access and > FileMaker tables (maybe even entire databases) and spit them=20 > back out in CSV > or some other easily exportable format. >=20 > On Thu, Mar 11, 2004 at 03:34:39PM -0800, Darryl Caldwell wrote: > > Does anyone on the list have experience with migrating data from > > FileMaker and/or MS Access? > >=20 > > I am looking ahead to import/export issues. > >=20 > > And are there any more comments on the diagram? > >=20 > > -D > >=20 > > --=20 > > Darryl Caldwell darrylc@fudosys.com > > Fudo Systems www.fudosys.com > > 206/567-5802 "Free Your Computers!" > >=20 > > _______________________________________________ > > Calendula-devel mailing list > > Calendula-devel@fudosys.com > > http://list.fudosys.com/mailman/listinfo/calendula-devel >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * .~. ( : Creede Lambard : > Never rush a miracle man. . / V \ . :------------------------: > You get lousy miracles. /( )\ : creede at : > --------------------------------^^-^^----: penguinsinthenight :=20=20 > Linux. Reliable and free. Pick any two. : dot com : > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 From bill-bell@bill-bell.hamilton.on.ca Fri Mar 12 14:06:13 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Fri, 12 Mar 2004 09:06:13 -0500 Subject: [Calendula-devel] data migration In-Reply-To: Message-ID: <40517D85.16264.3B757E8@localhost> On 12 Mar 2004 at 8:31, Thomas Panzarella wrote: > I'm not familiar with FileMaker (and only vaguely familiar with Access), > but on the Access front you could use a product like > http://www.mysql.com/portal/software/item-98.html to convert the Access > DB to MySQL and then from MySQL you can pretty much take it anywhere (or > leave it there since MySQL is mature and robust -- IMHO). > > Also, I know Access can be used as an ODBC data source (maybe file maker > can too???) -- so why not "roll your own" export utility? -- for example > in Java you could use the freely supplied JDBC/ODBC bridge and pull data > from access to whatever you want using standard JDBC. Does Python have > some type of bridging driver to ODBC? Since it seems Python is your > lang of choice, I'd check that out. Hello, all: I haven't been following this thread, and I haven't posted to this list before, which explains why I'm copying to some individuals: I'm not sure I have the right address for the list. I've worked with both FM and Access. Both support ODBC, and Python offers convenient access to ODBC. IIRC, FM's ODBC is wobbly, and as a consequence I have retrieved data from FM tables as HTML files, then parsed them. Access's ODBC has never given me trouble, and I've used it heavily, on and off, for some years. Here is some Python code to read from an Access database using ODBC. In this case Python reads from a table called "Students". It's just as easy to read from a virtual table defined with a SQL statement. # code starts here ============================== from win32com . client import Dispatch from smtplib import SMTP conn = Dispatch ( r'ADODB.Connection' ) connString = r'PROVIDER=Microsoft.Jet.OLEDB.4.0;DATA SOURCE=E:\1P97\Master\students.mdb' conn.Open ( connString ) rs = Dispatch ( r'ADODB.Recordset' ) server = SMTP ( 'smtp.vex.net', 425 ) server . set_debuglevel ( 1 ) server . login ( 'wbell', '*******' ) rs.Open ( "[students]", conn, 1, 3 ) while not rs . EOF : for addressField in [ 'email1', 'email2' ] : if rs . Fields ( addressField ) . Value : toaddr = rs . Fields ( addressField ) . Value server . sendmail ( 'bill@softwaregeneralist.ca', toaddr, """ \ Subject: Your ITIS 1P97 assignment submission code I'm sending this message to everyone in my section of ITIS 1P97. Your code is %s. Please bring it with you to every laborary session. Perhaps you could write it on a slip of paper that you keep in your billfold or handbag? Thanks. Bill Bell """ % rs . Fields ( 'code' ) . Value ) #~ break rs . Move ( 1 ) rs . Close ( ) server . quit ( ) # code ends here ============================== Would someone mind restating the problem to be solved? Best regards, Bill From darrylc@fudosys.com Fri Mar 12 17:08:44 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: Fri, 12 Mar 2004 09:08:44 -0800 (PST) Subject: [Calendula-devel] data migration In-Reply-To: <40517D85.16264.3B757E8@localhost> References: <40517D85.16264.3B757E8@localhost> Message-ID: <34725.64.38.163.140.1079111324.squirrel@webmail.fudosys.com> Bill, Bill, Bill, where were you when I needed your expertise last year? ;-) Thanks for that great code snippet. I can see putting that to use REAL SOON. The problem to be solved is to start planning for migration of data in FM and Access databases over to Calendula. Thomas and others have suggested that many small nonprofits use FM and Access to store their donor data. Some type of migration tools should be present early on and I want to make sure the path is mapped out. -D > > Hello, all: > > I haven't been following this thread, and I haven't posted to this list > before, which > explains why I'm copying to some individuals: I'm not sure I have the > right address > for the list. > > I've worked with both FM and Access. Both support ODBC, and Python offers > convenient access to ODBC. IIRC, FM's ODBC is wobbly, and as a consequence > I > have retrieved data from FM tables as HTML files, then parsed them. > Access's > ODBC has never given me trouble, and I've used it heavily, on and off, for > some > years. > == Code sample snipped == > > Would someone mind restating the problem to be solved? > -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From darrylc@fudosys.com Fri Mar 12 17:26:31 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: Fri, 12 Mar 2004 09:26:31 -0800 (PST) Subject: [Calendula-devel] Everyone has been unsubscribed from gnu list Message-ID: <34741.64.38.163.140.1079112391.squirrel@webmail.fudosys.com> You may have just received the goodbye msg from the gnu list. I just unsubscribed us all from there. Direct all your posts to calendula-devel@fudosys.com from now on. Thanks. -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From creede@penguinsinthenight.com Fri Mar 12 17:42:13 2004 From: creede@penguinsinthenight.com (Creede Lambard) Date: Fri, 12 Mar 2004 09:42:13 -0800 Subject: [Calendula-devel] data migration In-Reply-To: <34725.64.38.163.140.1079111324.squirrel@webmail.fudosys.com> References: <40517D85.16264.3B757E8@localhost> <34725.64.38.163.140.1079111324.squirrel@webmail.fudosys.com> Message-ID: <20040312174213.GK9809@igor.penguinsinthenight.com> --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The problem as I see it is that unless these databases are from programs wi= th standardized formats, you are going to have a bunch of tables slapped together and won't know programmatically which field represents which information in Calendula's database. I guess you could migrate data to CSV files and then have a tool to import the CSV information by specifying which FM/Access field maps to which Calendula field, but I don't think even that = is as straightforward as it sounds. Not to say we shouldn't do it, of course. Just saying it's going to require some skullsweat before the code gets written. On Fri, Mar 12, 2004 at 09:08:44AM -0800, Darryl Caldwell wrote: > Bill, Bill, Bill, where were you when I needed your expertise last year? = ;-) >=20 > Thanks for that great code snippet. I can see putting that to use REAL > SOON. The problem to be solved is to start planning for migration of data > in FM and Access databases over to Calendula. Thomas and others have > suggested that many small nonprofits use FM and Access to store their > donor data. Some type of migration tools should be present early on and I > want to make sure the path is mapped out. >=20 > -D --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * .~. ( : Creede Lambard : Never rush a miracle man. . / V \ . :------------------------: You get lousy miracles. /( )\ : creede at : --------------------------------^^-^^----: penguinsinthenight : =20 Linux. Reliable and free. Pick any two. : dot com : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFAUfZ06RaRqmjNX/0RAiiTAJdr5pvSeGMW9cPx+rkwimXpBktBAJ9CzfZI AyoOxgIrGsZrZe7R0pttcQ== =2rNN -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From TPanzarella@fcny.org Fri Mar 12 17:44:01 2004 From: TPanzarella@fcny.org (Thomas Panzarella) Date: Fri, 12 Mar 2004 12:44:01 -0500 Subject: [Calendula-devel] data migration Message-ID: With all of the Calendula movement (list, etc.) could you (Darryl) quickly = send out an email that says where the lists are, where the CVS is located, = and any other pertinent info for contributors? Also, at this point, I think we should turn discussions to finializing requ= irements, building a clear project plan document, and building out technica= l specifications -- I'd suggest we try to stick with some "standards" when = trying to communicate technical aspects of the project (i.e. UML Diagrams, = Use Cases, etc.). I feel sort of lost as to how to intelligently contribut= e here. We are talking data migration but what is the context? We looked = at a code snippet that connects to a database but, (again) what is the cont= ext? Who on this list is heading to Philly for NTEN? I propose a meetup of peop= le interested in the Calendula project to sit and discuss some details. I = will volunteer myself to draft up "minutes", so to speak, from that meeting= to communicate back to the group at large. Eventhough this is the "less f= un part" of open source, we need to work out the politics of how the "calen= dula community" is going to work. Set up a "board" ... who is "code captai= n", who is "zealot", who will maintain a bug database, who will maintain th= e list servs / cvs / etc., who is a "comitter" to cvs, who will set up - ma= intain - and make look pretty/professional the calendula project web site, = etc. There are many issues that need to get worked out ... I am going to a= ssume that Darryl does not want to take on all of those roles. t. > -----Original Message----- > From: Darryl Caldwell [mailto:darrylc@fudosys.com] > Sent: Friday, March 12, 2004 12:09 PM > To: calendula-devel@fudosys.com > Subject: RE: [Calendula-devel] data migration >=20 >=20 > Bill, Bill, Bill, where were you when I needed your expertise=20 > last year? ;-) >=20 > Thanks for that great code snippet. I can see putting that to use REAL > SOON. The problem to be solved is to start planning for=20 > migration of data > in FM and Access databases over to Calendula. Thomas and others have > suggested that many small nonprofits use FM and Access to store their > donor data. Some type of migration tools should be present=20 > early on and I > want to make sure the path is mapped out. >=20 > -D >=20 >=20 > > > > Hello, all: > > > > I haven't been following this thread, and I haven't posted=20 > to this list > > before, which > > explains why I'm copying to some individuals: I'm not sure=20 > I have the > > right address > > for the list. > > > > I've worked with both FM and Access. Both support ODBC, and=20 > Python offers > > convenient access to ODBC. IIRC, FM's ODBC is wobbly, and=20 > as a consequence > > I > > have retrieved data from FM tables as HTML files, then parsed them. > > Access's > > ODBC has never given me trouble, and I've used it heavily,=20 > on and off, for > > some > > years. > > > =3D=3D Code sample snipped =3D=3D > > > > Would someone mind restating the problem to be solved? > > >=20 >=20 > --=20 > Darryl Caldwell > darrylc@fudosys.com > www.fudosys.com > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel >=20 From TPanzarella@fcny.org Fri Mar 12 17:48:29 2004 From: TPanzarella@fcny.org (Thomas Panzarella) Date: Fri, 12 Mar 2004 12:48:29 -0500 Subject: [Calendula-devel] data migration Message-ID: Agreed. The way that I think this is best attacked is to create a clear specification on a data import file format or API. Then have individuals who have a personal stake in writing, for example, a Raiser's Edge to Calendula data migration tool to build the driver that will extract from RE into the Calendula's published import format and then run the Calendula import tools against that file or set of files to import the data. Much easier on the Calendula side and promotes community and could ultimately mean support for many more systems in the end... t. > -----Original Message----- > From: Creede Lambard [mailto:creede@penguinsinthenight.com] > Sent: Friday, March 12, 2004 12:42 PM > To: Darryl Caldwell > Cc: calendula-devel@fudosys.com > Subject: Re: [Calendula-devel] data migration >=20 >=20 > The problem as I see it is that unless these databases are=20 > from programs with > standardized formats, you are going to have a bunch of tables slapped > together and won't know programmatically which field represents which > information in Calendula's database. I guess you could=20 > migrate data to CSV > files and then have a tool to import the CSV information by=20 > specifying which > FM/Access field maps to which Calendula field, but I don't=20 > think even that is > as straightforward as it sounds. >=20 > Not to say we shouldn't do it, of course. Just saying it's=20 > going to require > some skullsweat before the code gets written. >=20 > On Fri, Mar 12, 2004 at 09:08:44AM -0800, Darryl Caldwell wrote: > > Bill, Bill, Bill, where were you when I needed your=20 > expertise last year? ;-) > >=20 > > Thanks for that great code snippet. I can see putting that=20 > to use REAL > > SOON. The problem to be solved is to start planning for=20 > migration of data > > in FM and Access databases over to Calendula. Thomas and others have > > suggested that many small nonprofits use FM and Access to=20 > store their > > donor data. Some type of migration tools should be present=20 > early on and I > > want to make sure the path is mapped out. > >=20 > > -D >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * .~. ( : Creede Lambard : > Never rush a miracle man. . / V \ . :------------------------: > You get lousy miracles. /( )\ : creede at : > --------------------------------^^-^^----: penguinsinthenight :=20=20 > Linux. Reliable and free. Pick any two. : dot com : > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 From bill-bell@bill-bell.hamilton.on.ca Fri Mar 12 22:22:29 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Fri, 12 Mar 2004 17:22:29 -0500 Subject: [Calendula-devel] data migration In-Reply-To: <34725.64.38.163.140.1079111324.squirrel@webmail.fudosys.com> References: <40517D85.16264.3B757E8@localhost> Message-ID: <4051F1D5.23881.57DB0C8@localhost> On 12 Mar 2004 at 9:08, Darryl Caldwell wrote: > Bill, Bill, Bill, where were you when I needed your expertise last year? ;-) Appearances to the contrary notwithstanding, my life is not all laughs and excitement. I was probably sitting in this very chair last year staring at this very screen. :o) > The problem to be solved is to start planning for migration of data > in FM and Access databases over to Calendula. ... Thanks for the summary! Bill From darrylc@fudosys.com Sun Mar 14 22:00:56 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: Sun, 14 Mar 2004 14:00:56 -0800 (PST) Subject: [Calendula-devel] construction plans to date In-Reply-To: References: Message-ID: <18067.207.254.100.206.1079301656.squirrel@webmail.fudosys.com> > With all of the Calendula movement (list, etc.) could you (Darryl) quickly > send out an email that says where the lists are, where the CVS is located, > and any other pertinent info for contributors? Quicker than quick! I've just spent 2 days at a YMCA development conference, breaking bread with fundraisers and spying on all of the proprietary software vendors. I encourage everyone who does not currently have a relationship with a nonprofit/charity to do this. It is well worth getting a peak at the requirement from their side; and let me tell you that cultivation of donors is key to getting their funding. Calendula shall be key to this process. So here are a few quick details requested by Thomas: Calendula Project: https://savannah.gnu.org/projects/calendula/ Calendula is part of the gnu project. Developers can get accounts here and receive contributor status. This is also the easiest way to view and access the cvs repository. This will change again and again, of course. Please visit and get an account. This will be your first step. In CVS you will find: REQ -- requirements doc ROADMAP - skeletal survey_questions -- survey for end-users universal_article - the business case article for Calendula database - directory contains: db schema in postgres format, OpenOffice diagram of the db tables. All of this needs updating and warts removed. Calendula Development mailing list: http://list.fudosys.com/mailman/listinfo/calendula-devel UI workflow diagram can be viewed at: http://fudosys.com/calendula-diagram.png I will be adding it to CVS soon. Here is the list of potential coders: Me Creede L. Thomas P. David G. And potential collaborators from DicipleMakers: Matthew P. Jason M. Tom H. Brian R. Some arms may need twisting from the list above. Now regarding the context of the database migration discussion I started it simply to get an idea of a possible migration path and how this would impact the early stages of the project. We will revisit it later on. I don't want anyone to feel stuck or lost. Squeaky wheels will get greased. If no one but Tom P. is going to N-TEN, we could schedule a conference call to act on "who owns what". And I could get started with Mr. Project.... -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 12:52:38 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Mon, 15 Mar 2004 07:52:38 -0500 Subject: [Calendula-devel] construction plans to date In-Reply-To: <18067.207.254.100.206.1079301656.squirrel@webmail.fudosys.com> References: Message-ID: <405560C6.5270.12E70BA1@localhost> On 14 Mar 2004 at 14:00, Darryl Caldwell wrote, in part: > > So here are a few quick details requested by Thomas: > > Calendula Project: > > https://savannah.gnu.org/projects/calendula/ I've reviewed some of the project documents. Has there been any discussion about what the main coding language will be? Bill From tpanzarella@mac.com Mon Mar 15 13:17:47 2004 From: tpanzarella@mac.com (Thomas Panzarella) Date: Mon, 15 Mar 2004 08:17:47 -0500 Subject: [Calendula-devel] construction plans to date Message-ID: <15226085.1079356667545.JavaMail.tpanzarella@mac.com> I believe that Darryl wanted to implement (at least the prototype) in Python. Is this set in stone? t. On Monday, March 15, 2004, at 07:52AM, Bill Bell wrote: > >On 14 Mar 2004 at 14:00, Darryl Caldwell wrote, in part: >> >> So here are a few quick details requested by Thomas: >> >> Calendula Project: >> >> https://savannah.gnu.org/projects/calendula/ > >I've reviewed some of the project documents. Has there been any discussion about >what the main coding language will be? > >Bill >_______________________________________________ >Calendula-devel mailing list >Calendula-devel@fudosys.com >http://list.fudosys.com/mailman/listinfo/calendula-devel > > From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 13:40:47 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Mon, 15 Mar 2004 08:40:47 -0500 Subject: [Calendula-devel] construction plans to date Message-ID: <40556C0F.11354.13132159@localhost> Thomas Panzarella > I believe that Darryl wanted to implement (at least the prototype) in > Python. Is this set in stone? I do not want to impose my preferences on others. However, I'm up to speed with Python and wxPython, and I'd be a willing participant. Bill PS: Recipes: http://aspn.activestate.com/ASPN/Cookbook/Python (search for "Bill Bell" with quotation marks) http://wiki.wxpython.org/index.cgi/FindPage?action=fullsearch&value=Bill+Bell&conte xt=40 http://www.zopelabs.com/cookbook/1054211661 From tpanzarella@mac.com Mon Mar 15 13:51:58 2004 From: tpanzarella@mac.com (Thomas Panzarella) Date: Mon, 15 Mar 2004 08:51:58 -0500 Subject: [Calendula-devel] construction plans to date Message-ID: <3152748.1079358718555.JavaMail.tpanzarella@mac.com> I too can deal with Python. But I must say, that I am inclined to think that a compiled language with strong typing would be preferred for a project of this scope. Also, I think much more important that the ultimate language is the architecture. A well designed object model and the use of patterns will pay off many times over in the end. If the design is done right, we could code this in any language that supports OO -- if I'm not mistaken, GetActive is coded in TCL and look at the success there! t. On Monday, March 15, 2004, at 08:40AM, Bill Bell wrote: > >Thomas Panzarella > >> I believe that Darryl wanted to implement (at least the prototype) in >> Python. Is this set in stone? > >I do not want to impose my preferences on others. However, I'm up to speed with >Python and wxPython, and I'd be a willing participant. > >Bill > >PS: Recipes: > >http://aspn.activestate.com/ASPN/Cookbook/Python (search for "Bill Bell" with >quotation marks) > >http://wiki.wxpython.org/index.cgi/FindPage?action=fullsearch&value=Bill+Bell&conte >xt=40 > >http://www.zopelabs.com/cookbook/1054211661 >_______________________________________________ >Calendula-devel mailing list >Calendula-devel@fudosys.com >http://list.fudosys.com/mailman/listinfo/calendula-devel > > From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 14:11:25 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Mon, 15 Mar 2004 09:11:25 -0500 Subject: [Calendula-devel] construction plans to date In-Reply-To: <3152748.1079358718555.JavaMail.tpanzarella@mac.com> Message-ID: <4055733D.10728.132F2FC9@localhost> On 15 Mar 2004 at 8:51, Thomas Panzarella wrote: > > I too can deal with Python. But I must say, that I am inclined to > think that a compiled language with strong typing would be preferred > for a project of this scope. (a) We can "compile" Python in various ways. The compiled codes are, of course, larger. However, that might not be an important factor for this project. (b) Python _is_ strongly typed. > Also, I think much more important that the ultimate language is the architecture. Perhaps we can agree that we will surely fail if we do a poor job of the architecture. I believe it might have been you that mentioned using UML. OK. An alternative would be literate programming, which is supported by Leo. This would have the advantage that it tends to be easier to exchange and modify texts than graphics. Or, maybe there's a free vehicle that supports UML; I'd love to know about one. > A well designed object model and the use of patterns will pay off many > times over in the end. Yes, I agree. At the same time, there are numerous ways of achieving that. > If the design is done right, we could code this in any language that > supports OO -- Sure. However, it's worth considering the fact that some languages in which we could code (and I'm thinking of C++) might cost us two or three times the work. Anyway, I was just letting others know what I can offer. It might be that my ego got in the way. Cheers, Bill From tpanzarella@mac.com Mon Mar 15 15:00:27 2004 From: tpanzarella@mac.com (Thomas Panzarella) Date: Mon, 15 Mar 2004 10:00:27 -0500 Subject: [Calendula-devel] construction plans to date Message-ID: <6045366.1079362827702.JavaMail.tpanzarella@mac.com> On Monday, March 15, 2004, at 09:11AM, Bill Bell wrote: > >(b) Python _is_ strongly typed. > I disagree, but that's not the point of this discussion. What I will agree on is that "strong testing" of Python code can ultimately lead to the same end result of strong static type checking at compile time (ala C++, Java, etc.) ... of course just because code compiles doesn't mean it *works* ... strong testing is just as important in a C++ or Java environment as well. > >> Also, I think much more important that the ultimate language is the architecture. > >Perhaps we can agree that we will surely fail if we do a poor job of the architecture. > Agreed. > >I believe it might have been you that mentioned using UML. OK. > yep. > >An alternative would be literate programming, which is supported by Leo. This would >have the advantage that it tends to be easier to exchange and modify texts than >graphics. > Don't know about this ... send some links that we could check out... > >Or, maybe there's a free vehicle that supports UML; I'd love to know about >one. > http://www.gentleware.com/products/descriptions/ce.php4 > >> If the design is done right, we could code this in any language that >> supports OO -- > >Sure. However, it's worth considering the fact that some languages in which we could >code (and I'm thinking of C++) might cost us two or three times the work. > I was actually thinking Java. With the amount of freely available and open source development tools for Java today, I think Java developement can happen just as fast as using a scripting language like Perl or Python (YMMV). I also think that there are additional benefits to Java: 1- javadoc - API docs are just as important as code in an open source project and javadoc makes it painless 2- native look-and-feels via Swing - support for XP, Java, GTK+, and Aqua. Anyway, I absolutely don't want to debate over language preferences with anyone. I think we need to do our technical due diligence when designing this system taking into account the environment that the system will be running in (non-profits that can't afford off-the-shelf tools and could care less what the underlying technology is). I'm interested in helping non-profits, not debating the technical merits of Python vs. Java or whatever.... Also, I want it to be clear that I have nothing against Python. I enjoy programming in Python. If that is what Calendula is ultimately going to be implemented in, so be it. I was just throwing in another perspective / preference .... t. From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 16:26:40 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Mon, 15 Mar 2004 11:26:40 -0500 Subject: [Calendula-devel] construction plans to date In-Reply-To: <6045366.1079362827702.JavaMail.tpanzarella@mac.com> Message-ID: <405592F0.19943.13AB010B@localhost> On 15 Mar 2004 at 10:00, Thomas Panzarella wrote: > > What I will agree on is that "strong testing" ... I seem to hear you alluding to the idea that language choice and testing strategy are interdependent. If so, I definitely agree, FWIW. We would need to discuss this further. In fact, we need statements about language choice and testing strategy. More generally, I haven't noticed any outline about software engineering for this project. Perhaps we should start one, so that, as far as possible, we discuss issues once, record decisions, then move on to issues that haven't been decided. > Don't know about [Leo] ... send some links that we could check out... http://webpages.charter.net/edreamleo/front.html ... which seems to provide a link to literate programming, as a bonus. I was amazed to see an idea as old as this re-emerge; still, it might help us. > >Or, maybe there's a free vehicle that supports UML; I'd love to know about > >one. > http://www.gentleware.com/products/descriptions/ce.php4 Thanks. Poseidon seems to be most closely associated with java, but then Leo favours Python work. Either looks interesting to me. Let's put this matter into an outline. Once we have enough items, let's priortise them, and finish discussions, so that we can move on. > Anyway, I absolutely don't want to debate over language preferences > with anyone. ...I'm interested in helping non-profits, not debating > the technical merits of Python vs. Java or whatever.... So you concede that Python is better???? Only joking! I don't care either. However, we need to start a process for taking decisions in order to make progress. Bill From creede@penguinsinthenight.com Mon Mar 15 17:57:46 2004 From: creede@penguinsinthenight.com (Creede Lambard) Date: Mon, 15 Mar 2004 09:57:46 -0800 Subject: [Calendula-devel] construction plans to date In-Reply-To: <4055733D.10728.132F2FC9@localhost> References: <3152748.1079358718555.JavaMail.tpanzarella@mac.com> <4055733D.10728.132F2FC9@localhost> Message-ID: <20040315175746.GC24283@igor.penguinsinthenight.com> --Pk6IbRAofICFmK5e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 15, 2004 at 09:11:25AM -0500, Bill Bell wrote: > Sure. However, it's worth considering the fact that some languages in whi= ch > we could code (and I'm thinking of C++) might cost us two or three times > the work. > C++ will also probably cost you at least one potential developer. I'm just another Perl hacker who knows enough Python to get into trouble, and while I can probably trust myself to get up to speed on wxPython quickly enough to = do some code for Calendula, I make no such claims about C, C++ or Java. (Howev= er if Calendula were to go to one of these languages, even if I'm not coding, I know how to write documentation and the like.) Python might also make it easier for NPOs to do their own modifications to the code, since it's much easier to learn than lower-level languages. And on a slightly less serious note, Darryl is a card-carrying member of House Slytherin, and he has so far resisted my efforts to convert him back = to the Multiple True Ways of Perl, where I first met him. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * .~. ( : Creede Lambard : Never rush a miracle man. . / V \ . :------------------------: You get lousy miracles. /( )\ : creede at : --------------------------------^^-^^----: penguinsinthenight : =20 Linux. Reliable and free. Pick any two. : dot com : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Pk6IbRAofICFmK5e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAVe6a6RaRqmjNX/0RAoU6AJ9SCTLy/UY5wtd7Ot+uXWXrcPrTzgCfUzyU Zy4XTMo+uXrjPmMbboyeOgQ= =se7z -----END PGP SIGNATURE----- --Pk6IbRAofICFmK5e-- From maasj@dm.org Mon Mar 15 18:14:39 2004 From: maasj@dm.org (Jason Maas) Date: Mon, 15 Mar 2004 13:14:39 -0500 (EST) Subject: [Calendula-devel] GNUe analysis - might be helpful Message-ID: Hi all, I'm excited to see the traffic on this list increasing and things starting to roll! I have a thought for an exercise that could be very helpful for us. I think it might be wise to do some sort of analysis of the GNUe project (www.gnue.org). I think it would be helpful to understand their architecture and learn from their experience. If we're not going to join them then I think someone should write down why and what we want to do differently. That would help us avoid reinventing the wheel and probably be useful in the future as people stop in and ask how Calendula is differnt from GNUe. I'm just thinking of a simple one page writeup with some bullets and a summary. Does this sound useful? Anyone wanna give it a shot? Jason -- Jason Maas DiscipleMakers Systems Dept --> www.dm.org From darrylc@fudosys.com Mon Mar 15 19:06:46 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 15 Mar 2004 11:06:46 -0800 Subject: [Calendula-devel] plans plans plans In-Reply-To: <405592F0.19943.13AB010B@localhost> References: <405592F0.19943.13AB010B@localhost> Message-ID: <1079377605.1305.44.camel@dhcppc4> Hello all, Thanks for all of the input. I can hear nonprofits around the world breathing an unconscious sigh of relief.... Ok. The tasks at hand: 1. If you are interested in development, get an account on Savannah and let me know your account name. 2. Design docs. First, do the requirements (REQ) look good to everyone? Do we need to convert any of the existing items into standard UML? 3. Language: Python for flexibility, readability, and as my own safety net (meaning if you all get hit by a bus, I need to be able to forge ahead). wxPython has really good support for adopting a native look/feel, but this will come after the Zope prototype. -D On Mon, 2004-03-15 at 08:26, Bill Bell wrote: > On 15 Mar 2004 at 10:00, Thomas Panzarella wrote: > > > > What I will agree on is that "strong testing" .. > > I seem to hear you alluding to the idea that language choice and testing strategy are > interdependent. If so, I definitely agree, FWIW. We would need to discuss this > further. In fact, we need statements about language choice and testing strategy. > > More generally, I haven't noticed any outline about software engineering for this > project. Perhaps we should start one, so that, as far as possible, we discuss issues > once, record decisions, then move on to issues that haven't been decided. > > > Don't know about [Leo] ... send some links that we could check out... > > http://webpages.charter.net/edreamleo/front.html > > ... which seems to provide a link to literate programming, as a bonus. I was amazed > to see an idea as old as this re-emerge; still, it might help us. > > > >Or, maybe there's a free vehicle that supports UML; I'd love to know about > > >one. > > http://www.gentleware.com/products/descriptions/ce.php4 > > Thanks. Poseidon seems to be most closely associated with java, but then Leo > favours Python work. Either looks interesting to me. Let's put this matter into an > outline. Once we have enough items, let's priortise them, and finish discussions, so > that we can move on. > > > Anyway, I absolutely don't want to debate over language preferences > > with anyone. ...I'm interested in helping non-profits, not debating > > the technical merits of Python vs. Java or whatever.... > > So you concede that Python is better???? Only joking! > > I don't care either. However, we need to start a process for taking decisions in order > to make progress. > > Bill > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Mon Mar 15 19:38:47 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 15 Mar 2004 11:38:47 -0800 Subject: [Calendula-devel] GNUe analysis - might be helpful Message-ID: <1079379527.1305.72.camel@dhcppc4> Analysis of GNUe framework... I am not sure that is a good idea, since I did spend a lot of time on it a while back. But I think we can do this right here and then someone can summarize. Why GNUe isn't good for Calendula: * Poor documentation (the current developers prefer IRC) * Unstable framework * Poor support (very little list traffic), limited adoption * inflexible UI design I used spent a couple of weeks downloading their IRC logs and grepping for the answers to my questions. I eventually decided that this is not a good foundation to build one's house upon. When I pointed this out to them they said, "well that's how we like to work." A better analysis would be to look at the GNUMED project (www.gnumed.org). On Mon, 2004-03-15 at 10:14, Jason Maas wrote: > Hi all, > > I'm excited to see the traffic on this list increasing and things starting > to roll! I have a thought for an exercise that could be very helpful for > us. > > I think it might be wise to do some sort of analysis of the GNUe project > (www.gnue.org). I think it would be helpful to understand their > architecture and learn from their experience. If we're not going to join > them then I think someone should write down why and what we want to do > differently. That would help us avoid reinventing the wheel and probably > be useful in the future as people stop in and ask how Calendula is > differnt from GNUe. > > I'm just thinking of a simple one page writeup with some bullets and a > summary. Does this sound useful? Anyone wanna give it a shot? > > Jason -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From tpanzarella@mac.com Mon Mar 15 20:24:10 2004 From: tpanzarella@mac.com (Thomas Panzarella) Date: Mon, 15 Mar 2004 15:24:10 -0500 Subject: [Calendula-devel] plans plans plans Message-ID: <11874033.1079382250561.JavaMail.tpanzarella@mac.com> On Monday, March 15, 2004, at 02:06PM, Darryl Caldwell wrote: > >3. Language: Python for flexibility, readability, and as my own safety >net (meaning if you all get hit by a bus, I need to be able to forge >ahead). wxPython has really good support for adopting a native >look/feel, but this will come after the Zope prototype. > Good man Darryl. Just what we need, a "benevolent dictator". From maasj@dm.org Mon Mar 15 20:34:46 2004 From: maasj@dm.org (Jason Maas) Date: Mon, 15 Mar 2004 15:34:46 -0500 (EST) Subject: [Calendula-devel] GNUe analysis - might be helpful In-Reply-To: <1079379527.1305.72.camel@dhcppc4> References: <1079379527.1305.72.camel@dhcppc4> Message-ID: Hi Darryl, On Mon, 15 Mar 2004, Darryl Caldwell wrote: >But I think we can do this right here and then someone can summarize. Great! I wasn't looking for anything real in-depth. >Why GNUe isn't good for Calendula: > >* Poor documentation (the current developers prefer IRC) >* Poor support (very little list traffic), limited adoption While those do raise red flags, I don't think they're show stoppers because they're fairly easily remedied. >* Unstable framework >* inflexible UI design These two are more interesting. Could you write a sentence or two about each one explaining what you mean? For example, by "unstable" do you mean that it crashes often or that the API changes daily...? >A better analysis would be to look at the GNUMED project >(www.gnumed.org). I poked around briefly on their website. I had never heard of the project before but it does look interesting. What in particular should we look at? Jason -- Jason Maas DiscipleMakers Systems Dept --> www.dm.org From tpanzarella@mac.com Mon Mar 15 20:37:43 2004 From: tpanzarella@mac.com (Thomas Panzarella) Date: Mon, 15 Mar 2004 15:37:43 -0500 Subject: [Calendula-devel] Calendula PR at NTEN / Penguin Day Message-ID: <247821.1079383063139.JavaMail.tpanzarella@mac.com> For those who are unaware, there is a mini conference being run in conjunction w/ NTEN in Philly at the end of the month called "Penguin Day" - http://www.penguinday.org. The point of it is to bring together open source developers and NGOs to start facilitating communication and the development of open source apps for NGOs. I have been asked by the organizers to facilitate a session at Penguin Day called "Emerging Technologies" / "Open Sourcing Java" -- my question is, do we want to "plug" Calendula there? If so, let's collaborate on what we would like to announce to the community at Penguin Day and I would be more than willing to be the mouth piece for us or to distribute literature, etc. t. From mako@debian.org Mon Mar 15 21:05:50 2004 From: mako@debian.org (Benj. Mako Hill) Date: Mon, 15 Mar 2004 22:05:50 +0100 Subject: [Calendula-devel] Calendula PR at NTEN / Penguin Day In-Reply-To: <247821.1079383063139.JavaMail.tpanzarella@mac.com> References: <247821.1079383063139.JavaMail.tpanzarella@mac.com> Message-ID: <20040315210550.GT20438@yukidoke.org> --0rEjiS+nMGFQ7Kkj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 15, 2004 at 03:37:43PM -0500, Thomas Panzarella wrote: > For those who are unaware, there is a mini conference being run in > conjunction w/ NTEN in Philly at the end of the month called > "Penguin Day" - http://www.penguinday.org. The point of it is to > bring together open source developers and NGOs to start facilitating > communication and the development of open source apps for NGOs. I > have been asked by the organizers to facilitate a session at Penguin > Day called "Emerging Technologies" / "Open Sourcing Java" -- my > question is, do we want to "plug" Calendula there? If so, let's > collaborate on what we would like to announce to the community at > Penguin Day and I would be more than willing to be the mouth piece > for us or to distribute literature, etc. I'll be there as well. --=20 Benjamin Mako Hill mako@debian.org http://mako.yukidoke.org/ --0rEjiS+nMGFQ7Kkj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAVhquic1LIWB1WeYRAnxYAKDpWBvz4uReAfVQDfyyh9zk76NvkwCglIld CRcju0N8bLTtzmMxoj+HLQc= =f2gt -----END PGP SIGNATURE----- --0rEjiS+nMGFQ7Kkj-- From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 21:07:56 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Mon, 15 Mar 2004 16:07:56 -0500 Subject: [Calendula-devel] plans plans plans In-Reply-To: <1079377605.1305.44.camel@dhcppc4> References: <405592F0.19943.13AB010B@localhost> Message-ID: <4055D4DC.9896.14AC8400@localhost> On 15 Mar 2004 at 11:06, Darryl Caldwell wrote, in part: > 2. Design docs. First, do the requirements (REQ) look good to everyone? Donors are often drawn by tax advantages and concessions. For example, in Canada about 75% of one's donation to a registered political party is refundable at income tax time. Donors might be more willing to cough up again if reminded of benefits they'd had before. Perhaps we should consider providing for information about each donor with to tax. Bill From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 21:12:13 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Mon, 15 Mar 2004 16:12:13 -0500 Subject: [Calendula-devel] plans plans plans In-Reply-To: <1079377605.1305.44.camel@dhcppc4> References: <405592F0.19943.13AB010B@localhost> Message-ID: <4055D5DD.2665.14B06E2F@localhost> On 15 Mar 2004 at 11:06, Darryl Caldwell wrote: > > 3. Language: Python for flexibility, readability, and as my own safety net > (meaning if you all get hit by a bus, I need to be able to forge ahead). > wxPython has really good support for adopting a native look/feel, but this > will come after the Zope prototype. Multi-client systems are harder to build than those that are for single clients. What's more, we are likely to spend considerable time fooling with the GUI, and it might be unwise to need to drag a server along with us--_especially_ Zope. (Lots of people never get over the learning curve for that beasty.) Why not build a single-client version of the system first? One immediate payoff would be that it could be distributed to quite small non-profits (who are, after all, principal targets for the system), which would benefit them and give us a lot of feedback about usability and the like. Bill From tpanzarella@mac.com Mon Mar 15 21:31:59 2004 From: tpanzarella@mac.com (Thomas Panzarella) Date: Mon, 15 Mar 2004 16:31:59 -0500 Subject: [Calendula-devel] Calendula PR at NTEN / Penguin Day Message-ID: <10237726.1079386319840.JavaMail.tpanzarella@mac.com> On Monday, March 15, 2004, at 04:05PM, Benj. Mako Hill wrote: > >I'll be there as well. > Great. Let's meet up and chat. Also, if you are going to be in Philly on Sat night, there is an informal gathering called "Thirsty Penguins" the night before: http://www.dotorganics.org/~tpanzarella/blog/blosxom.cgi/2004/02/15#DrunkPenguins This is just a time to hang out, drink beer, and talk NGO open source. t. From darrylc@fudosys.com Mon Mar 15 23:31:54 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 15 Mar 2004 15:31:54 -0800 Subject: [Calendula-devel] GNUe analysis - might be helpful In-Reply-To: References: <1079379527.1305.72.camel@dhcppc4> Message-ID: <1079393514.1289.35.camel@dhcppc4> On Mon, 2004-03-15 at 12:34, Jason Maas wrote: > >Why GNUe isn't good for Calendula: > > > >* Poor documentation (the current developers prefer IRC) > >* Poor support (very little list traffic), limited adoption > > While those do raise red flags, I don't think they're show stoppers > because they're fairly easily remedied. They are show stoppers for me because it means that the development tools aren't mature enough to attract and sustain developers across a broad spectrum. > > >* Unstable framework > >* inflexible UI design > > These two are more interesting. Could you write a sentence or two about > each one explaining what you mean? For example, by "unstable" do you mean > that it crashes often or that the API changes daily...? > GNUe Designer crashed every time. The UI for GNUe Forms is pretty much set in stone. While it is nice to be able to whip up some xml and not have to worry about developing a whole app from the ground up, I'd rather control the look/feel decisions. > >A better analysis would be to look at the GNUMED project > >(www.gnumed.org). > > I poked around briefly on their website. I had never heard of the project > before but it does look interesting. What in particular should we look > at? * wxPython toolkit. * Client/Server model * Modular design * The database abstraction is similar to what you guys at DM have expressed an interest in. * Useful Design docs. * The UI offers a Python shell for interfacing with the guts of the system. -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Tue Mar 16 00:25:31 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 15 Mar 2004 16:25:31 -0800 Subject: [Calendula-devel] multiple clients In-Reply-To: <4055D5DD.2665.14B06E2F@localhost> References: <405592F0.19943.13AB010B@localhost> <4055D5DD.2665.14B06E2F@localhost> Message-ID: <1079396730.1288.58.camel@dhcppc4> Bill, I have had a client/server model in mind from the beginning. I envision this system going into an office of 8 desktops. Not everyone will use Calendula except one or two financial development officers and other staff doing data entry. Zope is the easiest thing I have ever installed and it has some built in user admin that will come in handy. I am not expecting nonprofit personnel to learn dtml or Zope Page Templates. After looking at the cool code you have written for upload PDFs into Zope for text searches in ZCatalogs, I am not worried about you. In regard to multiple clients, the dm.org guys have some good ideas using the Modeling framework. http://modeling.sourceforge.net/ And lastly, I am hopeful that a demo version of Morphix/Debian-NP loaded up with Calendula and supporting systems would fit the bill, Bill. -D On Mon, 2004-03-15 at 13:12, Bill Bell wrote: > On 15 Mar 2004 at 11:06, Darryl Caldwell wrote: > > > > 3. Language: Python for flexibility, readability, and as my own safety net > > (meaning if you all get hit by a bus, I need to be able to forge ahead). > > wxPython has really good support for adopting a native look/feel, but this > > will come after the Zope prototype. > > Multi-client systems are harder to build than those that are for single clients. What's > more, we are likely to spend considerable time fooling with the GUI, and it might be > unwise to need to drag a server along with us--_especially_ Zope. (Lots of people > never get over the learning curve for that beasty.) > > Why not build a single-client version of the system first? One immediate payoff would > be that it could be distributed to quite small non-profits (who are, after all, principal > targets for the system), which would benefit them and give us a lot of feedback about > usability and the like. > > Bill > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From tpanzarella@mac.com Tue Mar 16 01:18:53 2004 From: tpanzarella@mac.com (Thomas Panzarella) Date: Mon, 15 Mar 2004 20:18:53 -0500 Subject: [Calendula-devel] multiple clients Message-ID: <10053998.1079399933365.JavaMail.tpanzarella@mac.com> Once again, I am confused, sorry. (see below) > >I have had a client/server model in mind from the beginning. I envision >this system going into an office of 8 desktops. Not everyone will use >Calendula except one or two financial development officers and other >staff doing data entry. > >Zope is the easiest thing I have ever installed and it has some built in >user admin that will come in handy. I am not expecting nonprofit >personnel to learn dtml or Zope Page Templates. After looking at the >cool code you have written for upload PDFs into Zope for text searches >in ZCatalogs, I am not worried about you. > I have only minimal exposure to Zope, but does it support something other than HTTP? If not, why would we write a full blown (presumably) multi-threaded client that cannot maintain a persistent connection to the server? In this case, the desktop GUI seems pointless, dynamically rendered web pages would fit the bill just fine. > >In regard to multiple clients, the dm.org guys have some good ideas >using the Modeling framework. > >http://modeling.sourceforge.net/ > What does object / relational mapping have to do with clients? Object / relational mapping is a persistence tier issue and should be designed completely independent of any client code. Am I missing something? From darrylc@fudosys.com Tue Mar 16 18:51:00 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 16 Mar 2004 10:51:00 -0800 Subject: [Calendula-devel] Article Cleaned Up Message-ID: <1079463060.1293.20.camel@dhcppc4> I just spent a lot of time editing and cleaning up the business case article at http://fudosys.com/Calendula.html Use this one if you are printing copies to send to NPO peers.... -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From tpanzarella@mac.com Tue Mar 16 19:02:55 2004 From: tpanzarella@mac.com (Thomas Panzarella) Date: Tue, 16 Mar 2004 14:02:55 -0500 Subject: [Calendula-devel] Article Cleaned Up Message-ID: <11835203.1079463775545.JavaMail.tpanzarella@mac.com> Is this the latest version in CVS? On Tuesday, March 16, 2004, at 01:51PM, Darryl Caldwell wrote: >I just spent a lot of time editing and cleaning up the business case >article at http://fudosys.com/Calendula.html Use this one if you are >printing copies to send to NPO peers.... > >-D > > >-- >Darryl Caldwell darrylc@fudosys.com >Fudo Systems www.fudosys.com >206/567-5802 "Free Your Computers!" > >_______________________________________________ >Calendula-devel mailing list >Calendula-devel@fudosys.com >http://list.fudosys.com/mailman/listinfo/calendula-devel > > From darrylc@fudosys.com Tue Mar 16 19:05:38 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 16 Mar 2004 11:05:38 -0800 Subject: [Calendula-devel] Article Cleaned Up In-Reply-To: <11835203.1079463775545.JavaMail.tpanzarella@mac.com> References: <11835203.1079463775545.JavaMail.tpanzarella@mac.com> Message-ID: <1079463937.1292.26.camel@dhcppc4> This version is not in cvs yet. I am actually having a problem connecting to savannah from my corner of the world. Can any of you even get to the web site? -D On Tue, 2004-03-16 at 11:02, Thomas Panzarella wrote: > Is this the latest version in CVS? > > On Tuesday, March 16, 2004, at 01:51PM, Darryl Caldwell wrote: > > >I just spent a lot of time editing and cleaning up the business case > >article at http://fudosys.com/Calendula.html Use this one if you are > >printing copies to send to NPO peers.... > > > >-D > > > > > >-- > >Darryl Caldwell darrylc@fudosys.com > >Fudo Systems www.fudosys.com > >206/567-5802 "Free Your Computers!" > > > >_______________________________________________ > >Calendula-devel mailing list > >Calendula-devel@fudosys.com > >http://list.fudosys.com/mailman/listinfo/calendula-devel > > > > > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Tue Mar 16 20:59:51 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 16 Mar 2004 12:59:51 -0800 Subject: [Calendula-devel] multiple clients In-Reply-To: <10053998.1079399933365.JavaMail.tpanzarella@mac.com> References: <10053998.1079399933365.JavaMail.tpanzarella@mac.com> Message-ID: <1079470791.1293.76.camel@dhcppc4> Hi, Benevolent Dictator here. Sorry, I was trying to do too many things at once yesterday (and today). Let's set the mulitple client discussion aside for now. I want to keep this first round of Calendula development very simple. Until a working prototype (even a mediocre one) is out for all to see, this project is not get the attention it deserves. To wit, I will be polling you all for an inventory of your talents. I will be making requests of you coders for specific tasks. Baby steps..... -D On Mon, 2004-03-15 at 17:18, Thomas Panzarella wrote: > Once again, I am confused, sorry. (see below) > > > > >I have had a client/server model in mind from the beginning. I envision > >this system going into an office of 8 desktops. Not everyone will use > >Calendula except one or two financial development officers and other > >staff doing data entry. > > > >Zope is the easiest thing I have ever installed and it has some built in > >user admin that will come in handy. I am not expecting nonprofit > >personnel to learn dtml or Zope Page Templates. After looking at the > >cool code you have written for upload PDFs into Zope for text searches > >in ZCatalogs, I am not worried about you. > > > > I have only minimal exposure to Zope, but does it support something other than HTTP? If not, why would we write a full blown (presumably) multi-threaded client that cannot maintain a persistent connection to the server? In this case, the desktop GUI seems pointless, dynamically rendered web pages would fit the bill just fine. > > > > >In regard to multiple clients, the dm.org guys have some good ideas > >using the Modeling framework. > > > >http://modeling.sourceforge.net/ > > > > What does object / relational mapping have to do with clients? Object / relational mapping is a persistence tier issue and should be designed completely independent of any client code. Am I missing something? > > > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Wed Mar 17 18:38:28 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 17 Mar 2004 10:38:28 -0800 Subject: [Calendula-devel] Savannah Message-ID: <1079548708.1309.1.camel@dhcppc4> Heads up. Savannah is down. No word yet on why. -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From jamest@gnuenterprise.org Wed Mar 17 22:22:38 2004 From: jamest@gnuenterprise.org (James Thompson) Date: Wed, 17 Mar 2004 16:22:38 -0600 Subject: [Calendula-devel] re: GNUe analysis - might be helpful Message-ID: <200403171622.38896.jamest@gnuenterprise.org> Someone pointed out to me the mail below. So I figured I'd join and respond.... > Why GNUe isn't good for Calendula: > > * Poor documentation This is true. It's worse than I recall it being. I'll try and address that. > * Unstable framework I'm not sure which part of GNUe is being referred to here. I'm using gnue-common based apps 24/7 in local company that does business almost nationwide. They use gnue-forms based UIs daily to accomplish tasks, such as routing their incoming faxes (billings) to the appropriate customer accounts. > * Poor support (very little list traffic), We have gravitated toward IRC based support. This did make for poor list support. On the other hand if you catch a developer in IRC you can frequently get patches in minutes working in real time with the developers. > limited adoption This partially falls back on poor documentation. But any project, such as your own, will also have limited adoption at first. > * inflexible UI design I think this is where some of the confusion from the docs is hurting GNUe. All the gnue tools can be used separately. When using parts of GNUe you are not forced into things like using GNUe-Forms as your UI. GNUe-POS (available in our svn tree) is based upon gnue-common and wxPython. I'm currently building a web based project using mod_python, gnue-common, gnue-reports, etc. I may or may not add gnue-forms based administration forms. It's basically just another set of tools in your toolbox. > > them they said, "well that's how we like to work." > This may indeed be what you were told. If so then I'll apologize and try to explain a little. We constantly have people people drop by IRC telling us how we're doing things wrong. We've had people suggest we throw out 10s of thousands of lines of code to do things their way. Most the time they won't bother to learn our systems before doing so. Often times these same people are the ones that will never contribute anything. We've had people come in then quickly fork after telling us we're too slow. I don't think any single fork has ever survived. I think they tend to figure out that some of this stuff can't be written fast. And it's hard to find people willing to write business apps for free in their spare time. Anyway, after a while you tend to get a little touchy when people start to question the hows and whys. Call it burn out, apathy, whatever you'd like. I know it's not right, but we're all human. I'm not meaning to say that Darryl said anything wrong. It's probably more like he caught that grumpy old man GNUe in a bad mood. :) So, is GNUe right for your project. I really can't say as I don't know much about it. Savannah web seems to be down. IMHO though, using gnue common alone would save a project an amazing amount of development work. But I'm a little bias about that :) If you have any questions please feel free to ask me. I'll do what I can to answer them. Take Care, James From darrylc@fudosys.com Wed Mar 17 23:28:31 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 17 Mar 2004 15:28:31 -0800 Subject: [Calendula-devel] re: GNUe analysis - might be helpful In-Reply-To: <200403171622.38896.jamest@gnuenterprise.org> References: <200403171622.38896.jamest@gnuenterprise.org> Message-ID: <1079566110.1278.51.camel@dhcppc4> Hi James, I've been giving GNUe a hard time over on the gnue list these last few days. Thanks for coming to my house. (I've actually been playing with GNUe Designer these last 2 days, since Savannah has been down. I did follow your suggestion and install GNUe-Reports and now the wizard in Designer is working as expected.) I spent 2 weeks with 0.4.2 last year. You have come a long, long way since then. In my mind it is still questionable whether GNUe is right for Calendula. I really don't have time to experiment and hope it works out. I need to scratch my own itch and I need evidence of stability. You have said that GNUe is run under a needs-based development model and a IRC-based support model. So are many projects; but I venture that they all developed good foundations and communities because there was documentation early on. Look at Remi Delon's CherryPy (www.cherrypy.org). I don't want to rely on IRC for your support anymore than I want to rely on RedHat/SuSE/Mandrake for phone support. Email leaves a better audit trail, and a better basis for FAQs later on. If you want wider adoption, I suggest that one or all of the core GNUe developers stop writing apps for use in production (as you note below) and make documentation a priority. Every once in a while a GNUe developer will pop up on a list I am on, and will say, "Hey, why don't you use GNUe for your project?" I always complain about the lack of docs and visible signs of use. Show me, don't tell me. Less outreach, more support, please. Write some short guides, howtos, updated API docs, etc. You wrote a great email yesterday describing 4 quick steps to testing Designer. That was wonderful. Now write something describing how you created the apps you mentioned below. Other folks on the gnue list have supported my sentiments. I do really dig the concepts around GNUe. If I don't use it for Calendula, I can foresee using it for something else down the road. Thank you, thank you taking the time to join this list and for all of your support on your gnue list. You can find out more about Calendula at http://fudosys.com/Calendula.html. -Darryl ps> Did I mention that you should write more documentation? -D On Wed, 2004-03-17 at 14:22, James Thompson wrote: > Someone pointed out to me the mail below. So I figured I'd join and > respond.... > > > Why GNUe isn't good for Calendula: > > > > * Poor documentation > > This is true. It's worse than I recall it being. I'll try and address that. > > > * Unstable framework > > I'm not sure which part of GNUe is being referred to here. I'm using > gnue-common based apps 24/7 in local company that does business almost > nationwide. They use gnue-forms based UIs daily to accomplish tasks, such as > routing their incoming faxes (billings) to the appropriate customer accounts. > > > * Poor support (very little list traffic), > > We have gravitated toward IRC based support. This did make for poor list > support. On the other hand if you catch a developer in IRC you can > frequently get patches in minutes working in real time with the developers. > > > limited adoption > > This partially falls back on poor documentation. But any project, such as > your own, will also have limited adoption at first. > > > * inflexible UI design > > I think this is where some of the confusion from the docs is hurting GNUe. > All the gnue tools can be used separately. When using parts of GNUe you are > not forced into things like using GNUe-Forms as your UI. GNUe-POS (available > in our svn tree) is based upon gnue-common and wxPython. I'm currently > building a web based project using mod_python, gnue-common, gnue-reports, > etc. I may or may not add gnue-forms based administration forms. It's > basically just another set of tools in your toolbox. > > > > > them they said, "well that's how we like to work." > > > > This may indeed be what you were told. If so then I'll apologize and try to > explain a little. We constantly have people people drop by IRC telling us > how we're doing things wrong. We've had people suggest we throw out 10s of > thousands of lines of code to do things their way. Most the time they won't > bother to learn our systems before doing so. Often times these same people > are the ones that will never contribute anything. We've had people come in > then quickly fork after telling us we're too slow. I don't think any single > fork has ever survived. I think they tend to figure out that some of this > stuff can't be written fast. And it's hard to find people willing to write > business apps for free in their spare time. > > Anyway, after a while you tend to get a little touchy when people start to > question the hows and whys. Call it burn out, apathy, whatever you'd like. I > know it's not right, but we're all human. I'm not meaning to say that Darryl > said anything wrong. It's probably more like he caught that grumpy old man > GNUe in a bad mood. :) > > So, is GNUe right for your project. I really can't say as I don't know much > about it. Savannah web seems to be down. IMHO though, using gnue common > alone would save a project an amazing amount of development work. But I'm a > little bias about that :) > > If you have any questions please feel free to ask me. I'll do what I can to > answer them. > > Take Care, > James > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From jamest@gnuenterprise.org Thu Mar 18 22:04:38 2004 From: jamest@gnuenterprise.org (James Thompson) Date: Thu, 18 Mar 2004 16:04:38 -0600 Subject: Fwd: Re: [Calendula-devel] re: GNUe analysis - might be helpful Message-ID: <200403181604.38801.jamest@gnuenterprise.org> --MIMEStream=_0+280555_9889177954383_63240525731 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I accidentally forgot to CC the list on this message this AM. --MIMEStream=_0+280555_9889177954383_63240525731 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Description: James Thompson : Re: [Calendula-devel] re: GNUe analysis - might be helpfu From: James Thompson To: Darryl Caldwell Subject: Re: [Calendula-devel] re: GNUe analysis - might be helpful Date: Thu, 18 Mar 2004 11:19:04 -0600 User-Agent: KMail/1.6.1 References: <200403171622.38896.jamest@gnuenterprise.org> <1079566110.1278.51.camel@dhcppc4> In-Reply-To: <1079566110.1278.51.camel@dhcppc4> Message-Id: <200403181119.04423.jamest@gnuenterprise.org> X-UID: 131 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline > I've been giving GNUe a hard time over on the gnue list these last few > days. Thanks for coming to my house. Ooooo, sorry about the mud on the carpet. > I spent 2 weeks with 0.4.2 last year. You have come a long, long way > since then. In my mind it is still questionable whether GNUe is right > for Calendula. I really don't have time to experiment and hope it works > out. I need to scratch my own itch and I need evidence of stability. You I understand the itch thing. However on the stability front I'd like to point out that gnue is in use in real world, money making situations. Specific parts of gnue are tested daily and people are paying for gnue based solutions that work. If you are thinking of creating a solution written completely from scratch then it is quite possible the initial code would be less stable than what another project (GNUe or something else) would provide. > I don't want to rely on IRC for your support anymore than I want to rely > on RedHat/SuSE/Mandrake for phone support. Email leaves a better audit > trail, and a better basis for FAQs later on. We are going to try and be more responsive to email support as the traffic the last few days have show people are interested. > If you want wider adoption, I suggest that one or all of the core GNUe > developers stop writing apps for use in production (as you note below) > and make documentation a priority. It's so easy to say this. Its so much harder in real life. Most if not all the developers are working on gnue features based upon needs. Those needs usually relate to either deadlines and work or money from a client. I know in my case a client doesn't care if X is fully documented, they only want X working, yesterday. That being said, i did reread our documentation (i typically don't have to :) and see it is hideously outdated and incomplete. I have shifted more of my time towards proper documenation and will be posting a least the start of something to our list later today. > tell me. Less outreach, more support, please. Write some short guides, > howtos, updated API docs, etc. You wrote a great email yesterday > describing 4 quick steps to testing Designer. That was wonderful. Now In progress. If fact, late last year we started adding epydoc comments to all our applications to cover the API front. They are far from complete but you can see the starting samples at http://www.gnuenterprise.org/~jamest/apis/ Again its partially a communications issue on our part. The developers know this is in progress but it hasn't been well communicated to the list. > > Thank you, thank you taking the time to join this list and for all of > your support on your gnue list. No problem. The list activity at gnue has been a bit of a wake up call for me. When GNUe was founded it was never my intention for things to become as closed as they have. I plan to take the steps needed to show we're not a dead project as many believe >You can find out more about Calendula at http://fudosys.com/Calendula.html. Like I have time to read web sites. I've got docs to write! j/k I'll check it out this weekend =) Take Care, James --MIMEStream=_0+280555_9889177954383_63240525731-- From pattonm@dm.org Thu Mar 18 22:43:12 2004 From: pattonm@dm.org (Matthew Patton) Date: Thu, 18 Mar 2004 17:43:12 -0500 (EST) Subject: [Calendula-devel] DiscipleMakers weigh-in Message-ID: Hi Darryl et al, Tom Hallman and I (two full-time developers) work for a Christian Campus ministry called DiscipleMakers, and we have a need for a software package like Calendula for managing our supporters, and we are committed to working towards an open source solution to our needs. We have made some decisions recently regarding our future development work that I wanted to share with you all. To begin meeting our needs, we have been developing for some time an enterprise application toolkit that will enable us to write the software we need. There is a first generation version of this available at doulos.sourceforge.net that we have successfully used to create and deploy a Conference Registration application. However, what you will find there is far inferior to what we have been researching and planning for the past several months. Doulos is a PHP Web Application Framework. Our current work will be to create an enterprise application toolkit (yet to be named, sourceforge page coming very soon) that will be written primarily in python. I have explained this at length in a previous post which I can resend to any who are interested (no archives anymore of old mailing list, Darryl?). You are probably groaning right now and writing us off as dreamers who won't have anything workable in a long time. However, we are taking the approach that if anything else is already written, don't rewrite it. Below is an overview of our architecture as we currently have conceived it, with the parts that are already written (i.e., other mature projects) specified: Client (web client, native app client, etc) -View (HTML, GTK, etc.) -Control (code that calls business logic) | RPC Protocol (our own super-protocol that would extend a lower protocol like XML-RPC to enable objects to be sent back and forth) -Client Translator -Lower level RPC protocol (either XML-RPC (nice python library already written, xmlrpclib), SOAP, etc. or just a direct local call) -Server Translator | Server (running in Zope or just used as a local library) -Business Logic Framework (code that uses modeling and other data access layers) -Modeling (modeling.sourceforget.net) object/relational bridge, other Data source-to-object layers | Low Level Data Sources -DB's, LDAP, etc. (where the data is actually stored, these are already written (MySQL, Postgres, etc)) Since we are using powerful, mature tools like Zope, Modeling, xmlrpclib, and Open Source DB's, our todo list is just the relatively lightweight frameworks and glue layers to make the hefty tools work together. The total list is: 1. Client Frameworks I know of one good GTK possibility that I have to research more, and there are many good Python Web Application Frameworks that can possibly be tweaked for our needs, so I am hoping not to need to write these. But even if I do, I have a lot of experience from writing Doulos and could develop a web app framework quickly enough. 2. Client/Server Translators These will enable us to speak our high-level protocol and that will expand just slightly basic RPC protocols like XML-RPC. These will be very thin and very lightweight. 3. Business Logic Framework This defines the basic API for interacting on a high level with the low-level data storage software (like SQL DB's). This is also going to be quite lightweight and will just offer some handy abstractions for writing common business logic code. Modeling, a relational DB to object mapper for python, will do most of the work for us and save us from writing a line of SQL. Since these three things are so small, we could have the first version of the tools that we need in short order (hopefully a month or two) and start writing the REAL code. As for this REAL code, the real code that we need the soonest is a replacement for our current receipting system. As a result, we will be developing this first and using it as real-life test case for our enterprise application toolkit. The tools will really be worth using after they have gone through the rigors of their first application, and this app isn't going to be too big, so it won't be too long before the tools reach this maturity (hopefully several months). I see this receipting system as being a module for the core CRM that you are looking to develop, and they could be easily merged, but only if we work from the same toolkit. So I wanted to let you all know that this is a possibility, and see what you thought. Thanks, Matt ______________________________________________________________ Matthew Patton pattonm@dm.org DiscipleMakers Headquarters: (814)234-7975 x32 From darrylc@fudosys.com Fri Mar 19 22:38:48 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 19 Mar 2004 14:38:48 -0800 Subject: [Calendula-devel] Savannah Message-ID: <1079735927.1456.6.camel@dhcppc4> Hi, savannah.gnu.org is back in business. I added the workflow diagram and updated the article to the latest version. http://savannah.gnu.org/projects/calendula -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Sat Mar 20 23:52:37 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: Sat, 20 Mar 2004 15:52:37 -0800 (PST) Subject: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: References: Message-ID: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> > As for this REAL code, the real code that we need the soonest is a > replacement for our current receipting system. As a result, we will be > developing this first and using it as real-life test case for our > enterprise application toolkit. The tools will really be worth using > after they have gone through the rigors of their first application, and > this app isn't going to be too big, so it won't be too long before the > tools reach this maturity (hopefully several months). > I see this receipting system as being a module for the core CRM > that you are looking to develop, and they could be easily merged, but only > if we work from the same toolkit. So I wanted to let you all know that > this is a possibility, and see what you thought. Thanks for the overview, Matt. Could you by chance provide us with a simple use case for this receipting system. I am trying to visualize how this would fit into a CRM. -D -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From elwell642@hotmail.com Sun Mar 21 01:40:42 2004 From: elwell642@hotmail.com (Tom Hallman) Date: Sat, 20 Mar 2004 20:40:42 -0500 Subject: [Calendula-devel] DiscipleMakers weigh-in Message-ID: Darryl, >Thanks for the overview, Matt. Could you by chance provide >us with a simple use case for this receipting system. I am trying to >visualize how this would fit into a CRM. Currently, most staff workers in DiscipleMakers have some form of CRM (often Goldmine) to manage their donors, but a record of each donor's gift must be looked up separately (Excel/OpenOffice spreadsheet, etc.) This is a silly distinction, since both the CRM and "donor list" are using the same conceptual entities. Let's say that Matt Patton is supported financially by Jim Smith. A very useful feature for Matt would be to be able to pull up Jim's record (containing his name, his wife's name, their address, notes from their last meeting together, etc.) right alongside a list of all the financial gifts that Jim has given (including dates and amounts.) This last information would have been entered via the receipting system in the Headquarters. I hope this is helpful! ~Tom _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page – FREE download! http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/ From bill-bell@bill-bell.hamilton.on.ca Sun Mar 21 13:13:43 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Sun, 21 Mar 2004 08:13:43 -0500 Subject: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: Message-ID: <405D4EB7.4244.31E16F89@localhost> On 20 Mar 2004 at 20:40, Tom Hallman wrote, in part: > Currently, most staff workers in DiscipleMakers have some form of CRM > (often Goldmine) to manage their donors ... Would it be possible for you to indicate which Goldmine features are the most heavily used? > I hope this is helpful! Well _I_ find it interesting. Thanks! Bill From maasj@dm.org Mon Mar 22 01:32:22 2004 From: maasj@dm.org (Jason Maas) Date: Sun, 21 Mar 2004 20:32:22 -0500 (EST) Subject: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> References: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> Message-ID: Hi Darryl, On Sat, 20 Mar 2004, Darryl Caldwell wrote: >Thanks for the overview, Matt. Could you by chance provide us with a >simple use case for this receipting system. I am trying to visualize how >this would fit into a CRM. I'll throw in a little more to try and clarify things. By "receipting" what we mean is the software that our secretaries use to handle contributions (donations) that come to our headquarters, usually in the form of checks. They use the software to enter in who the gift was from, who it's for, and then print a receipt to mail to the donor (hence the name "receipting"). It would be great for this "receipting" system to tie into our CRM software so all of our staff (most are remote) would automatically see all the gifts a contact has given when they look up a person's record in the CRM software. The basic idea we have is to have this big database of people that all of our software ties into, instead of our current situation of separate software for the donations, CRM, event/conference management, etc. I hope that makes sense. -Jason From darrylc@fudosys.com Mon Mar 22 04:25:23 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: Sun, 21 Mar 2004 20:25:23 -0800 (PST) Subject: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: References: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> Message-ID: <37741.64.38.161.33.1079929523.squirrel@webmail.fudosys.com> Thanks Jason and Tom, The use case you outlined is right in line with the REQ doc that I have written for Calendula. Many donors hang on to "thank-you" letters from charities and other NPOs for their tax records. You all can view the REQ in the CVS repository or send me a note and I will attach it to an email message to you. NOW would be a good time to read through the REQ to see if it is missing something obvious. It also contains good talking points for you consultants out there that deal with nonprofits on a regular basis, and especially all of you on your way to NTEN/Penguinday. -D > Hi Darryl, > > On Sat, 20 Mar 2004, Darryl Caldwell wrote: > >>Thanks for the overview, Matt. Could you by chance provide us with a >>simple use case for this receipting system. I am trying to visualize how >>this would fit into a CRM. > > I'll throw in a little more to try and clarify things. By "receipting" > what we mean is the software that our secretaries use to handle > contributions (donations) that come to our headquarters, usually in the > form of checks. They use the software to enter in who the gift was from, > who it's for, and then print a receipt to mail to the donor (hence > the name "receipting"). It would be great for this "receipting" system to > tie into our CRM software so all of our staff (most are remote) would > automatically see all the gifts a contact has given when they look up a > person's record in the CRM software. > > The basic idea we have is to have this big database of people that all of > our software ties into, instead of our current situation of separate > software for the donations, CRM, event/conference management, etc. > > I hope that makes sense. > > -Jason > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel > -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From pattonm@dm.org Tue Mar 23 15:11:39 2004 From: pattonm@dm.org (Matthew Patton) Date: Tue, 23 Mar 2004 10:11:39 -0500 (EST) Subject: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: <37741.64.38.161.33.1079929523.squirrel@webmail.fudosys.com> References: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> <37741.64.38.161.33.1079929523.squirrel@webmail.fudosys.com> Message-ID: Hi Darryl, You asked that we view the REQ document in the CVS repository. I've done that and compared it with the requirements document we have here at DM for our receipting system. The following are things that you didn't have that we will need: Functionality ============= -There will be remote users whose user account will be associated with a certain fund (in our case, remote staff who each have a fund that their supporters give to). These users will need to be able to view certain reports: a. View gifts for their respective funds b. View a donor's contact information c. View an account's giving history (for what an account is, see "Data" below) d. Eventually it will be necessary to have the data that these remote users have about their donors (contact information, personal notes, relationship history) sync'd up with this central DB that stores the gifts that come in, but this is an advanced feature that can wait -The main kind of user, however, will be the administrator. In addition to the functionality you mention, the system will need to provide the admin with the following functionality: Deposits (see below under "Data" what for what a deposit is) a. add/mod deposit: i. add/mod Transactions 1. add/mod accounts ii. del Transactions iii. Print / Email receipts 1. Individual receipts 2. All in batch iv. Email to owners of funds a list of contributions they have received b. Reports i. Bank report Transactions a. Search for transactions Funds a. add/mod/del funds, owners b. Reports i. History Data ==== 1. Deposit - one batch of transactions (mainly checks) processed at a time (usually to go to the bank) a. Name b. Creation date c. Transactions in this deposit (see Transaction) d. Note 2. Transaction - one monetary event where money goes from an account to a fund a. Which account is sending money (see Account) b. Line items: i. Which fund is receiving money (see Fund) ii. Amount of money iii. Whether tax deductible c. Type Check i. Check number ii. Name of institution on check iii. Name on check iv. Routing number v. Account number for check vi. Who actually cut the check (used when a gift is given from a business) Money Order i. Who actually cut the money order Cash [No additional data] Electronic Fund Transfer (EFT) i. Name of institution ii. Routing number iii. Account number? d. Note 3. Account (not sure if this is the right technical accounting term for this) - a single money-sending entity. Examples would be: 1. An individual (e.g., "Joe Smith") 2. A couple (e.g., "Joe & Sue Smith") 3. A family (e.g., "The Smiths") 4. A company (e.g., "Smith's Grocery, Inc.") 5. A church/organization (e.g., "First Presbyterian Church") The data for an account would be: a. Which donor(s) own this account For each donor: i. Name ii. Sortname iii. Gender iv. Contact Information 1. Address 2. Phone number 3. E-mail address b. Note 4. Fund - a single money-receiving entity. Examples would be: 1. An individual staff (e.g., "Joe Staff") 2. A staff couple or family (e.g., "Joe & Sue Staff") 3. An organization-wide fund (e.g., "Conferences") The data for a fund would be: a. Name b. id of fund in accounting software package (we use Peachtree, and would need to export from this receipting system the total received for each fund and import those totals into the accounting system) c. Whether tax deductible d. Owners of fund e. Whether the fund is active f. Note =================== There may be some overlap in what I have shared with what you have in your Requirements Doc, Darryl, but I tried to minimize that. Let me know your thoughts! Matt ______________________________________________________________ Matthew Patton pattonm@dm.org DiscipleMakers Headquarters: (814)234-7975 x32 On Sun, 21 Mar 2004, Darryl Caldwell wrote: > Thanks Jason and Tom, > > The use case you outlined is right in line with the REQ doc that I have > written for Calendula. Many donors hang on to "thank-you" letters from > charities and other NPOs for their tax records. > > You all can view the REQ in the CVS repository or send me a note and I > will attach it to an email message to you. > > NOW would be a good time to read through the REQ to see if it is missing > something obvious. It also contains good talking points for you > consultants out there that deal with nonprofits on a regular basis, and > especially all of you on your way to NTEN/Penguinday. > > > -D > > > > > > Hi Darryl, > > > > On Sat, 20 Mar 2004, Darryl Caldwell wrote: > > > >>Thanks for the overview, Matt. Could you by chance provide us with a > >>simple use case for this receipting system. I am trying to visualize how > >>this would fit into a CRM. > > > > I'll throw in a little more to try and clarify things. By "receipting" > > what we mean is the software that our secretaries use to handle > > contributions (donations) that come to our headquarters, usually in the > > form of checks. They use the software to enter in who the gift was from, > > who it's for, and then print a receipt to mail to the donor (hence > > the name "receipting"). It would be great for this "receipting" system to > > tie into our CRM software so all of our staff (most are remote) would > > automatically see all the gifts a contact has given when they look up a > > person's record in the CRM software. > > > > The basic idea we have is to have this big database of people that all of > > our software ties into, instead of our current situation of separate > > software for the donations, CRM, event/conference management, etc. > > > > I hope that makes sense. > > > > -Jason > > _______________________________________________ > > Calendula-devel mailing list > > Calendula-devel@fudosys.com > > http://list.fudosys.com/mailman/listinfo/calendula-devel > > > > > -- > Darryl Caldwell > darrylc@fudosys.com > www.fudosys.com > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel > From darrylc@fudosys.com Wed Mar 24 23:14:36 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 24 Mar 2004 15:14:36 -0800 Subject: [Calendula-devel] Interesting FLOSS project Message-ID: <1080170075.1282.12.camel@dhcppc4> Peter Hollings sent me this info: The federal Department of Housing and Urban Development (HUD) is requiring all communities that receive HUD funding (the vast majority) to implement a Homeless Management Information System (HMIS) by the end of 2004.* Homeless shelters will be entering client information into these HMIS databases, and in return communities will get unduplicated counts of homeless persons served, electronic case management tools, and better planning information. Several communities in Washington State have banded together to create an open source HMIS, the latest version of which can viewed/demoed/downloaded from: http://homeless-mis.net/ Although there are several commercial HMIS systems, as far as I know the open source HMIS is the only one fully compliant with the HUD draft HMIS Data Standard (http://www.hud.gov/offices/cpd/homeless/hmis/). -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From maasj@dm.org Fri Mar 26 16:05:02 2004 From: maasj@dm.org (Jason Maas) Date: Fri, 26 Mar 2004 11:05:02 -0500 (EST) Subject: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: <405D4EB7.4244.31E16F89@localhost> References: <405D4EB7.4244.31E16F89@localhost> Message-ID: Hi Bill, On Sun, 21 Mar 2004, Bill Bell wrote: >Would it be possible for you to indicate which Goldmine features are the >most heavily used? We have different groups of users based on their dependence on Goldmine (GM) and their proficiency with it. We have a few "power users" of Goldmine who are starting to using the Goldmine synchronization feature (marketed as GoldSync) to collect all their data together. Those users use it as their email client because it then associates emails with their contacts. They use the "notes" fields heavily and also the calendar. Another much-loved feature is the ability to use a modem to dial phone numbers for voice calls (thus avoiding mis-dialing). Most of our staff who use GM just use it as a PIM which can also manage snail mail (i.e. print labels) and email lists for mass mailings to their donors. If we could cover those uses and also tie it in to our donation-handing system (aka "receipting") that would be a great start. >Well _I_ find it interesting. Do you have Goldmine experience? Jason From bill-bell@bill-bell.hamilton.on.ca Fri Mar 26 18:03:43 2004 From: bill-bell@bill-bell.hamilton.on.ca (Bill Bell) Date: Fri, 26 Mar 2004 13:03:43 -0500 Subject: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: References: <405D4EB7.4244.31E16F89@localhost> Message-ID: <40642A2F.24248.130D9F96@localhost> On 26 Mar 2004 at 11:05, Jason Maas wrote: > On Sun, 21 Mar 2004, Bill Bell wrote: > > >Would it be possible for you to indicate which Goldmine features are the > >most heavily used? > > Do you have Goldmine experience? I tried it out a few years ago, that's it! It just seemed to me that it would be valuable to know about how actual users might employ the thingy we're thinking of building. Thanks for the information. Bill From darrylc@fudosys.com Tue Mar 30 22:25:07 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 30 Mar 2004 14:25:07 -0800 Subject: [Calendula-devel] quickbooks? Message-ID: <1080685501.2569.29.camel@dhcppc4> Hi all, Does anyone out there have a connection with a nonprofit that uses Quickbooks for nonprofits? I am just wondering how prevalent it is. This link is interesting: www.nonprofitbooks.com Has anyone looked at GNUCash and thought about its viability in a NPO setting? Also, there was some discussion here of the contact management side of a fundraising system. Notable items mentioned are Act! and Goldmine. I did a little snooping on the net. Ideas? Take a look at the demo I found: http://www.absolutebusy.com/contact_manager.html (proprietary, uses mysql, demo online) Found the following link to Contract Pro Plus, a WinX app. The page contains some interesting flash demos of their system. Great screenshots. http://www.contactplus.com/products/pro/promain.htm -Darryl -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From maasj@dm.org Wed Mar 31 02:43:59 2004 From: maasj@dm.org (Jason Maas) Date: Tue, 30 Mar 2004 21:43:59 -0500 (EST) Subject: [Calendula-devel] Penguin Day & NTEN report? Message-ID: Hi all, Anyone here make it to NTEN & Penguin Day? If so, what were some of the highlights? -Jason From maasj@dm.org Wed Mar 31 03:44:02 2004 From: maasj@dm.org (Jason Maas) Date: Tue, 30 Mar 2004 22:44:02 -0500 (EST) Subject: [Calendula-devel] quickbooks? In-Reply-To: <1080685501.2569.29.camel@dhcppc4> References: <1080685501.2569.29.camel@dhcppc4> Message-ID: Hi Darryl, On Tue, 30 Mar 2004, Darryl Caldwell wrote: >Does anyone out there have a connection with a nonprofit that uses >Quickbooks for nonprofits? I am just wondering how prevalent it is. Not us, we are just making do with "Peachtree Complete Accounting" software for Windows (under VMWare, storing the data using Samba). It's not designed for non-profits. >Has anyone looked at GNUCash and thought about its viability in a NPO >setting? Yes! I've used GNUCash for my personal finances for about 3.5 years now. Last summer we had a couple interns with accounting degrees investigate the various OSS options for replacing Peachtree as our accounting package. They decided that there was nothing worthwhile out there, but we've since learned that people with an accounting degree and experience using shiny proprietary accounting software tend to look for certain labels and buttons. It seems that the different flavors of most commercial accounting packages all basically do the same things, but they'll be tailored for a certain market (i.e. churches/nonprofits, small retail stores, etc) and the software will have certain labels & buttons to match the target market. OSS like GNUCash is designed to be more generic and work in different markets and countries, etc. so it doesn't have special "non-profit" buttons. But I think it can do everything we do as a small non-profit. One bummer about GnuCash is that it currently only supports a single user making changes to your data. They've done some work on using an RDBMS back-end to support multiple users working on the data at the same time, but I believe that code is out of date and not complete. Another package I want to look at more is SQL-Ledger (www.sql-ledger.org) which is a web-app accounting package designed for small businesses. It can handle multiple concurrent users. Neither of those applications has an integrated payroll system for handling the paying of employees and all the taxes and fees that need to be taken out of their gross salary. But that doesn't mean that you can't use them for your payroll! Here are a couple links that discuss how to use GnuCash for payroll: http://www.gnucash.org/docs/v1.8/C/gnucash-guide/chapter14.html http://www.aerospacesoftware.com/GNU_Cash_for_Business_users_Howto_Guide.html Another option is to outsource your payroll calculations & check >http://www.absolutebusy.com/contact_manager.html (proprietary, uses >mysql, demo online) Looks a little bit interesting, but it's not nearly as featureful as Goldmine. >Found the following link to Contract Pro Plus, a WinX app. The page >contains some interesting flash demos of their system. Great >screenshots. > >http://www.contactplus.com/products/pro/promain.htm I didn't look at any of the Flash movies (blech), but I did skim through some of the info about the program, and it sounds very similar to Goldmine in purpose, scope, and pricing. It even sounds better than Goldmine in some ways (better security controls over data in a multi-user environment). This is the kind of app that an organization like DiscipleMakers would like as OSS someday. We don't have a "sales force", but all of our staff do fund raising which looks a lot like sales from a software point of view. We need a good tool to allow our staff to share information their contacts, especially in the common situation where multiple staff know a specific donor and want to see all interaction with that donor. Jason From phollings@ipt.org Wed Mar 31 18:49:31 2004 From: phollings@ipt.org (Peter Hollings) Date: Wed, 31 Mar 2004 13:49:31 -0500 Subject: [Calendula-devel] RE: Calendula-devel digest, Vol 1 #16 - 3 msgs In-Reply-To: <20040331180001.31300.19952.Mailman@slice.riposte.org> Message-ID: <005101c41750$e791a180$8964a8c0@IPT11> Many non-profits have a fundamental difference in their accounting methods from commercial enterprises. They do something called "fund accounting". Basically, what this means is that they set aside some funds earmarked for specific purposes (such as an university endowment for scholarships) and then they account for the income and expenditure of the fund. This is in addition from the organization's "general accounting".=20 Since many NPOs operate on grants, you might also consider what kind of financial recordkeeping/report making would be required.=20=20 Peter Hollings -----Original Message----- From: calendula-devel-admin@fudosys.com [mailto:calendula-devel-admin@fudosys.com] On Behalf Of calendula-devel-request@fudosys.com Sent: Wednesday, March 31, 2004 1:00 PM To: calendula-devel@fudosys.com Subject: Calendula-devel digest, Vol 1 #16 - 3 msgs Send Calendula-devel mailing list submissions to calendula-devel@fudosys.com To subscribe or unsubscribe via the World Wide Web, visit http://list.fudosys.com/mailman/listinfo/calendula-devel or, via email, send a message with subject or body 'help' to calendula-devel-request@fudosys.com You can reach the person managing the list at calendula-devel-admin@fudosys.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Calendula-devel digest..." Today's Topics: 1. quickbooks? (Darryl Caldwell) 2. Penguin Day & NTEN report? (Jason Maas) 3. Re: quickbooks? (Jason Maas) --__--__-- Message: 1 From: Darryl Caldwell To: caldev Organization: Fudo Systems Date: 30 Mar 2004 14:25:07 -0800 Subject: [Calendula-devel] quickbooks? Hi all, Does anyone out there have a connection with a nonprofit that uses Quickbooks for nonprofits? I am just wondering how prevalent it is. This link is interesting: www.nonprofitbooks.com Has anyone looked at GNUCash and thought about its viability in a NPO setting? Also, there was some discussion here of the contact management side of a fundraising system. Notable items mentioned are Act! and Goldmine. I did a little snooping on the net.=20 Ideas? Take a look at the demo I found: http://www.absolutebusy.com/contact_manager.html (proprietary, uses mysql, demo online) Found the following link to Contract Pro Plus, a WinX app. The page contains some interesting flash demos of their system. Great screenshots. http://www.contactplus.com/products/pro/promain.htm -Darryl --=20 Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" --__--__-- Message: 2 Date: Tue, 30 Mar 2004 21:43:59 -0500 (EST) From: Jason Maas To: calendula-devel@fudosys.com Subject: [Calendula-devel] Penguin Day & NTEN report? Hi all, Anyone here make it to NTEN & Penguin Day? If so, what were some of the highlights? -Jason --__--__-- Message: 3 Date: Tue, 30 Mar 2004 22:44:02 -0500 (EST) From: Jason Maas To: Darryl Caldwell Cc: caldev Subject: Re: [Calendula-devel] quickbooks? Hi Darryl, On Tue, 30 Mar 2004, Darryl Caldwell wrote: >Does anyone out there have a connection with a nonprofit that uses >Quickbooks for nonprofits? I am just wondering how prevalent it is. Not us, we are just making do with "Peachtree Complete Accounting" software for Windows (under VMWare, storing the data using Samba). It's not designed for non-profits. >Has anyone looked at GNUCash and thought about its viability in a NPO >setting? Yes! I've used GNUCash for my personal finances for about 3.5 years now. Last summer we had a couple interns with accounting degrees investigate the various OSS options for replacing Peachtree as our accounting package. They decided that there was nothing worthwhile out there, but we've since learned that people with an accounting degree and experience using shiny proprietary accounting software tend to look for certain labels and buttons. It seems that the different flavors of most commercial accounting packages all basically do the same things, but they'll be tailored for a certain market (i.e. churches/nonprofits, small retail stores, etc) and the software will have certain labels & buttons to match the target market. OSS like GNUCash is designed to be more generic and work in different markets and countries, etc. so it doesn't have special "non-profit" buttons. But I think it can do everything we do as a small non-profit. One bummer about GnuCash is that it currently only supports a single user making changes to your data. They've done some work on using an RDBMS back-end to support multiple users working on the data at the same time, but I believe that code is out of date and not complete. Another package I want to look at more is SQL-Ledger (www.sql-ledger.org) which is a web-app accounting package designed for small businesses. It can handle multiple concurrent users. Neither of those applications has an integrated payroll system for handling the paying of employees and all the taxes and fees that need to be taken out of their gross salary. But that doesn't mean that you can't use them for your payroll! Here are a couple links that discuss how to use GnuCash for payroll: http://www.gnucash.org/docs/v1.8/C/gnucash-guide/chapter14.html http://www.aerospacesoftware.com/GNU_Cash_for_Business_users_Howto_Guide .html Another option is to outsource your payroll calculations & check >http://www.absolutebusy.com/contact_manager.html (proprietary, uses >mysql, demo online) Looks a little bit interesting, but it's not nearly as featureful as Goldmine. >Found the following link to Contract Pro Plus, a WinX app. The page >contains some interesting flash demos of their system. Great >screenshots. > >http://www.contactplus.com/products/pro/promain.htm I didn't look at any of the Flash movies (blech), but I did skim through some of the info about the program, and it sounds very similar to Goldmine in purpose, scope, and pricing. It even sounds better than Goldmine in some ways (better security controls over data in a multi-user environment). This is the kind of app that an organization like DiscipleMakers would like as OSS someday. We don't have a "sales force", but all of our staff do fund raising which looks a lot like sales from a software point of view. We need a good tool to allow our staff to share information their contacts, especially in the common situation where multiple staff know a specific donor and want to see all interaction with that donor. Jason --__--__-- _______________________________________________ Calendula-devel mailing list Calendula-devel@fudosys.com http://list.fudosys.com/mailman/listinfo/calendula-devel End of Calendula-devel Digest From robergb@dm.org Wed Mar 31 19:55:39 2004 From: robergb@dm.org (Brian Roberg) Date: Wed, 31 Mar 2004 14:55:39 -0500 Subject: [Calendula-devel] Accounting software In-Reply-To: <005101c41750$e791a180$8964a8c0@IPT11> References: <20040331180001.31300.19952.Mailman@slice.riposte.org> <005101c41750$e791a180$8964a8c0@IPT11> Message-ID: <20040331195539.GC27963@dm.org> On Wed, Mar 31, 2004 at 01:49:31PM -0500, Peter Hollings wrote: > Many non-profits have a fundamental difference in their accounting > methods from commercial enterprises. They do something called "fund > accounting". Basically, what this means is that they set aside some > funds earmarked for specific purposes (such as an university endowment > for scholarships) and then they account for the income and expenditure > of the fund. This is in addition from the organization's "general > accounting". I'm glad you mention this, because it highlights the uncertainty and frustration that we (a small non-profit organization) have faced with respect to accounting software. When I went to the Christian Management Association conference last year, I heard all about "fund accounting" and was concerned because our software wasn't geared to do that. But I'm a sysadmin, not an accountant, so I didn't understand what everything meant. In fact, like most non-profits our size (I'd imagine), we don't have a full-time accountant. Thus none of us understand these accounting terms with any real precision. We just get by doing what we need to do. In fact, I've had trouble understanding what exactly makes fund accounting qualitatively different from what a for-profit company would use. By the definition you provided, we do fund accounting. But some accountant-types who've worked with us say what we're doing is not fund accounting. Jason was expressing the tentative conclusion we've reached, namely that people with formal training in accounting look for very particular things when they evaluate accounting software. For example, one of the guys who helped us last summer has a Master's degree in accounting. He said that GNUCash wasn't suitable for use because it doesn't have a "Chart of Accounts." He's right that it doesn't have a button that says "Chart of Accounts." But it does let you organize accounts hierarchically, manage amounts for each independently, assign codes for each account, etc. The capability is there, but the presentation of the data is not what an accountant would expect. True, it would be better if we had a system that presented things using the same terminology as the regulations we're trying to follow. But we don't have the money to buy such a system, and if GNUCash can do the same thing (if not using the right words), we'll go with that. If anyone is an expert in both accounting and GNUCash, I would love to know whether our assessment is accurate. > Since many NPOs operate on grants, you might also consider what kind of > financial recordkeeping/report making would be required. Definitely. This is very important. Brian -- Brian Roberg DiscipleMakers, Inc. W: 814-234-7975x34 H: 814-867-8327 http://www.brianroberg.org/ From maasj@dm.org Wed Mar 31 19:57:26 2004 From: maasj@dm.org (Jason Maas) Date: Wed, 31 Mar 2004 14:57:26 -0500 (EST) Subject: [Calendula-devel] Nice website about finances for non-profits... Message-ID: Hi all, If you're interested in financial management procedures for non-profits, ("fund accounting", etc) check out this list of FAQs: http://www.allianceonline.org/FAQ/financial_management It seems to me to be quite well-written & even-handed, and you don't have to be a professional accountant to understand it. =) In particular, check out FAQs 9, 1, 2, and 6 among others. HTH, Jason From darrylc@fudosys.com Wed Mar 31 21:45:30 2004 From: darrylc@fudosys.com (Darryl Caldwell) Date: 31 Mar 2004 13:45:30 -0800 Subject: [Calendula-devel] thoughts on QB intergration In-Reply-To: References: <1080685501.2569.29.camel@dhcppc4> <32839.64.38.163.55.1080712314.squirrel@webmail.fudosys.com> Message-ID: <1080769272.1442.10.camel@localhost.localdomain> On Wed, 2004-03-31 at 08:42, Jason Maas wrote: > Hi Darryl, > > What exactly are you thinking of when you say "integrating with existing > accounting packages"? > > Jason > k I mean passing data back and forth through the various hoops. If you look at the QuickBook clones for NPOs they offer hooks into accounting. Presumably, the ability to define campaigns funds to the accounting fund categories without having to enter data more than once. Raiser's Edge, Donor2 and the other big players off the same convenience. I am getting way ahead of myself, but I read this case study for a for-profit company and I started daydreaming..... http://www.openflow.it/EN/Documentation/casestudies_html -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!"