A simple analogy:

But if someone wrote a patch that adds autoscroll support to FBReader, and then found out:

1. The patch will only be included in the next version, which won't work on N800/N810.
2. He is not legally allowed to distribute his own version of FBReader, only to explain to users how to patch source and build their own version.


How likely will the developer be to continue working on FBReader?

matan, specifically regarding fbreader note what I put at the bottom of these threads

http://www.fbreader.org/mantis/view.php?id=98

http://www.internettablettalk.com/fo...ad.php?t=26126

However misguided my approach I want to do whatever is possible to help

@QGil:

A little bit about motivation:
Humans (when not forced) will not work for free. So, in order to get any development going, your developers have to get motivation. There are just two major sources of motivation:

• Material (money, toys, food, free travel opportunities, etc. with money easily leading the list)
• Psychological (seeing results of your work everywhere, crowds of people coming to you for advice, groupies sending you flower baskets, etc.)

Now, if we get the first motivation source off the table, we are left with psychological motivation. That is what makes open source developers do their work for free. The main problem with psychological motivation is that it is elusive. Very few people can work on psychological motivation alone for long periods of time: at some point, you will still have to pay them. Aside from this, here is a few hints how you can kill all psychological motivation in your developer community:

• Let developers work on their projects but do not promote the results of their work in official products, so that developers feel like you do not care what they are doing. This is a sure way to kill all community development.
• Force strict procedural guidelines on your developer community. Make developers sign NDAs, adhere to style guides, use the same centralized version control system, request digital certificates, go through extra loops just to make their stuff available to the users. See Symbian development model for hints on how you can do this.
• Herd developers into large groups working on big projects. This serves two purposes: 1) it makes every individual's contribution look small and insigificant and 2) causes your developers to endlessly argue about technical details with the losing side quitting in disgust.

PS: Calls like "let everyone just select a project and start working on it" do nothing to motivate your developers and thus will not produce any meaningful results. But you probably know it by now.

You aren't really speaking about FBReader, are you?

Even in small and pure community free software projects you are encouraged to contact the developers before going ahead with a significant patch adding a completely new feature to the project.

If you dislike the criteria of the maintainers you can always go ahead with your own fork.

All this existed years before Maemo started.

@mfs

Mmm it seems that many of you can't avoid seeing me as a Nokia employee. I'm really talking here about collaboration between individuals and community projects. Nokia and corporate projects are totally secondary here.

Also I'm talking about my experience as contributor to community projects. I wasn't born in Nokia and actually I have spent more years in free software community projects than inside the company.

Your points are interesting for another discussion, the collaboration between individual developers and Maemo SW. Feel free opening a new thread with the very same points and let's continue there.

This is exactly the point - I can fork FBReader, I can fork debian (another analogy that came up in this thread), but I can't fork OS2008.

The problem I discuss here is not that the system is closed (that's for another discussion) - but that some people claim it is more open than it actually is.

But, for better or for worse, you are a Nokia employee, so it is a weight you will have to carry no matter what. Having said that, the points I have listed are not specific to Nokia. They are relevant to just about any community project.

I can understand your frustration, but you're missing the point. The ball is in Nokia's court.

Open Source isn't about spending money to "buy" a community, nor about "managing" a community. If a product line is deserving of developer interest, a vibrant community will build up around it spontaneously, very rapidly and without any difficulty.

If people perceive that Nokia might have lost its way with internet tablets, then only the loyal stalwarts will remain. That's the problem right now. As soon as it's clear that the future is bright, the community will grow rapidly and easily.

Here's where I stand: As soon as Nokia confirms details of the next hardware, I can decide that it's worth my time committing towards it. Personally, I'm not interested in any device with a smaller screen than my N800, and wouldn't develop for it. But something as good as the N800 and twice as fast? Sure!

Each person has their own criteria, but no-one wants to be stuck with a dead horse so we need some signs of optimism if we are expected to wait 6 more months or more for an already-overdue device.

Secrecy about future hardware is fine if you are a closed shop like Apple, but if you want developers on board you need to release information as soon as it's available (naturally with disclaimers that plans might change etc). If Nokia thinks this would put them at a competitive disadvantage, they don't understand open source.

Seriously, we only do that because we really care about the product niche. And we don't try to tell Nokia that they must do things a certain way, we just say that if they do them that way then we as developers will be happy. And surely Nokia wants happy developers?

And we are no more "telling a corporation how to do business" than you are "telling a community how to do business".

Regards,
Roger

Quim, I'm not sure if your initial post was directed at me or just a general rant around what I was saying...

If you are talking to me specifically, I am by nature a "Master of Every Topic in 1001 discussions" so please don't ask me to completely overhaul my personality. That's how I roll. I am better at facilitating from 1,000 feet in areas like this than in dwelling on details... especially since I am largely still unfamiliar with the ins and outs of Linux details. EDIT: also, until 2 weeks ago, I felt it was well within my rights to tell the corporation where and what to do. That was in fact my obligation as an employee.

Anyway, I have no qualms against helping on any project BUT I feel like the various efforts are by and large too diffused, too ignorant of each other and too individually oriented for me to know where to begin (that said, I have engaged in testing and feedback).

But you know where I come from: the professional world of coding. My experience programming under Windows affects my outlook here. I don't have much Linux/OS experience at all so perhaps the situation that I see as chaotic may be perfectly okay for you. However, I would like to draw an analogy: I used to be involved in FPS game mapping design in one community. There were many, many projects going but the few that survived and were highly enjoyable were those that were well staffed and professionally approached. Take just one of those aspects away (as happened to my project when staff vanished) and the result is less than desirable.

In the end there were hundreds of maps, many with the same basic concepts, and that diffusion did significant damage to the overall concept and drove new players away. Some of us tried to corral the disparate developers into larger projects to prevent confusion and unnecessary overlap but too many map makers were far too independent to participate in teams.

I've seen pretty much the same thing with third party Maemo solutions. Again, I think lone coders are okay but to an extent-- I believe most efforts should be performed by teams. But I doubt that was possible before the foundation of the council, and I'm hopeful its creation will result in some guidance at the very least.

From past experience I know that you can get the wrong impression of what I'm saying, and I'll take at least half the responsibility for that. Maybe I sometimes choose words poorly. If you still have problems with what I'm saying here, by all means let me know.

EDIT: speaking of which, see what Roger said in the post above mine. He put it very well IMO.

EDIT 2: kudos to fms as well for touching on the importance of psychological motivation.

To continue on the theme, maybe what's needed here are "official" mentors. People who monitor startup projects and then step in to offer guidance where needed. Of course, receptiveness by the project's originator is key here but I am hopeful such an approach could prevent a great deal of what is being addressed.

EDIT 3: the more I think about it, the more I also take exception to the title of this thread. Sometimes talking IS doing.