[kwlug-disc] Continued: OpenSource Me!]

Insurance Squared Inc. gcooke at insurancesquared.com
Mon Dec 22 11:38:54 EST 2008


I wasn't clear in the distinction.  An independent insurance agent is 
going to want a non-server, non-browser based app, like a compiled, 
standalone app they can run on their desktop, natively.  That's why I 
think I'd need to go with C instead of php, and have the concerns about 
output and database modularity.  We don't do windows development so I'm 
a bit out of touch.

unsolicited wrote:
> Can you decompose some of the functionality to development stages or 
> releases?
>
> Insurance Squared Inc. wrote, On 12/22/2008 10:07 AM:
>   
>> Continuing on the vein of starting a new OSS software project, I'd 
>> appreciate some input and advice on the following hurdles.
>>
>> My personal need is for the database to run on a local linux server and 
>> access it via browser.  Super easy, I create the specs and our developer 
>> whips it up in php/mysql.  If I want to make it more modular, I seperate 
>> the database functions so it allows other databases.  This would also 
>> work well for those that have some number of employees and the ability 
>> to run a local linux server.  It doesn't work well for independent folks 
>> running MS on their desktops.  That segment of the market is actually 
>> far larger than the users that have my profile.  I'm questioning the 
>> tradeoff between looking after these folks and the additional work and 
>> costs (remember, I'm paying for developer time, at market rates). 
>>     
>
> What am I missing? Whether it's a browser on Linux or a browser on MS, 
> should it not be the same? i.e. No (initial?) need for native desktop 
> MS coding?
>
> If you stage things and initially write for Firefox (perhaps even a 
> firefox add-in?), can you K.I.S.S. and worry about other browsers and 
> / or the MS desktop later? What about OpenOffice Base since it's cross 
> -platform?
>
>   
>> It seems that if I'm going to allow easy cross platform useage and a 
>> non-browser based interface (i.e. both a linux based system accessed via 
>> browser and a local desktop windows app) then I've got quite a few 
>> hurdles to overcome.  Specifically:
>> - I think I have to go with some C variant instead of php.  More costs, 
>> and more effort.  We're not a C shop.
>> - Screen/output have to be *really* modular.  HTML output with smarty 
>> templates, easy.  Abilitiy for one set of code to run smarty templates 
>> and whatever it is that windows uses, way more complex.  I guess I even 
>> have to start thinking about print functions.
>> - same thing with the database.  It's one thing to have a linux/php 
>> system access a couple different common linux databases.  It seems like 
>> a whole other level of complexity to use mysql as a database and I don't 
>> know what on windows. 
>>
>> And I don't expect this to be a typical OSS project, even if 
>> successful.  Given my non-tech marketplace, we'll be the only ones 
>> doingin any coding.  So hoping for someone else to port isn't going to 
>> happen.
>>
>> Are these hurdles easy to overcome? Should I just do a linux system and 
>> worry about MS later?
>>     
>
> Any reason why you couldn't, for your MS 'server' folks, do a Linux vm 
> to run under vmplayer? Worry about a native MS port later, if ever? 
> e.g. If you can be an appliance, are there not a number of LAMP 
> appliance distros out there you can leverage off of?
>
> 	I know there's LAMPs out there to run under native windows, however, 
> for the moment, do you want the complexity of inserting your app into 
> current environment, or can you require, for the moment, your own 
> appliance, such as within your own vm.
>
> I keep hearing about 'iterative development' - can your user interface 
> be browser only for the moment? Make it 'pretty' later?
>
> On the other hand, I keep hearing in the back of my head something 
> John said a while ago ... essentially, if it isn't eye candy, 
> marketing wise, it ain't going nowhere.
>
> The other thing I've heard ... the very hardest part about an 
> application is perfecting the business rules. I remember how 
> subrogation bedevilled our developers when it was added after the fact.
>
> FWIW.
>
> _______________________________________________
> kwlug-disc_kwlug.org mailing list
> kwlug-disc_kwlug.org at kwlug.org
> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org
>
>   





More information about the kwlug-disc mailing list