[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