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 15:01:02 GMT
Well, Friday has come and gone and (with exceptions) the response has
not been over whelming.

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?

Failing that, and taking it upon myself to make some suggestions, here's
what I'm seeing from the emails still being fired around.  In short, I
believe we should be focusing on the following;

The Ultimate Goal: River to be used in more projects

Two Focus Areas:
1) Better prototyping experience
2) Apache adoption

/The Ultimate Goal: River to be used in more projects/

This is what I believe is something to aim for.  I'm seeing people write
emails about how Jini has been dismissed as a solution to a problem or
been replaced as the solution to some project.  What I'm not seeing is a
growing list of Jini success stories.

Without adoption the project is likely to stagnate and dwindle and with
adoption the community is likely to increase in size and commitment
which will drive further adoption.  The reverse is also true, without
adoption the community will (I think) start getting bored and move on to
other things.

Counting downloads seems like it might work as a measure of success, but
counting contributors or activity on some River-wiki or similar might be
better approach.  What I don't know is how to decide that we've arrived
at the goal or when we think we're close enough and should switch goals.

/Two Focus Areas/
1) Better prototyping experience
To increase adoption we need to make it easier for developers to
prototype solutions (or provide more varied part-solutions for
download).  Making it easier to get-up-and-go will hopefully start
convincing people that Jini is a viable solution and (within sensible
defaults) is easy to start adding business value with.  

This might include a nice service browser and developer tools.

2) Apache adoption
To convince people to use River we need to convince them that the
community is active and will stick around.  Getting Apache adoption will
lend us credibility which we maybe don't currently have.  I see it as an
affirmation that the project is alive and 'endorsed' by Apache and is
therefore healthy.

What do people think of these?  Can we get started?  What's next?

Cheers,

Tom



-----Original Message-----
From: Sam Chance [mailto:sgchance@gmail.com] 
Sent: 15 November 2008 04:49
To: river-dev@incubator.apache.org
Subject: Re: Deciding the Future

I like it!  Thanks for taking the time to capture all the points and
write
an outline!  BZ!

Count me in.



On Fri, Nov 14, 2008 at 5:39 AM, Tom Hobbs <tom.hobbs@sucden.co.uk>
wrote:

> Hi all,
>
>
>
> I've been watching these "Future of Jini/River" emails with interest
> these past few days, and being new to the River dev community I
started
> getting pretty excited about all The Next Big Things that River could
> accomplish.  This excitement then got reduced to disappointment by
> Dan...
>
>
>
> "...I'm pleased to see this debate.  However, I've seen it a number of
> times before and it's ultimately yielded no advancement... Will it be
> any different this time?" - Dan Creswell 12/11/08
>
>
>
> So here's my attempt to make things different this time.
>
>
>
> I've just finished going through the emails of the past few days and
> picking out all the bits and pieces people have said they want or that
> we "must" see before the project can take off and go places.  The good
> (maybe) news is there are lots of different ideas.
>
>
>
> Here is my proposal.
>
> 1)    Everyone who cares read this list (at bottom of email).  Let's
> spend until Friday 21 November (Warning: date chosen at random) adding
> to and correcting it.
>
> 2)    Spend the following 7 days (until Friday 28 November) doing
three
> things:
>
> a.    Identifying The Ultimate Goal, e.g. a gazillion downloads every
> day, River running on every toaster, sexiest user experience in the
> world, whatever
>
> b.    Decide on top two areas which are important to the community,
e.g.
> Easy get-up-and-go for developers, better/some developer tools,
adoption
> of more protocols and options, performance enhancements, new features,
> bug fixes, business tools for River systems (IncaX replacement?), full
> Apache adoption etc
>
> c.    Put our wish list under the categories of the top two important
> areas, everything else (however cool) gets archived until we start
> getting somewhere with our chosen two areas
>
> 3)    We take a consensus of the dev list to decide which of these
> things has what priority, we put /dates and names/ against of them.
>
> 4)    Then we start getting things done.
>
> 5)    ...
>
> 6)    Profit!  (Sorry, couldn't resist that one.)
>
>
>
> I understand that some people are only interested in certain parts of
> River and those parts may not make it into the Top Two this time
round.
> But we have to start somewhere and as others have said, unless we
agree
> on a /limited/ direction we'll all be trying to do too much, in too
many
> different directions and we'll get no where.  So I encourage everyone
to
> get involved regardless of where your own pet-features land in the
> priority lists.
>
>
>
> As I said, I'm new to the dev community, so if this is the wrong
> approach or if there is a better tool than the mailing list, or if
I've
> trod on someone else's toes and I'm out of line, then I apologise.
I'm
> just eager to get involved and help to push this project forwards -
for
> whatever value of "forwards" the community decides on.
>
>
>
> Note: Please forgive me if I have attributed an idea to the wrong
> person, any such instances are mistakes and not intentional.
>
>
>
> Note: I fully expect that I have put some things in the wrong
categories
> or chosen wrong categories entirely.  Please don't get sidetracked by
> that, the item itself and not its category is what's important.
>
>
>
> The list follows.
>
>
>
> Cheers,
>
>
>
> Tom
>
>
>
> (Apache) Adoption
>
>  * Release AR2 (Everyone all the time?)
>
>  * Namespace change (River-261)
>
>  * "Let's make the code easy to get, easy to build, easy to use. Let's
> post nightly builds" (Jeff Ramsdale 12/11/08)
>
>  * Roadmap, release schedule, plan of regular releases (Jeff Ramsdale
> 12/11/08)
>
>  * Commit patches already committed (Craig L Russel 10/11/08)
>
>  * Marketing-style blurb; why YOU should use River (Tom Hobbs
14/11/08)
>
>  * publish and promote [the River project] (Jeremy Easton-Marks
> 10/11/08)
>
>
>
> Beginner Use
>
>  * Provide some clever default services to get up and running with -
> "Fast Track" (Niclas Hedhman 13/11/08)
>
>  * Program to probe hardware and recommend Jini config (Jools
13/11/08)
>
>  * "Build a Jini service with UI in 10 minutes" tools/help/examples?
> (Calum Shaw-Mackay 12/11/08)
>
>
>
> Developer Use
>
>  * Netbeans and Eclipse tools (Wade Chandler 13/11/08)
>
>  * Cleaner API for "ease of use" (Wade Chandler 13/11/08)
>
>  * Annotations and abstract classes for service start points (Wade
> Chandler 13/11/08)
>
>  * Make it easier to checkout code and run tests locally (Niclas
Hedham
> 10/11/08)
>
>
>
> Advanced Use
>
>  * Easily navigatable documentation for (more) advanced concepts and
> options (RMI vs JERI, Transient/Persistent/Activation, Configuration
> etc) (Tom Hobbs/Niclas Hedhman 13/11/08)
>
>  * Provide skeleton examples of services that fulfil some common
> business goal, syncing, failover etc - think distributed GoF-style
> design patterns (Tom Hobbs 14/11/08)
>
>
>
> Enhancements
>
>  * Move to Java 1.5 (Wade Chandler 13/11/08)
>
>  * "supporting CLDC(MIDP) and CDC" (Wade Chandler 13/11/08)
>
>  * Support for simplified testing (Niclas Hedhman 13/11/08)
>
>  * Bug fixes (everyone all the time?)
>
>  * New lookup service (Gregg Wonderly 11/11/08)
>
>  * Jini Desktop environment (Gregg Wonderly 11/11/08)
>
>  * Password access (Gregg Wonderly 11/11/08)
>
>  * Proxied Authorization (Gregg Wonderly 11/11/08)
>
>  * richer set of APIs for GUI based service UI (Gregg Wonderly
> 10/11/08)
>
>  * inbound calls run as the remote user's Subject (Gregg Wonderly
> 10/11/08)
>
>  * zero code downloads at startup (Gregg Wonderly 10/11/08)
>
>  * River-based BPM/Orchestration capability (Sam Chance 10/11/08)
>
>  * Replacement for IncaX (since that it is no longer supported) (Sam
> Chance/Tom Hobbs 10/11/08)
>
>  * "Using River, build an internet scale, decentralized, autonomic,
> dynamic PF&B service management APPLICATION that is browser base, OSGi
> technology based and Service Component Architecture (SCA) based.  The
> framework should allow rapid creation and deployment of services.  The
> binding protocol should be based on ATOM or something similarly open.
> It shoud allow end users to build ad hoc worklfow by combining
services.
> It should not be wed to SOAP, but allow SOAP.  It should allow REST
> also." (Sam Chance 10/11/08)
>
>  * Configuration System (Niclas Hedhman 10/11/08)
>
>  * User-type targetted Security System documentation (Niclas Hedhman
> 10/11/08)
>
>
>
>
>
> 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.




-- 
Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)

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