[Grok-dev] Re: What is Grok anyways... time for a name change? :)
Sebastian Ware
sebastian at urbantalk.se
Fri May 11 09:09:06 EDT 2007
10 maj 2007 kl. 23.56 skrev Martin Aspeli:
> Hi Sebastian,
>
>> I'll try to answer all comments in a condensed manner.
>> DISCLAIMER: I don't want to hurt any cavemen's feelings, but it
>> is highly competitive out there in the framework jungle... so you
>> have to evolve your tools... ;)
>
> Your comments are extremely constructive, so no-one's feelings are
> getting hurt. :)
Phew... :)
>
>> I would like to se GROK as the tool of pioneers who know that the
>> hack I write today might evolve into a mission critical,
>> enterprise wide, application tomorrow, and I want to use the
>> right framework up front.
>
> That's a good message, I like that one.
>
> It's a bit like the marketing of things like JBoss SEAM or even what
> Macromedia tried to do with building Cold Fusion on top of J2EE
> (ouch +
> ouch = eeewwwww). Gimme the quick-and-easy and let me drill down to
> the
> solid core when I need it.
>
> The problem here is that it's almost impossible to make "pure Java"
> terribly agile and easy to get started in, and almost impossible to
> make
> anything written with Fold Fusion not be an awful hack.
>
> It's possibly a bit like Rails scaffolding mode, thought that's just
> something that I've heard.
>
> The hard sell in that message is "don't worry, the transition from
> quick
> hack to evolved framework will be straightforward and obvious, not a
> painful jerk of the crutch from underneath you".
Maybe this could be one of the pillars of the communication.
Answering the question: How does Grok make the transition from useful
hack to enterprise wide adoption easy?
>
>> The Zope being good/bad for Grok is an easy one. If a developer
>> has bias against Zope, they obviously won't use Grok... but if
>> the buzz gets hot on a this new framework Grok, which puts a
>> great twist on the all new and improved Zope 3, then it will
>> surely make (a professional) developer want to evaluate this option.
>
> I think so. I'm of the opinion that we shouldn't pander to Zope
> negativism. Who cares if people rant about Zope? Point to good
> examples
> of people being wrong. I think Martijn is the master of such
> coolheadedness.
Absolutely. Remember, if we don't believe in our own stuff... why
should others...? :)
>
>> Regarding my list of names... why do people associate Java with a
>> programming language... might it be because of SUNs marketing
>> dollars? ;) I think so... and how about .NET... Remember, these
>> days even management will have a say in the matter.
>
> Of course. To an awful lot of businesses, the choice of platform is
> "Is
> this a Java or a .NET project?". Then again, we possibly don't compete
> against those languages in the situations where that is the case. But
> there is something of generational shift going on... it used to be
> "Cobol or nothing. Then Java or nothing. Then Java or .NET".
True. So we have to communicate "Plays extremely well with Java
and .NET"
I think Grok will be pitched against TurboGears/Django/RoR/PHP5 and I
think we can convince people of the benefits of the Grok route.
>
> These days, we're slowly getting into a place (and Ruby-on-Rails is
> doing a lot in that department) where more agile, open source, rapid
> tools are becoming acceptable, though you'll always fight an uphill
> battle of convincing people of scalability, security and future
> support.
>
> Sometimes, that's rightly so. My client shouldn't have to pay with
> higher risk just because I don't like coding Java as much as I like
> coding Python. They should be presented with arguments about
> time-to-market and flexibility and cost, though.
>
> And Grok can win there, because Zope has a stable history. It still
> doesn't hold a name-recognition candle to Java or .NET or even Rails,
> but you find old-timers who once heard of it and thought it was cool.
> That's important.
>
>> My point with the list was that there will always be short-lists
>> when people evaluate stuff, and you want to be on that short-
>> list, and you want to stand out.
>> GROK|ZOPE3 -- an enterprise framework made easy
>
> I want that, but in a diagram and not a name-with-punctuation-in-it.
>
> Anyway, I think it's some time before Grok ends up in those head-to-
> head
> comparisons. We should crawl before we walk and walk before we run.
> Right now, we should focus on making the framework good, and being
> honest and enthusiastic about that process. We should sell the
> messages
> we have, clearly and concisely, not sell hot air that we think
> someone's
> boss may swallow.
>
>> Grok, the caveman as a subculture. I am not convinced that he has
>> (already) become a subculture. Grok the caveman is a metaphor, and
>> he just gives me the wrong associations. Nonetheless, as an
>> ironic comic strip bashing on the evils in software development,
>> yeah I think it could become a really cool thing. As the poster
>> boy of Grok... he might actually be a problem. :(
>
> I disagree that this is a problem. Java has a silly merlin-wizard like
> thing. Linux has a fat penguin. BSD has a devil-looking-thing. Logos
> that are memorable and personable are more important, in my opinion,
> than a "I am really corporate and solid" me-too.
True, but it's an emphasis thing. I think we could use the mascot a
lot smarter. I am more into the idea of a Dilbert kind of caveman,
that trumpets amusing situations in software development. And then we
can say "this is how Grok tackles it...".
I just feel there is a slightly too liberal use of caveman
references... :)
I'd say, use a cool caveman for viral marketing and a feeling of
recognition (Dilbert strip style) and to make examples and sample
applications more fun.
This would be both useful and fun for internal story telling as well.
>
>> Grok currently communicates that it is aimed at developers who
>> feel like cavemen. Only in my book, cavemen do stupid things and
>> compensate with persistence. For me, PHP would be the tool of
>> choice for a caveman.
>
> I think that's an interesting market research data point. I
> disagree on a personal level, but this *is* all about feelings and
> perceptions, so thanks for sharing it.
>
> It may also depend on how we present the caveman, in what context,
> and with what text.
>
> Martin
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
More information about the Grok-dev
mailing list