Hi Kristian,I went to your blog and should say that you are very productive writer.I like your manner of writing beside the fact that many of your posts is interesting to read. Now I know more about you and way you are thinking :) > and first off, again thanks for your well-written statements - food for> thought indeed, that's what I like about FishCAT, too. :]
I'm very thankful that you are paying so serious attention to this discussion. At least for me that is enough motivation to go further.
> providing meaningful and profound issue reports could raise someones> attention and help you in times of need? Surely, it's not reliable...
It's definitely not reliable :)Let me put here another in some way interesting example because there was involved FishCat member.I'm talking about Adam Bien who was active participant in the program.One day he posted this blog:
http://www.adam-bien.com/roller/abien/entry/glassfish_will_be_killed_closedOne of the comment he got right away was:"Adam,Fishing for traffic? Sad."
I'm afraid that you also will need to "kill" something or somebody to get attention at time of fishing :) Anyway when you are designing some kind of software system I'm sure you are trying to make it scalable and unifiable as much as possible. So in process of designing motivation system please do not try to align its design to your personal chances to win the war of the attention.
> 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.
Finally after analyzing both of your letters I found the point from where we can quickly come to some conclusion and define common ground. I should stress that we are trying to design the new workable system and we need to get it right. On my work I almost every day design a new functionality and very closely work with the users who will use it.In many cases users are not very happy in the beginning of the process. The first problem here is the fact that users have a big problem to define precisely what is wrong or what they need. Beside this users don't know what is possible and how it can be implemented. So I pretty much trained in guessing and recognizing what have to be done to make them happy.Issue that you are highlighted with awarding schema pretty good is described in details and you even used some supportive terminology to make things more clearly. But I wasn't prepared to address your concern properly because I failed to see if the problem exists. Let me put your concern in more unified form. In my interpretation you are saying the following: "Why to introduce award schema for services that can be provided for free?" It's important question that we have to be prepared to answer on it.After all Glassfish team could rise this question during negotiation with them. Your main problems with this issue is if I understand you correctly that it could take too much resources from Glassfish team to pay absolutely for everything and also that too much efforts will be taken to control and handle it properly. In the same time you agree that in many cases additional motivation makes sense.
Arguments that support idea to award services that potentially could be free:
There is always a blurry line between "free" and "awarded" services.Free services often is treated as not worthy or without much value and this is not good at all.Providing additional playing field for people who provide "free" services.Possibility to estimate and take in account value of "free"/small services.Bigger operating scope for "duke" currency.
You know I'm not a big fan of volunteer based services for two reasons. The first reason is that this kind of services take away potential work places from people who really need a job and the second reason is that volunteer work is free.In too many cases people become volunteer because they just can't get the regular job. In my opinion the society is cheating in this regard pretty much. One more view related to "small" services. Practically every day I see people who are gathering empty bottles.For every bottle they get a few cents and this incentive is enough for them to do this kind of business.This is win-win situation for both sides who participate in transaction. Important to mention that side who is paying fee for the service is very affordable and effectively resolved recycling issue. Important to remember: One main condition here is that fee for small services must be affordable!Example with "bottles" business seems is a good illustration of meaning "additional playing field".
> 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... ;)
One of the explanation friendliest of the Ubuntu forum could be that many of them working as network administrators and have more time on their hands comparing to typical developer. For them it could be some kind of "customer support" oriented training. Of course it would be interesting to organize "motivation survey" there and get more precise data on this.
> Yes. Actually, in most cases it's "organizational" hazards like this> that keep me from financially supporting such projects...
Good, here we are on the same page.
> 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... :) ).
We could try to put in trade agreement with Oracle possibility to buy "Enterprise Manager" for dukes.Regarding your description how open source business model is working I agree completely with the picture you put here.In my previous letter I intentionally simplified related model to make point that this model is not ideal and need to be redesigned.It's very big topic that we could discuss a little bit later.
> 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.
I honestly believe if Oracle will accept our trade policy Glassfish will quickly become dominated technology :)
> 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
The key word here is "limited" if virtual currency will start works we will forget meaning of "limited" word.
> enthusiasm and people doing things out of passion. I think that> reaching those people is incredibly more difficult, and maybe there are
Just take in account how incredibly easy we can reach people when we have currency on the hands :)
Best regards,Vladimir
> Date: Fri, 25 Jun 2010 22:32:48 +0200
> From: rink_at_planconnect.de
> To: quality_at_glassfish.dev.java.net
> Subject: Re: Request for comments : FishCAT, the way forward
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2