On Sep 19, 2007, at 4:51 PM, Eric Meyer wrote:
This is with all due respect. I have just been involved in way too
many projects where people rushed things, only to end us spending way
too much time, money, and effort to get what they really NEED.
EM: I'm in agreement. It seems to me that we should set up some basic
stuff-- at least a wiki and a forum, possibly a CMS-- from existing
packages so that those communication channels aren't held up by an
ongoing effort to create the Perfect Solution. Later on, if we build
our own stuff, we can migrate the content over.
NK: Here is my problem with that. Just throwing a wiki, a forum, and a
CMS at it won't solve any problems or help us create a cohesive whole.
It will create data islands on the backend, each solution using its
own auth/auth and database structure. Our choices to 'migrate the
content over' would involve either a) Rewriting the application we are
using to fit our needs (never a good idea), or b) creating a migration
script that will take the data from the formats that those packages
used, and re-formating them to fit our needs (seemingly unnecessary -
but our data model might not match their data model).
Neither of these solutions is an easy or quick fix - especially from
the open source options. There are many data issues that would need to
And this doesn't even touch on the front end issue of giving us a
brand/identity. Just as with the data islands, now we have the same
sort of islands with the front end: file structure, url structure, css
structure and organization, HTML structure and organization - do we
really want to manage data islands?
My personal opinion: that doesn't position us very well as a group of
web professionals. It doesn't take a web professional to install 3
different open source packages (or paid) and call it a day. I think
going open source with these options will create more work for us than
necessary. The communication channels would then become disconnected
from the whole. The big picture gets lost.
EM: Yes, we're a brilliant group with a lot of skills. And we should
certainly use that to create great things. But the same could be said
of many W3C Working Groups that have been working on "great things"
for years and years and years.
NK: I think that is comparing apples with oranges. We want to create a
professional web presence that meets our needs and goals - the W3C
Working Groups are working on setting recommendations and standards in
place. They have many more variables and constraints they have to work
within and around. I know we haven't set out our initial goals,
audience, or processes - but I can bet they won't be near as big as
what the W3C Working Groups have to work with. Two completely
different scopes and resources.
EM: Personally, I tend to be more attuned to the development style
that says get something out the door and refine it over time. Flickr
is the poster child for this, and it's worked very well for them.
I agree with that 110%. I have the same philosophy of getting things
out the door and having the flexibility to grow and expand as
necessary. You simply can't wait for 'the Perfect website' - it won't
happen. You will worry about all of the little details to the point
you never get anything done. I am in full agreement with getting
things done. No argument from me there. Also, the scope and resources
of Flickr are much larger than ours. Did flickr start out with open
source options to get things done, or did they build and then add
features as the service evolved (And was bought by Yahoo)?
My personal opinion: for the sake of 'getting things out the door' -
you can't sacrifice your goals, quality, and your time. Heck, it's why
my personal site is still stuck on Wordpress. I thought it would
initially be a great solution to get me up and running and out the
door, and now I have to spend the time to actually build to my needs
(versus digging through the wordpress tag soup and architecture). Time
that would have been better spent building it right in the first
place. When you use open source, you are subject to their coding
standards (both front end and back end), their database schema, and
their URL/Routing/Dispatching. Throw several packages into the mix and
the maintenance now escalates...
EM: As for "why the rush?", I've seen this group bloom and die before.
The more momentum we give it, the better chance it will avoid death.
Getting our own site with our own communication channels will boost
that momentum quite a bit. I don't want to wait for that boost.
Besides, with software in place, we'll have something to react to, in
terms of "we should have that feature in our thingy!" and "I hate that
feature, let's never do that in our thingy!" and why can't we do
such-and-so? let's make sure our thingy does that!".
I understand the need for momentum. I am trying to think in terms of
simplicity. I am sure we all have ideas of 'features' that our site
should have. This is why we, as a collective group, need to sit down
and really hash out our 'needed' features and build from there.
Features are going to be subjective, just as the design will be. We
need to avoid feature bloat and give us the tools we need to
communicate effectively, both internally and externally. Keeping it
Again, I fail to see how software packages will help us to react to
that. A CMS, forum, and wiki each have distinct structure, schemas and
functionality - much of which I am sure we will want to connect to
Example: A simple aspect of logging in as a registered user. One
system uses SHA1 encryption with a salt. One system uses MD5 without a
salt. One system doesn't encrypt at all. One system uses ACL with
MPTT, another uses a roles table. One system handles authentication
via sessions stored on file, one system handles authentication via
sessions stored in a database. Are we just going to maintain three
different databases that require us to login in the wiki, the forum,
and the CMS?
EM: Anyway, my point being that I'd rather we ship early and often,
even though it means some extra effort, than do tons of work on the
ultimate solution and risk never shipping.
NK: I would rather see us build with a solid foundation, and then ship
early and often - versus throwing random pieces of software into the
mix. That extra software will require much more than some extra
effort, much more. Let's sit down as a collective group and really see
what features are needed, what is our message going to be, who will
our message be aimed towards, and give us a solid base to work with.
We can sit down and dream together. Both long term and short term.
Then we take all of those pieces and organize them into a workable
timeline to allow us to ship early and often. I can guarantee in the
long run it will be much less hassle than several open source software
packages. Everyone can be involved. Those who are here to learn can
now engage in the process of building something and understand how
something was made, not installing something.