== Recognizing The Potential:
Evo and OO both recognize that comprehensive groupware functions GREATLY
enhance the appeal of their respective products: Evo sees shared
calendars, shared contacts, a user-administered back-end permissions
system, etc. all contribute to making Evo more valuable.
Can I mention that phpGroupWare (and other such solutions) would also
benefit greatly by a joint effort? We are already moving toward doing
this all by ourselves, but could benefit from a shared effort.
== Facing The Reality
Evo and OO realize that building something that competes (at least on
some level) with Exchange and Notes is a significant undertaking. Their
products are shaping up, but there is still a LOT of work to do. Time
is of the essence. Both groups conclude that their time is better spent
working on their core products; but gosh-darn-it, it sure would be nice
to have those back-end features.
Ahhh the ever present dilemma. I think that this can be solved. In fact
I am working on solving part of this with the phpGroupWare project (will
explain more later).
== The Light Comes On
Evo and OO know what what open source is all about. They
advocate/cheerlead/champion an open groupware initiative, put out a call
for developers, post notices on their websites, and sound the general
call to arms: "We want to free countless corporate employees and system
administrators from the tyrannies of expensive, proprietary groupware
systems and the whims of their vendors!" To get critical mass, they
might ask some other prominent open source groups - or - gasp - a
standards body - to get on board.
Why in the world isn't this happening?!
I spend countless hours trying to talk with other groupware projects and
constantly try and find out if they are building any kind of inter
operability between their and my project, but am shut down with little
to no real consideration. Im ready to play ball with other projects. Im
ready to make this dream reality. I just cannot do it alone.
== The Call Goes Out
Evo and OO are pretty well-known among the open source community;
developers hear about this "open groupware standards" thing and become
interested. The founders of the 20 or so groupware projects that have
languished still-born on sourceforge are reinvigorated by this call to
action, thinking "Hey, I won't be ALONE this time, I'll have Ximian and
OO on my side, and all these other developers are interested too!" They
call their project sidekicks in on it. Eventually a persuasive
charismatic (or two) emerges, like a Jobs or de Icaza. He spreads the
gospel at conventions: "We're taking it to the next level, people!"
Why not start now? Im ready... what about leaders of other groupware
project? I will start a mailing list if needed, but I think that maybe
FSF would be more appropriate.
I am in the middle of creating the "Open Source GroupWare Foundation"
which is going to start by taking control of phpGroupWare, working as a
governing body to help push phpGW development in a focused direction.
Right now we are in the process of a complete cleanup of our code. As
soon as this process is done I will be starting a draft for an
XML-RPC/SOAP interface to the API and core apps (email, calendar, todo,
notes). This XML-RPC/SOAP interface will open up our interface and data
store to any number of programming languages. This is where the "Open
Source GroupWare Foundation" will help step in and maintain the
XML-RPC/SOAP interfaces and work with app developers who want to build
interfaces in GTK, VB, C++ or whatever. So the idea is to start with
what we have, but work toward opening it up to other languages.
At some point we will probably start development of the back end using C
which will be a full blown daemon. Of course it will have a built in
http server which will be responsible for transporting the xml-rpc/soap
data.
I personally think that XML-RPC/SOAP is the best way to go for the back
end services required for all these GroupWare clients to use.
XML-RPC/SOAP is supported by most major programming languages, its
flexible and fairly well designed, its network centric and it is very
buzzword compliant. Just think of how kick ass it will be to offer a
free and open .NET groupware service before M$ does. I think it can be
done. I think with my start in phpGW it can be done.
Granted I don't think that PHP is the best long term solution, but I am
already working in this direction, and everyone else seems to be lost in
committee. The phpGW development is pushing ahead with or without anyone
else, but would of course rather have some heavy weights such as OO and
EVO working with us to make sure that the XML-RPC/SOAP structures we
build are properly re-usable by any groupware client. Building this
structure is the most important part. The backend code (PHP) can easily
be replaced by a better/faster solution if it becomes necessary.
== The Word Is Heard (or: "Gentlemen: I give you - OOGS!")
<nitpick>What is the second O for?</nitpick>
I say we start drafting OGWS (Open GroupWare Standard) using
XML-RPC/SOAP now. I will build phpGW as the first implementation of the
backend (unless someone can beat me to it).
If no one joins me, I will do it myself. I have already been working
toward this and will keep doing so. Those that join will simply make
sure I do it the best way possible.
As Evo and OO's interest in open groupware standards rises, they start
talking to each other more about interoperability. Neither wants their
fate tied to the fate of the other, but they find areas where they can
cooperate and benefit without risking their own positions.
This is where a backend that is completely separated from the GUI's will
benefit everyone.
BTW, my XML-RPC/SOAP implementation will take into account vCard and the
iCalendar standards. I personally don't think a whole lot of iTIP since
I have yet to see a single iTIP daemon. Also as a stand alone daemon it
seems far too limited. You would end up talking to IMAP for email, iTIP
for calendar/todo, maybe some kind of vCard daemon for contacts... I
think it MUCH easier for everyone if the XML-RPC/SOAP services deal with
the data and leave the client side to giving the user a rich and useful
tool.
== Stirrings in the Volcano Island Fortress
The proprietary vendors pretend to ignore OOGS. They don't even mention
the word. They forbid their employees to discuss it. But in the upper
echelons, they're reading everything about OOGS that they can get their
hands on. Extra-double-plus-good lieutentants are permitted to install
the OOGS betas, and submit secret reports to the bigshots. Finally,
when eWeek or C-Net run an article on it, they break down and issue a
statement:
Isn't this the funniest part?
== OOGS 1.0
== OGWS 1.0
Soon, the world is a brighter place. Thousands of people are using
OOGS, many of them not knowing it or caring, but nonetheless enjoying
the very real benefits of a choice of
mail/organizer/calendar/document-sharing clients.
And they all live happily ever after.
Can we get some singing and dancing munchcins for good measure?
I"ll leave it to you to decide where the plausibility ends and pure
fantasy begins :-). But stranger things have happened - and are
happening right now in our midst, I would say.
Well, fantasy will become reality at least in something getting done.
Its only up to everyone else to start working together on this backend
to define it properly.
I am not the most talented programmer in the world, but I am not sitting
still. The team that works with me are excited and forward thinking. We
will move to open up our backend to other languages, and just hope that
everyone else takes advantage of our efforts. If not, I know I did what
i could.
Seek3r (aka Dan Kuykendall)
