Thread: Request for assistance/advice: TikiWiki CMS/Groupware will have to drop PostgreSQL support soon unless a maintainer steps up

Hello to the PostgreSQL community!

I asked someone in the PostgreSQL community and he wrote: "There have
been past conversations on the advocacy's mailing list discussing the
lack of implementation of web based front-ends using PostgreSQL. You
could post a request for help on the advocacy mail list."

This is a request for assistance/advice. Please point me to the right
people/place if this is the wrong place.


I am a project admin for TikiWiki CMS/Groupware.

"TikiWiki CMS/Groupware is a full-featured, web-based, multilingual,
tightly integrated, all-in-one Wiki+CMS+Groupware, Free Source
Software (GNU/LGPL), using PHP, ADOdb, Zend Framework, jQuery and
Smarty. It is actively developed by a very large international
community and is translated in over 35 languages. TikiWiki can be used
to create all sorts of Web applications, sites, portals, knowledge
base, intranets, and extranets."

A few stats to give an idea of the scope of the project
* Over 1 million lines of code.
* 220+ developers directly committing to the core, with countless
other people helping with support, documentation, testing, etc.
* 1000+ pages of documentation.
* A new code commit every 2 hours (average of last 5 years)
* 16 000+ registered users on tikiwiki.org
* 700 000+ downloads

Also:
http://info.tikiwiki.org/Fact+Sheet
http://support.mozilla.com/ (10 million page views per week) and
wiki.kde.org are powered by Tiki

Tiki uses a database abstraction layer so it can be used with many
databases (PostgreSQL, Oracle, Sybase, SQLite) in addition to MYSQL.
However, support for anything but MySQL has become more & more
problematic. It's not strictly a chicken & egg problem because Tiki
once worked with non-MYSQL. However, without maintainers, it was lost
over time.

So we have come to a difficult decision. In about 50 days, database
independence will be dropped in Tiki unless a maintainer steps up. So
Tiki will become officially MySQL-only.

Why?
--------
We would love to support many databases, especially PostgreSQL because
it's an open source & community-managed project like Tiki. There are
many reasons why we would want database independence and it's no use
listing them here because it's not that we don't want. It's that we
don't have the resources to do so. Tiki is a huge application and we
would need active devs that use/maintain Tikis on other databases.

However, since we have no maintainer, we have been for a long time now
in a "Worst of both worlds" situation.
*Extra code to maintain
*Bugs that never get fixed
*People that are disappointed (feeling it's "false-advertising")
*Not taking full advantage of MySQL advanced features

More information here:
http://dev.tikiwiki.org/Database+independence

This is very disappointing to me because I have always wanted Tiki to
be as universal as possible. So I don't want to give up on this goal
without a fight. Which is why I am writing to you today.

I look forward to any advice or help you may provide.

Best regards,



--
Marc Laporte

http://MarcLaporte.com
http://TikiWiki.org/MarcLaporte

Forwarded the message to a Venezuelan mailing list, hope it will get
spread soon...

Marc Laporte escribió:
> Hello to the PostgreSQL community!
>
> I asked someone in the PostgreSQL community and he wrote: "There have
> been past conversations on the advocacy's mailing list discussing the
> lack of implementation of web based front-ends using PostgreSQL. You
> could post a request for help on the advocacy mail list."
>
> This is a request for assistance/advice. Please point me to the right
> people/place if this is the wrong place.
>
>
> I am a project admin for TikiWiki CMS/Groupware.
>
> "TikiWiki CMS/Groupware is a full-featured, web-based, multilingual,
> tightly integrated, all-in-one Wiki+CMS+Groupware, Free Source
> Software (GNU/LGPL), using PHP, ADOdb, Zend Framework, jQuery and
> Smarty. It is actively developed by a very large international
> community and is translated in over 35 languages. TikiWiki can be used
> to create all sorts of Web applications, sites, portals, knowledge
> base, intranets, and extranets."
>
> A few stats to give an idea of the scope of the project
> * Over 1 million lines of code.
> * 220+ developers directly committing to the core, with countless
> other people helping with support, documentation, testing, etc.
> * 1000+ pages of documentation.
> * A new code commit every 2 hours (average of last 5 years)
> * 16 000+ registered users on tikiwiki.org
> * 700 000+ downloads
>
> Also:
> http://info.tikiwiki.org/Fact+Sheet
> http://support.mozilla.com/ (10 million page views per week) and
> wiki.kde.org are powered by Tiki
>
> Tiki uses a database abstraction layer so it can be used with many
> databases (PostgreSQL, Oracle, Sybase, SQLite) in addition to MYSQL.
> However, support for anything but MySQL has become more & more
> problematic. It's not strictly a chicken & egg problem because Tiki
> once worked with non-MYSQL. However, without maintainers, it was lost
> over time.
>
> So we have come to a difficult decision. In about 50 days, database
> independence will be dropped in Tiki unless a maintainer steps up. So
> Tiki will become officially MySQL-only.
>
> Why?
> --------
> We would love to support many databases, especially PostgreSQL because
> it's an open source & community-managed project like Tiki. There are
> many reasons why we would want database independence and it's no use
> listing them here because it's not that we don't want. It's that we
> don't have the resources to do so. Tiki is a huge application and we
> would need active devs that use/maintain Tikis on other databases.
>
> However, since we have no maintainer, we have been for a long time now
> in a "Worst of both worlds" situation.
> *Extra code to maintain
> *Bugs that never get fixed
> *People that are disappointed (feeling it's "false-advertising")
> *Not taking full advantage of MySQL advanced features
>
> More information here:
> http://dev.tikiwiki.org/Database+independence
>
> This is very disappointing to me because I have always wanted Tiki to
> be as universal as possible. So I don't want to give up on this goal
> without a fight. Which is why I am writing to you today.
>
> I look forward to any advice or help you may provide.
>
> Best regards,
>
>
>

Marc,

> This is very disappointing to me because I have always wanted Tiki to
> be as universal as possible. So I don't want to give up on this goal
> without a fight. Which is why I am writing to you today.

Thanks for contacting us.  Clearly we need a way to advertise through
our community which projects are looking for PostgreSQL
maintenance/porting help; for now we can put TikiWiki in the Weekly News
or similar, but it would be nice to do this more systematically.

I assume there's already been appeals on the tikiwiki user mailing
lists?  Ultimately the maintainer needs to be someone who uses tikiwiki
regularly or they won't stick to it.

Actually ... *does* anyone use TikiWiki with Postgres right now?

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Mon, Jun 8, 2009 at 12:29 AM, Marc Laporte <marclaporte@tikiwiki.org> wrote:
> Tiki uses a database abstraction layer so it can be used with many
> databases (PostgreSQL, Oracle, Sybase, SQLite) in addition to MYSQL.
> However, support for anything but MySQL has become more & more
> problematic. It's not strictly a chicken & egg problem because Tiki
> once worked with non-MYSQL. However, without maintainers, it was lost
> over time.

I'm guessing one of the painful things you deal with is maintaining
the create and upgrade DDL scripts for all those platforms. I've done
this in the past (years ago now, thankfully) for several
database-independent products. It's not fun.

I'm the lead developer on Power*Architect, an open source data
modeling tool that lets you develop your data model in a
platform-independent and visual way, then "forward engineer" to
several platforms (from your list, we support PostgreSQL, Oracle, and
MySQL--Sybase and SQLite support would need a bit of work). You could
use this to generate both create and upgrade scripts for all the
supported platforms.

I hope this can help you argue to keep PostgreSQL support. With a
platform-independent data model, supporting multiple platforms is much
easier. I've done the switch from hand-coded SQL to platform
independent visual modeling on real projects, so I could give a bit of
advice about how to approach the problem if any of the tikiwiki
developers are interested in trying it!

-Jonathan

On Mon, Jun 8, 2009 at 4:56 PM, Josh Berkus<josh@agliodbs.com> wrote:
> Marc,
>
>> This is very disappointing to me because I have always wanted Tiki to
>> be as universal as possible. So I don't want to give up on this goal
>> without a fight. Which is why I am writing to you today.
>
> Thanks for contacting us.  Clearly we need a way to advertise through our
> community which projects are looking for PostgreSQL maintenance/porting
> help; for now we can put TikiWiki in the Weekly News or similar, but it
> would be nice to do this more systematically.
>


This is a great idea! TikiWiki-Firefox collaboration has been hugely
successful. I am sure it can be the same.

I think our best shot is if both communities use their network to try
to find one or many people that see value in this project and are
ready to help out.  We combine :
*Experienced Tiki devs but that are unfamiliar with PostgreSQL  (2 so
far have expressed interest)
*With PostgreSQL wizards that have a need for a Wiki+CMS+Groupware hybrid

Both will have things to learn from each other :-)


> I assume there's already been appeals on the tikiwiki user mailing lists?

Yes. And I just added here:
http://wiki.postgresql.org/wiki/TikiWiki_CMS/Groupware

>  Ultimately the maintainer needs to be someone who uses tikiwiki regularly
> or they won't stick to it.
>

Exactly.


> Actually ... *does* anyone use TikiWiki with Postgres right now?
>


I don't know for sure. But I am pretty sure there are some old
versions out there (because AFAIK, it used to work).

The problem is that maybe some people will upgrade in 6-12 months,
only to find out at that time that PG support has been dropped.

Best regards,

M ;-)

--
Marc Laporte

http://MarcLaporte.com
http://TikiWiki.org/MarcLaporte

Hi Jonathan,

Thanks for this information and offer. You obviously know our pain,
inside-out :-)

I am glad to report that 2 Tiki developers have expressed interest so far.

I am hereby passing on the link to Tiki dev-list :-)
http://code.google.com/p/power-architect/

Best regards,

M ;-)


On Mon, Jun 8, 2009 at 5:40 PM, Jonathan Fuerth<fuerth@sqlpower.ca> wrote:
> On Mon, Jun 8, 2009 at 12:29 AM, Marc Laporte <marclaporte@tikiwiki.org> wrote:
>> Tiki uses a database abstraction layer so it can be used with many
>> databases (PostgreSQL, Oracle, Sybase, SQLite) in addition to MYSQL.
>> However, support for anything but MySQL has become more & more
>> problematic. It's not strictly a chicken & egg problem because Tiki
>> once worked with non-MYSQL. However, without maintainers, it was lost
>> over time.
>
> I'm guessing one of the painful things you deal with is maintaining
> the create and upgrade DDL scripts for all those platforms. I've done
> this in the past (years ago now, thankfully) for several
> database-independent products. It's not fun.
>
> I'm the lead developer on Power*Architect, an open source data
> modeling tool that lets you develop your data model in a
> platform-independent and visual way, then "forward engineer" to
> several platforms (from your list, we support PostgreSQL, Oracle, and
> MySQL--Sybase and SQLite support would need a bit of work). You could
> use this to generate both create and upgrade scripts for all the
> supported platforms.
>
> I hope this can help you argue to keep PostgreSQL support. With a
> platform-independent data model, supporting multiple platforms is much
> easier. I've done the switch from hand-coded SQL to platform
> independent visual modeling on real projects, so I could give a bit of
> advice about how to approach the problem if any of the tikiwiki
> developers are interested in trying it!
>
> -Jonathan
>



--
Marc Laporte

http://MarcLaporte.com
http://TikiWiki.org/MarcLaporte