Hi Vladimir;
and first off, again thanks for your well-written statements - food for
thought indeed, that's what I like about FishCAT, too. :]
> I should say that your detail response will help a lot to develop
> motivation policy such way that will attract people with your kind of
> mindset.
This, of course, would be good in my opinion. ;)
> This situation would be a great achievement for our motivation
> engine.For minor things we could pay dukelets instead of dukes :)By
> the way imagine a situation when you lost your job and have plenty of
> time on your hands but worry about financial situation.
> Day after day pass and you are still looking for job.It could be very
> depressing isn't it.
It _is_, for sure. But then again, I think effectively addressing
things like this is out of scope of what something like FishCAT can do,
unfortunately... except for the "resume effectiveness", of course,
and eventually except for the "valuable" effect of networking, of being
linked with a whole load of like-minded people involved into their
professional environment. Maybe being active in FishCAT, patiently
providing meaningful and profound issue reports could raise someones
attention and help you in times of need? Surely, it's not reliable...
> I like your terminology on this and if "currency approach" will be
> put in production then "coordinated-testing" approach is the only way
> to go.Probably you should describe in more details how you see it.
Well... I wonder how, in general, FishCAT aligns with the "overall"
testing and QA process for GlassFish done all along the Oracle software
development procedures. From my point of view, FishCAT people can be
active in two general directions as far as testing is concerned:
1. They can do "breadth" testing. This is rather simple: Take your
application (no matter whether developed in-house, some pimped-up
open source component or even an off-the-shelf open source or
proprietary application), dump it into GlassFish, make it work with
the server. This, in my opinion, serves two purposes: (a) It
drastically widens the set of configurations and environments "known
to work" with Glassfish, and (b) it eventually exposes issues and
problems not addressed while testing the server all along the
outlined test cases. How does that container behave while deploying a
slightly mis-crafted .war module? How do things behave if you, in
example, dump in an application massively relying upon Spring,
slf4j, ... ? Having a wide community of users with a lot of different
applications, different environments, different use cases in my
opinion can provide a vast set of helpful input here.
2. They can do "focussed" testing. Provide a list of more or less
well-defined test cases and eventually a deadline until which to test
them, let users "adopt" test cases and make sure they provide you
with information how their tests did get along. This is a more
structured working approach which is not covering all the breadth of
possible Java EE applications, but it seems a good way of doing "load
balancing" the testing work across many shoulders.
Case (1) obviously is "community testing". This is what each and every
user does when (s)he tries to adopt a new runtime platform for an
existing application environment, and, doing so in course of something
like FishCAT is a win-win situation: The testing user gets help getting
his/her applications to run with the new runtime, thus helping during
adoption of the new technology and widening the user base. The testing
process, on its side, gets feedback and eventually is provided with
information on issues just discovered in this very situation. This
scenario is not very specific and it is difficult to predict how
successful it will be, but overally I think there are good chances for
it to be successful given enough people testing the container under
different environmental / application conditions.
Case (2) also might be considered as "dedicated" testing. If (in (1))
you try to adopt a new platform for _your_ existing applications, this
is something you can do pretty well all along your day-to-day business
tasks if maintaining and developing on that platform is part of your
job. Doing "dedicated" testing by adopting given test cases and doing
that specific testing in a pre-defined, predictive time frame is real,
additional work, this is something likely to be way more effort, way
more additional time spent on that testing.
From that point of view, I'd say: (1) doesn't really need a rewarding
model too strict, as users do benefit here from getting qualified hints
and support in course of adopting the platform while providing back
input they gathered all along their everyday work. This is fine. In
case of (2) however, thinking about a more decent "rewarding" scheme
might be sane to compensate users for the fact that the "dedicated
testing", asides overally making the product better and providing
valuable feedback, has no obvious and immediate use to such a testing
user.
> I dare to say that a "reward approach" when is done right will
> attract hundred times more people comparing to "pure enthusiastic
> approach" :)
Maybe. But even if so (again, look at the Sun forums that have "Dukes"
vs. a whole load of other, open forums that do not provide anything
like this). The Ubuntu Mailing List is one of the friendliest places
I've ever been, a place where a whole load of people are likely to
quickly help you out without second thought. It works... ;)
> with simple technology approach. If millions of developers who are
> using Firebug had a very quick mechanism to make micro donation to
> the author of Firebug they would do it without doubt.This case with
> the author of Firebug all about how quick process of payment is.
Yes. Actually, in most cases it's "organizational" hazards like this
that keep me from financially supporting such projects...
[...]
> not that bright.In my opinion current business model of open source
> projects is pretty weak.Too often only way to make the money from
> working on open source project is providing support to clients who
> are using it.What if the product is done perfectly and with good
> documentation then no needs for people to pay for support.
You have a valid point here definitely, but I think there are different
fields of software to be taken into consideration: Selling, say, a
"boxed product", I am completely with you. If you make an office
application "good" enough for users to not need support anymore and
give it away for free, you'll for sure run out of money / business
pretty soon. Then again, middleware or application development
platforms are, at least to me, a wholly different kind of beast. In
example talking about building a complex distributed application, the
cost spent on runtime (appserver, database, ...) environment and
support, no matter whether you go JBoss or WebLogic or WebSphere, is
pretty small compared to the total costs of your application, including
things like training (helping you to get the most out of these tools),
consulting (helping you to understand how to, at best, apply the
solution these tools provide to your specific use cases, assisted by
people who have enough experience to give you valuable guidelines
here), performance tuning (figuring out why the **** the application
seems to come to a grinding halt once or twice a day...) and so forth.
In such a situation, I dare to say a company offering support based
upon a rock-solid open source platform has a pretty comfortable
standing as they can focus on what they primarily do (supporting,
training, educating users, providing project-specific help and
solutions) rather than mainly developing a "generic" software platform
which, in itself, will have a hard time to go break-even in terms of
money earned this way. Or, looking at things from another point of
view: A lot of open source based businesses I dealt with so far seem to
live off the idea of selling "enhanced" versions of open-source
toolkits: The stuff at the core, the frameworks, platform, ... can be
used by everybody open and free of charge, given you know how and/or
are willing to learn. If you want to have it easier, you eventually pay
for tools or technology (Glassfish Enterprise Manager, in example - I
hope I got that name right... :) ). No matter how you put it: For a
company, developing the "whole thing" on your own is likely to be
pretty expensive. From that point of view, I see open source at the
core of it as a good solution to earn money by providing customers with
services and support that actually has a value to them. If you're about
to buy a desktop office application, you eventually do not need that
much support and are done the very moment you paid for your license. If
you're about to build a complex distributed application, no matter
whether you pay or use free(beer/speech) runtime technology, after
choosing the runtime technology you haven't gotten anywhere yet - all
the work still is left to do. Most of the expenses still will have to
be made all along the way.
> That is a great news that you are founder of JUG. I'm sure this fact
> is give you a big leverage to quickly promote "motivation" engine.If
> many people will accept and willing to follow the conception of the
> developer's currency than official proposal to Oracle will get
> serious consideration.I wondering how many people can you bring to
> the discussion?It's critical to success of the "motivation" project
> number of people in it.
I will see. :) At the moment, looking back at the last couple of years,
I honestly have to say that Eclipse and OSGi is the dominating
technology in the JUG environment, and people seemed to stay away from
Sun technology apart from the JDK of course. The "uncertain days" after
having the Sun acquisition announced surely didn't do much good to
that, and even by now people sometimes ask me "Glassfish? I thought
this is next-to-abandoned now they're all Oracle".
But apart from that, yes, talking about motivation: That's what I
meant. You just have a limited set of folks to be reached, a limited
set of developers that are willing to, asides their day job, also spend
their spare time dealing with software and development. I thoroughly
wonder whether we (FishCAT) can come up with a rewarding scheme
"strong" and promising enough to attract those people who, by now, shut
down their computers and leave their offices at 16:30 in the afternoon
to be sure not to have to deal with code and development anymore that
very day. No, so far I don't have an answer to that. ;)
> I completely agree with you on this. So it makes sense to bring to
> life more lighter currency :) Your detail response significantly
> increased my motivation to push "motivation" vehicle further.
We're definitely at the same side of the car pushing here. ;) The only
thing I would want people to keep in mind: Never underestimate
enthusiasm and people doing things out of passion. I think that
reaching those people is incredibly more difficult, and maybe there are
fewer of them, but I think such a set of people will be way more
"reliable" and available on the long run. Let's see where we will get
this way. ;)
Best regards, have an enjoyable weekend! :)
K.
--
Dipl.-Ing.(BA) Kristian Rink * Software- und Systemingenieur
planConnect GmbH * Könneritzstr. 33 * 01067 Dresden
fon: 0351 215 203 71 * cell: 0176 2447 2771 * mail: rink_at_planconnect.de
Amtsgericht Dresden HRB: 20 015 * St.-Nr. FA DD I 201 / 116 / 05360
Geschäftsführer: Stefan Voß, Karl Stierstorfer