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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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.
