[BW-dev-discussion] Is it important to adopt a new framework before proceeding?

[Peter Lind]

On 23 August 2010 11:59, Tobias Brox <tobixen at gmail.com> wrote:
> On 22 August 2010 14:47, Peter Lind <peter.e.lind at gmail.com> wrote:
>> This avoids a big-bang strategy (one of the most likely risks of
>> failure for the project) while easing developers in.
>
> I don't know much about the bwrox application ... but I agree quite
> much to that, I've witnesses several failures or near-failures from
> when the programmers have become fed up with the mess, and tried to
> reimplement a project from scratch.  The new code will most likely
> miss some of the old features and will be with more bugs.  The users
> will see only the drawbacks, not the benefits with the "new and clean
> code", and the programmers will become disencouraged because the users
> prefers to run the old code.
>
> Then again ... isn't it slightly ironical, that one of the reasons
> stated why "bwrox sucks" is exactly because one has several times
> attempted to "switch framework" without fully succeeding with it?

Sort of. There's been one attempted switch, then one attempt to
repair/extend the framework we switched to. But yeah, one should
definitely be aware of the possible risks.

> Except for that, I'm quite much against reinventing the wheel.  For
> me, bwrox seems like "just another social networking site", with some
> extra emphasize on geolocation.  I would be amazed if there isn't some
> ready-to-use software in the open source domain that already supports
> many of the bwrox features out of the box.  Alternatively, for sure
> there exists many open-source applications supporting one or some of
> the features we want to deliver, i.e. discussion forums, wikis,
> calendar, blog, etc.  It could be possible to "stitch together" (i.e.
> single signon, good cross-linkage possibilities, etc) existing
> specialized applications and concentrate on the hospitality exchange
> specifics in our own application?  Well, I do see drawbacks with such
> solution ... but at least we would gain on it by having almost
> feature-complete and bugfree subsystems on our site without too much
> maintenance efforts.

I agree up to a point. It would be nice to just be able to string
together a number of products and hey presto, system in place. I don't
believe this is feasible though, for the following reasons:
- we've already tried it with the ErfurtWiki we use now. It's utter
crap, we've had to hack it to make it work as we want it to (and it
still doesn't quite). The main wiki system that one benchmarks against
is - according to anecdote) - a nightmare to implement into existing
systems
- a platform like BW or the proposed cooperation goal is *not* just
the sum of it's parts. It's not just a forum with geolocation tacked
on to the outside. It's a forum where the geolocation is a central
part - and it's geolocation capable of pulling forum threads, member
profiles, etc into one. Trying to do this with several stand alone
components will probably result in massive overhead or a nightmare of
hacks.
- creating a uniform experience with several stand-alone projects is
very hard. It will likely be very easy to see that you're now leaving
the stand alone forum part and entering the stand alone wiki part.
That's not a nice user experience

That said, the way one might be able to do this is by creating a set
of thin adapters/facades to the various systems, pull data out of them
and then present it outside each system, as a unified whole. That
might be a *lot* of work though - hard to gauge without experience (if
one could find a forum with a good api, a wiki with the same, etc,
then it might be easy enough to simply run those systems on their own
and just extract data from them).

Regards
Peter

-- 
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>