river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Apache River Roadmap
Date Sun, 11 Feb 2007 12:29:17 GMT
Mark Brouwer wrote:
> I'll try keep it short so I skip many things I could have reacted on but
> likely wouldn't add anything new.
> 
> Dan Creswell wrote:
> 
>> Why would I bother to put a spec into River?  If River is going to be
>> this small in focus, I'll develop services and API's elsewhere without
>> bothering to do specifications.
> 
> I think you confuse specification with standard. To me an API of such as
> service is the specification and I see value in people collaborating to
> specify and implement such a service as part of River. As I already
> said. I see no problem in people collaborating to get something done
> here, but they can also do it somewhere else.
> 

I think you assume that I confuse specification and standard.  Actually
I have my own very clear definitions but maybe they aren't the same as
yours. ;)

>> Boring == few developers == project that doesn't need to be at Apache
>> with high visibility and might as well sit on SourceForge in a dark
>> corner.
> 
> The Apache Software Foundation:
> 
>  - provide a foundation for open, collaborative software development
>    projects by supplying hardware, communication, and business
>    infrastructure
>  - create an independent legal entity to which companies and individuals
>    can donate resources and be assured that those resources will be used
>    for the public benefit
>  - provide a means for individual volunteers to be sheltered from legal
>    suits directed at the Foundation's projects
> 
> SourceForge:
> 
>  - provides hardware, communication, and business infrastructure
> 
> So I think there are plenty of reasons why you want to do even 'boring'
> work that needs to be done here opposed to as in a dark corner at
> SourceForge.
> 

The trouble as I keep trying to explain is that River is threatening to
become a hub/key focus for Jini and I contend that if that's the case
should it be solely about the kind of things you describe it will
further damage Jini's image i.e. it will hinder not help.

Basically, River needs to be bigger than this or we need to ensure
people are sent elsewhere (jini.dev.java.net or jini.org) to start with.
 And that's really difficult to do given the spotlight River is under.

>> It might be successful to you but IMHO, having such a thing so visible
>> at Apache will be a PR disaster:
>>
>> "Some quiet little project at Apache that no-one's interested in, that
>> has a couple of committers tinkering away on little things that no-one
>> appears to care about.  Wow, is that all there is to Jini?"
> 
> In my story I talked about a project that provided the foundation for a
> lot of other exiting projects, so that means a lot of people indirectly
> care about this project. I think not that many people download just the
> Linux kernel and then say "wow that is useful".
> 

The linux kernel was interesting to a lot of people that wanted to learn
operating systems or build their own PC or......

That's a pretty wide audience in comparison with the number of people
that might want to learn distributed systems Jini style.  Remember that
most people who use J2EE think they already do distributed systems and
have (supposedly) learnt all there is to learn hence their relative lack
of interest in Jini.

Therefore, I contend that Linux is a bad example in this case because it
had much broader appeal from a generation of programmers and it has to
be said Linus had a certain aura and style that people found attractive.
 If you wanted to play on a "happening" OS on the latest hardware (386)
Linux was really your only option.  If you want to play on "happening"
distributed systems you go use Web Services i.e.  the crowd is against you.

> Also I refuse to let my need for features I require be based on how the
> outside world thinks of it. I can only hope it will be appreciated but
> that is not my main motivation for contributing here.
> 

Can you clarify that statement please?  From at least one viewpoint,
you've just said "I'm only interested in playing with my Jini and I
don't care what anyone else thinks".

Failing that, perhaps you could explain what your main motivation is?

> I believe there is room for things that Sean's Joe the programmer will
> directly comprehend and thinks this is great, as well as for things that
> makes sure that Joe the programmer won't hit the wall at some point in
> time because somebody already thought of that. There is always room for
> people that don't get all the attention but for which you can only hope
> they are there and I hope these kind of people will also be appreciated
> here too.
> 
>> The kinds of minutae (e.g. PreferredClassLoader changes) we've talked
>> about thus far will not address any of these problems.  If River is not
> 
> I would appreciate it if you stop labeling these discussions as being
> about minutiae. The last thing we need IMHO is people backing of
> discussion about code because it might not fit someones definition of
> relevance.
> 

I will not stop labelling it as such because I see no point in messing
around with this stuff unless there's a bigger context driving it.  And
for me at least that bigger context needs to be about a lot more than
just "it fixes a bug" or "it makes the code nicer" or "it makes the code
more perfect" etc.

However, I will happily stop labelling it as such if you can explain
what that bigger context is.

>> If what you describe is the destiny of River as a user and committer, I
>> see minimal value in what the project will be doing.  I might as well
>> take a simple snapshot of the source code and then evolve it and package
>> it independently in a direction I find more useful to customers/users
>> whilst avoiding the need for endless debate with people that want a
>> small quiet project that does little.  I'd also be crossing my fingers
>> that I can attract attention away from River to avoid the PR disaster I
>> mention above.  Kind of sounds like the behaviour of a number of
>> commercial Jini efforts out there using but preferring not to talk about
>> Jini, why?
> 
> I think we should prevent we get some mindset there is a group of people
> that wants to make Jini irrelevant and that there is a group that wants
> to make it relevant and that are obstructed by the first group.
>

Trouble is that as I suggest above your current line of argument could
be viewed as creating exactly such a divide and just because you would
prefer it not to be that way doesn't prevent it from happening.

> Maybe it turns out that in the end our differences all boil down to our
> way with words, there is nothing so inaccurate as natural language
> especially when spoken by people from different countries and different
> personalities.
> 

Maybe - Mark, the reason I'm prepared to expend a number of hours on
this discussion with you is precisely because I value you and assume by
default we are talking past each other due to difference in countries or
language.

> From what you have said so far I can only conclude you have some ideas
> how Apache River can make Jini more relevant, maybe this is a good
> moment to talk about those ideas.
>

Maybe I do and maybe I'll get to talking about them one day but I'm much
more interested in hearing the "community view", people like Mike or
Sean for example and forming a roadmap from that.

In absence of such feedback and if there's general interest from other
committers I will consider putting them forward.  Otherwise, I will
assume the project wants to focus on the kind of things you've put
forward in which case I will execute on my ideas elsewhere.

> Maybe it turns out your ideas for the roadmap align nicely with the
> ideas of others, so we can all work happily together hand in hand!

Thus far, I'm not convinced they do align hence my irritating
questioning of things as a means of discovering what people do want to do.

Dan.

Mime
View raw message