You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Patricia Shanahan <pa...@acm.org> on 2015/04/29 04:37:35 UTC

State of the River community

My next board report is due by May 6th. The board is increasingly 
pushing for realistic and detailed assessment of the status of each 
project community. Generally, the board does not get involved in what we 
are doing, just in whether we have a functioning developer community 
doing it in accordance with ASF policies.

It is an extended time since we added a really new committer and/or PMC 
member. The last change was my return to the PMC.

My impression is that we have a problem. We have things that need doing, 
such as improving the new user experience, getting out a bug fix 
release, and getting our QA code better organized.

Although I have some free time, I don't have the background to do the 
most urgent things right now, practical experience with River itself and 
with modern build and distribution tools. There are community members 
who do have those skills, but may not have the free time to make much 
progress.

If this impression is correct, I should discuss it in the board report, 
preferably with a realistic plan for improvement. Of course, I would 
love to be convinced I am totally wrong and that all is well in River-land.

Patricia

Re: State of the River community

Posted by Patricia Shanahan <pa...@acm.org>.
On 4/29/2015 9:45 PM, Greg Trasuk wrote:
>
> Hi all:
>
> We have enough active committers to collect 3 ‘+1’ votes and make a
> release.  So the project is stable and functional, if not very
> active.

I should have mentioned some of the things I think are right about the
project. We have several very able committers, including, as Greg points
out, a PMC quorum for approving a release. Mailing list communications
tend to focus on technical and policy issues, not personalities. We
don't have a lot of problems I have heard about in other projects, such
as splits into factions that talk past each other.

> But, having said that, yes, we have a problem, and we have had this
> problem almost since the inception of the project.  We do not have
> agreement on the future direction of the project.  I’m not sure if we
> even have a good collective understanding of what River ‘is’, never
> mind what it should be.  Some of our community use JERI as a plain
> remote procedure call mechanism, without using the service discovery
> or mobile code aspects of River.  Some of our community want to
> rethink River as some kind of Internet operating system.  Some of our
> community want to experiment with interesting security policies and
> serialization techniques.  We have huge amounts of work (I am guilty
> of some of it) that has been done in isolation, without a collective
> understanding of what we should be concentrating on.

Thanks for the detailed and constructive analysis. I would appreciate
input from others giving their own analysis.

Patricia

Re: State of the River community

Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi all:

We have enough active committers to collect 3 ‘+1’ votes and make a release.  So the project is stable and functional, if not very active.

But, having said that, yes, we have a problem, and we have had this problem almost since the inception of the project.  We do not have agreement on the future direction of the project.  I’m not sure if we even have a good collective understanding of what River ‘is’, never mind what it should be.  Some of our community use JERI as a plain remote procedure call mechanism, without using the service discovery or mobile code aspects of River.  Some of our community want to rethink River as some kind of Internet operating system.  Some of our community want to experiment with interesting security policies and serialization techniques.  We have huge amounts of work (I am guilty of some of it) that has been done in isolation, without a collective understanding of what we should be concentrating on.

And in all of this, we have consistently failed to consider the needs of _users_ of River.  As a result, I suspect there are very few users of River.  I strongly suspect that most users of River are holdouts (like me and Dennis) from the Jini days.  We have entirely failed to improve the ‘new user’ experience for River.  And us old fogeys have failed to explain how and why to user River, even to other members of our community.  Which is a shame, because we are standing on the cusp of a wave of opportunity.  And since there are no users, there are no potential committers.  Hence our problem.

So, what I think we need to do is something like this:

- Agree that bringing new users in to the River/Jini space is the critical factor for success.
- Decide what we need to do to bring new users in.
- Do that!

What do we need to do to bring new users in?  Probably lots of things, but I suspect they will include:
- Show and tell what use cases are appropriate for River
- Make it easy for new users to adopt River in order to address those use cases.

When we bring in new users, those users will ask questions and show us where the River codebase needs to improve.  Hopefully some of those users will even be interested enough to submit patches for the codebase.  Then we’ll have potential new committers.

So I’m arguing that the key effort we need is to define River’s target space, and then go crazy showing examples and talking (on blogs, Youtube videos, InfoQ articles, other Apache lists, wherever we can) about how River can make life easier for developers.  

My argument for the target space: Java-based micro services that don’t depend on http.  Selling point: You can integrate without having to cast everything as a RESTful service.  Rather we can define Java interfaces for services and build collections of micro services in a Java-natural way.  Discovery and Join removes the configuration effort.  Proxy-based service access allows us to easily integrate well-known infrastructure services like Zookeeper, etc, but still write integration code in Java and minimize the configuration effort, while offering scalability.

I’m in the process of adding an example of accessing River-based services inside a web app.  That opens the door to deploying collections of River-based micro services in the cloud as the back-end of a RESTful client app, or a regular web app.

Any other ideas?

Cheers,

Greg Trasuk.

On Apr 28, 2015, at 10:37 PM, Patricia Shanahan <pa...@acm.org> wrote:

> My next board report is due by May 6th. The board is increasingly pushing for realistic and detailed assessment of the status of each project community. Generally, the board does not get involved in what we are doing, just in whether we have a functioning developer community doing it in accordance with ASF policies.
> 
> It is an extended time since we added a really new committer and/or PMC member. The last change was my return to the PMC.
> 
> My impression is that we have a problem. We have things that need doing, such as improving the new user experience, getting out a bug fix release, and getting our QA code better organized.
> 
> Although I have some free time, I don't have the background to do the most urgent things right now, practical experience with River itself and with modern build and distribution tools. There are community members who do have those skills, but may not have the free time to make much progress.
> 
> If this impression is correct, I should discuss it in the board report, preferably with a realistic plan for improvement. Of course, I would love to be convinced I am totally wrong and that all is well in River-land.
> 
> Patricia