Spectra Participant.
I took the weekend to think about your comments as well as those posted to
this thread. I am combining my response to both in one email, so it might
seem that I jump between the two of them... This is the way I read it and am
willing to discuss any point with anyone... Upon reviewing this email, it
seemed that I wrote up my thoughts on everything... Also, a small favor,
please don't read too much into things. Don't take a lack of a comment as
anything else but that...
I agree with your observation that this list believes that Spectra matters
to Macromedia. And I believe that this belief has merit. Here are my
reasons:
1. This Spectra Community Site.
For about a year now the community has been asking MM for a site where fixes
can posted, validated and shared with the community. Well, this is that
site. Unlike the Dev Center where additions to Spectra are posted, my
understanding was that we all wanted a place where we could get the latest
and greatest Spectra code base without having to wait for a release.
I also remember several comments from several folks in the community,
including myself, that if there was such a site we would be excited about
sharing the fixes we were doing. I for one never imagined this site being a
way where whole services were written or rewritten for distribution. That
had always been something for the Dev Exchange, which BTW I do have comments
about for improving it for this sort of thing. I also believe, Ray do
correct me on this if I am wrong, that this site will serve as a platform
for MM itself to make fixes to Spectra.
In addition to fixes, it sounds like we can also make small
modifications/enhancements to Spectra (as long as it is not written for any
particular business problem, a.k.a 'fork') and have that made available as
well. In my mind this means an extra attribute to a tag here, or optimized
code in tag like the one that Michiel Boland showed and demonstrated a few
posts back (BTW, very nice work Michiel). I know that my team and I are
already planning on submitting these sort simple enhancements to Spectra
Source.
I also want to add that the expectation of that code being submitted to this
site will revolutionize Spectra is absurd. Changes of this magnitude will
more then likely deviate from the core model as well as be very difficult to
be backward compatible... (Last statement is my opinion). Also, I doubt that
an enhancement of the quantity would go public. I expect that the
company/developer would rather get paid for that type of functionality...
Getting back on track, what I see as the great thing about this site, beside
the fact that it is way cool, is that I won't have to send code to Ray or
Charles anymore. I can submit it and make it available immediately. This
benefit my team, clients, community as well as myself...
As for my thoughts on who owns the code fixes. It makes sense for MM too. It
is their product, they have to run regression tests against the fix, they
have the ability to distribute it to the masses more effectively, they have
the big picture of the Spectra product as it stands and hopefully can be
objective in sorting through the submissions to make sure the purity of the
application framework is maintained. Also, I believe their are legal
ramifications
if they don't own the code, I.e. they can't ship it. Now enhancements are a
little
different. Those can represent a lot of time put in by a team and should
only be shared if want to give it away to the community. And my last thought
on this is, it is not mandatory. This site is just a tool and a platform for
collection and distributing bug fixes.
I know for a fact that this site represents a huge effort from MM, primarily
Ray, so I for one would like to applaud them/him for their work. Legal
wording be damned.
2. The COAPI being moved a future release of ColdFusion.
I know that this seems like a weird reason, but let me explain. Spectra is
not disappearing. Well, maybe as a product but not as a technology. The core
of our development is done in the COAPI, well that and a bit of CF. After
which we would then leveraging the Spectra services. It is this COAPI
development model that MM is talking about transitioning forward.
So let's look at this from a different angle. Let's say you build an
calendar application. It is highly flexible, feature rich, blah, blah,
blah... But, like all application any of us build it isn't perfect. A year
goes by and you have to build back office suite application that contains a
calendar component. Wouldn't you go back and analyze the existing calendar
application to provide a base for the next application. Also, let's say that
you sold the first calendar to multiple clients. And we all know from sales
that it is your existing customers that make the best clients. That being
said you have two things you need to accomplish 1) provide a way for clients
to move from the first calendar to the second 2) use your existing
clients/developer community and application as way to effectively build the
calendar component in the back office suite. In this example, not only would
you care about the existing calendar application, but also the existing
clients and the development community that was using it.
Scaling this to what us (the Spectra development community) we can see where
this applies. Look at the size of the community, the number/type of Spectra
sites and finally who the Spectra clients are and that should show how
important Spectra is.
3. Preview into the future
MM has already released the first of several articles that will be giving
insight and guidance for Spectra development for the transition. A
reflection of point two shows the value.
Now from my perspective those are some pretty good indications. I believe
that there are more reasons that other members of this list can also
provide.
Putting that down, lets move on to the notation that the investment is close
to useless... My question is how do you figure?
The way I saw it was that Spectra is a series of services written against
the COAPI. Out application leveraged these services as well as implemented
our logic and data written in the COAPI. With the COAPI moving forward what
we get is the core of both the Spectra services and our applications being
made available to us in CF. I look at the investment I made in Spectra and
see it in two parts. 1) Applications 2) my time.
Addressing applications first. First off, I generally don't write them for
myself so the real concerning is in the clients that I wrote them for. One
thing that I enjoyed about Spectra was that I was able to write my
applications consistently through the structured nature of the COAPI. Data
and logic is abstracted and implemented through APIs. By looking at the
architecture of Spectra I saw that as long as I was able to move this style
of development over I would be leverage the investment of my applications.
Perhaps the underlining name of the technology has changed but the truth of
the matter is that it is the development style that needs to remain the
same. That is all I will discuss or say on this matter, there will be more
information for MM on the full Spectra transition that is outside of this
document.
The second investment is time. I started working with technology and
programming languages in my early teens. Unfortunately in that time I have
seen a lot of investment in languages dry up and go away. As we all have.
What I have found is that I always need to look below the language and pull
out design, the problem it was solving, what it took to successful implement
and other non syntax things in nature... As I have barreled through
technologies I saw that it was those things that I was able to leverage over
and over again. Syntax and logic were always able to be relearned... For
example, if you look at the EJB spec or have built a J2EE application you
will notice some very similar concepts and implementations between that and
Spectra. Beans in that architecture are very similar to our Types/Objects in
Spectra. EJB has container managed persistence, Spectra has COAPI managed
persistence. There are other similarities between just those two
technologies. Now those are two distinct languages, right? But still our
investment in time in learning Spectra pays off... Now compare the time
investment in Spectra and how much you will be able to leverage when it
moves to a release of CF. In my mind there isn't even a question.
The last topic I want to touch upon is motivation and reason I keep using
Spectra today. And unlike what was suggested, it is not because that is all
I know or that my business is built entirely around Spectra. The reason I
still stoke the fires is because of my believe in this product. Both in what
it is today and what it will move to. I also believe in the well being of my
clients, when I bring Spectra into an engagement it is because it is the
right fit. PERIOD.
A noted above, I have had the pleasure (and sometimes not the pleasure) of
working with a variety of languages. Over the last couple of years I have
used a variety of they to help clients solver their problems, but yet I
still choose Spectra for projects. Why? Well first off, I have found Spectra
to be one of the most cost effective ways to build an application. Second,
it introduces a set structure to an application (COAPI) without an
overburdening complexity (for complexity try Java development). Third, every
time I started a pure CF or Java application I ended up building out
portions of my applications to accomplish the same functionality that was
immediately available to me in Spectra.
These all lead me to the fact that Spectra provided the most value to my
clients. Putting everything else aside, that is the primary motivation in
using it to build applications (IMHO, this should be the reason for using
any product in an application). Do I think Spectra is a fit for all
applications, heck no... I am the first to say that what is being requested
is not a correct fit, whether it be to simple, complex or doesn't provide
the correct functionality. When I recommend and use Spectra in a project, it
is because I _BELIEVE_ it is the best fit.
I feel safe in saying that these are some of the similar thoughts echoed by
the developers on the list and a reason why we think MM cares about Spectra.
I also know from talking one on one to clients, business managers and
developers alike that also feel this to be true...
A small personal request, I know you didn't mean to be offensive (at least I
hope not), but if you don't want to mention your name in an email, please
don't mention mine or draw assumptions...
For all of those who read the entire 'book', congratulations ;) I have been
wanting to reply to the many posts that have appeared on the list for
sometime and finally found the time... These are my thoughts and why I do
what I do...
As always I am open to discussing any of the above comments.
Ben
-----Original Message-----
From: Spectra Participant [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 13, 2001 12:29 PM
To: Spectra-Talk
Subject: Re: SpectraSource is now live
It appears to me that there's a general belief in this list that Spectra
somehow matters to Macromedia.
With all due respect to everyone who has worked so hard on Spectra for so
long, Macromedia's interest in Spectra and the community source model is in
placating a customer base that should be rightly angered by their investment
now being close to worthless. Macromedia is playing both sides of the fence:
they've announced that they will no longer build Spectra and in two years
they will no longer support Spectra; at the same time they are saying that
any fixes or enhancements that are provided by the community of users will
be their property. You never know when the community might do something
stunning and if they do, Macromedia will own all the stunning product of
that labor. Their investment in that possibility? One website.
I think Macromedia is acting in their best interest. I don't think Spectra
really serves that interest very well. If it did, it wouldn't have been
tossed to the side like it was. I think their plans for the COAPI and how
they will build their applications to integrate with it will trump all
efforts put into Spectra.
I can appreciate the efforts made by Ray Camden and Ben Elmore and all to
keep the Spectra flame burning. They've got their own interests and their
own businesses and their own client bases that are probably heavily reliant
on Spectra's future. As principal developers, I'm sure they've got a lot of
personal ties to the product as well.
I think other people that are looking at the community source for Spectra as
a stable foundation for the future might want to take a step back and think
about it.
>From: spike <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Spectra-Talk <[EMAIL PROTECTED]>
>Subject: Re: SpectraSource is now live
>Date: Fri, 13 Jul 2001 17:12:59 +0200
>
>I agree with this.
>
>Most bug fixes are a simple matter of a 1 or 2 line code change. I have no
>problem with _giving_ this to Macromedia.
>
>The problem with using the Developer's exchange is that it doesn't provide
>much scope for descriptions of complex applications. There is no way to
>know how good or bad the code is until you download and try it, and there
>is no facility for distributing or managing the distribution of updates of
>changes to the users other than hoping that they have checked the notify me
>box when they downloaded the tool. Since they don't know how good or bad
>the tool is before they download, it is unlikely that many people check
>this box by default.
>
>There should (IMHO) only be 1 version of Spectra which is sold by
>Macromedia, but that needn't preclude the centralization of many Spectra
>add-on products such as Alternative Webtop/admin interfaces, Custom
>Security, Custom Database Structures etc. Most people who have built
>multiple Spectra projects have made one or more of these modifications and
>have a toolbox which they would probably be prepared to share with the
>community for a price. Most would not, however be prepared to give
>ownership of those tools to Macromedia for free. I would like to see a
>centralized repository of mods, additions and so-on as well as the bug
>fixes. This could also include a facility for posting peer review comments
>on the code and a choice of licensing for the developers similar to the one
>in the developer's exchange.
>
>Without the facility to centralize these resources the onus is on the
>developers to make these available to the community and development
>companies do not have the resources or the inclination to create a site to
>do this as they would have to invest in the hardware, marketing,
>advertising etc. With a centralized resource this cost is greatly reduced
>and the community is better able to benefit from the tools and use Spectra
>to it's full potential.
>
>Spike
>
>At 16:26 13/07/2001 Friday, you wrote:
> >Personally, I don't mind that minor fixes become the property of
>Macromedia.
> >This is the way things were until now. However, I would think it wise if
> >Macromedia would have a more appealing approach around major mods. Let's
> >face it, the Spectra development process is now in the hands of the
> >community. It'll take up to two years for stuff to appear in the CF
>engine.
> >All those wonderful mods people might share with the world are now going
>to
> >stay hidden. That's a shame, particularly because a lot of Spectra could
> >benefit from some major changes (security, metadata for example).
> >
> >Not allowing forks is in my mind a bad idea. That's saying: it's perfect
>the
> >way it is with some minor issues. That's not the case in my opinion.
> >
> >Kind regards,
> >
> >Marc Schipperheyn
> ><theFactor.e>
> >
> >Premium Partner for Macromedia
> >
> >The future is technological, but it will not be a world of gray steel
> >
> >
> >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
