river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Hobbs" <tom.ho...@sucden.co.uk>
Subject RE: Deciding the Future
Date Mon, 24 Nov 2008 17:29:52 GMT
Hi Jukka,

Thanks for the response.  You've raised some interesting points (in my
own head at least).

The incentive I had for starting this is my (mistaken?) belief that the
"River community as a whole" (whatever that is) was aimless with each
individual wanting to scratch their own itch and there being no real
shared goal.  I got the impression that "People" wanted such a direction
and goal and deliberations were happening about what they should be.  I
was trying to shove that into motion.

This is the first open source project I've tried to become active in, so
I guess you can write a lot of this off as an over abundance of
newbie-exuberance.  :-)

I don't want to come across as being defensive.  I'm, if not happy then
prepared, to be corrected.  But as for the three tasks I called people
into action over; yes I did do them, but no I didn't post about them.
Perhaps I should have.

> What's in that for me? Increased adoption only brings me indirect
> benefits in terms of increased project activity, but it won't help
> with the issues I face today.

This is the statement I have the most problem with - but again it's
possibly down to my misunderstanding of what the "River Community" is
and wants.  To use a tired house builder analogy; if you're standing in
the rain and all you want is a roof over your head, why waste time
having your builders dig a hole in the ground and fill it with concrete?


That's what goes through my mind when I think about trying to move River
on.  We all are facing issues about the code base that directly impact
our immediate problems.  But is there a step beyond that, beyond the
here and now which is the direction "the community/project" should be
taken to salve tomorrow's itches?

I /want/ it to be a large and successful project and my reason is "just
because".  I like the technology, I work with it every day, it is
actually pretty cool and clever.  Dropping "River" into a conversation
and not having people look confused or dismiss it as irrelevant would
give me a pretty good feeling.  Since River has taken over from Jini and
my day job revolves around Jini services, keeping the code alive and bug
fixes and features coming in will make my 9-5 easier also.

> No, the only (sustainable) way you can get someone to adopt a project
> is to have it solve some real problem they are having. No amount of
> community activity will help if that basic requirement is met.
> Similarly there are lots of people who are capable of figuring their
> way out with even an abandoned codebase if the benefits of doing that
> are good enough.

I don't agree with this either.  I've been in several situations and
companies where the inactivity of an open source community has been the
direct reason why we have elected /not/ to use it.  

In my experience the likelihood of being able to convince a manager of
any level to allow the adoption of an open source project which may have
been abandoned or has very little activity on it is very small.  Let's
face it, most of management will want their developers to spend 100% of
their time fixing business problems, not trying to fix the tools they
have chosen to fix business problems.  Won't they?

I get your point about (and I'm paraphrasing) that if you want to see
some activity then submit some code, don't just shout at people about
the code they should be submitting.  But again, what, on a grander
level, is accomplished by a bunch of people sat around only scratching
their own itches?  Should I (or we, or you) care about some grander
level or does the vision not go beyond 'what I'm trying to do today'?

Maybe this just boils down to my own preconceived ideas about what being
involved in an open source project is really like.  I look at other
(bigger and more mature project like linux distros and log4j etc) and
there does seem to be an over-reaching direction that people then submit
code to try and reach.  That's what I thought River was trying to
emulate.

Is this an accurate statement?  

"You're suggesting that if people just submitted code to fix their own
individual problems then growth and activity would be more organic.
Then, as more itches are scratched, more people would then use River
because whatever was blocking them before had eventually been fixed
because someone else scratched it (possibly by chance)."

If that's the case and as a 'community member' I should be scratching my
own itches then I shall now start getting busy getting some patches done
and ready for submission!

I realise that this email is a bit "War and Peace" but writing down my
own thoughts often helps me sort them out.  Which is has.

Cheers,

Tom

-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com] 
Sent: 24 November 2008 15:50
To: river-dev@incubator.apache.org
Subject: Re: Deciding the Future

Hi,

On Mon, Nov 24, 2008 at 4:01 PM, Tom Hobbs <tom.hobbs@sucden.co.uk>
wrote:
> So, if this isn't a good approach, can someone let me know so I can
> stop?
>
> If it is a good approach, can someone 'bigger' in this project please
> back me up and help get things moving?

I do appreciate the effort, but my experience with open source
projects has been that the kind of plan that you're trying to outline
doesn't work that well in practice. You can highlight areas that need
attention, but ultimately it's up to each individual contributor to
decide what areas most interest them.

We're all here to scratch our own itches. There are no "big" people
here that could tell others what to do. Apache is a meritocracy, so
the only way you can really lead is by doing things, not by calling
others to action. RIVER-296 is a good first step!

As an example, you called for us to "Spend the following 7 days doing
three things". Did you do that? Why would you expect anyone else to
have done that? In Apache you lead by example. :-)

You state the ultimate goal as: "River to be used in more projects".
What's in that for me? Increased adoption only brings me indirect
benefits in terms of increased project activity, but it won't help
with the issues I face today.

> 1) Better prototyping experience
> To increase adoption we need to [...]

Are you scratching your itch or someone else's itch? Rephrase the
issue as "to make my work easier, I need to ...", and you're on to
something. Often you're not the only one with a problem, and so
getting your problems solved will ultimately also lead to increased
adoption as more people find the project useful.

The people following this mailing list have all probably done at least
some prototyping with Jini and/or River. Will you'll be doing more of
that in the future? What changes in River would make such work easier?
What can you do to make those changes happen?

> 2) Apache adoption
> To convince people to use River we need to convince them
> that the community is active and will stick around.

No, the only (sustainable) way you can get someone to adopt a project
is to have it solve some real problem they are having. No amount of
community activity will help if that basic requirement is met.
Similarly there are lots of people who are capable of figuring their
way out with even an abandoned codebase if the benefits of doing that
are good enough.

BR,

Jukka Zitting

www.sucden.co.uk
Sucden (UK) Limited, 5 London Bridge Street, London SE1 9SG
Telephone +44 20 7940 9400
 
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA
register under no. 114239

This email, including any files transmitted with it, is confidential and may be privileged.
It may be read, copied and used only by the intended recipient. If you are not the intended
recipient of this message, please notify postmaster@sucden.co.uk immediately and delete it
from your computer system.

We believe, but do not warrant, that this email and its attachments are virus-free, but you
should check. 

Sucden (UK) Ltd may monitor traffic data of both business and personal emails. By replying
to this email, you consent to Sucden’s monitoring the content of any emails you send to
or receive from Sucden. Sucden is not liable for any opinions expressed by the sender where
this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation
to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message