The cohesive community: from talking to doing
 

This is a spin-off of the Where is Nokia... thread

Executive summary: Do you want to improve this community? Then choose one project and become a regular contributor. Without this step, posting more in web forums like this will barely help.

I don't know if overlaps and gaps are the essential problem and I'm not sure whether management is the solution to whatever is the problem.

In a Sunday morning and 100% with my community shirt, for me a problem is the amount of community energy just wasted in threads where everyone seems to have an opinion about the things that are out of their reach (and actually their deep knowledge). In the meantime, issues within a reach for concrete contributions and change remain open or even unnoticed.

The advice I got when I started getting involved in free software projects was to concentrate on a couple of topics and help out there until getting something done. Sounds simple? It's damn though. But so gratifying every time you succeed.

Here in ITt there are plenty of discussions going on but how much of this talk ends up in some kind of fruitful improvement? Everyone: look your last 10 posts. Look also to random posts you wrote 3, 6, 12 months ago. Reach your own conclusions.

Overlaps. What is the problem with overlaps. Make your choice and help your preferred project improve and prevail. If there are nasty frictions highlight them. Choose one and help fix it.

Gaps. Which gaps? Be precise in use cases and concentrate your energies in those most relevant to you. Find the closest project(s) and help covering/porting the features needed. Or create a new project if needed (although with 763 projects only in garage.maemo.org and plenty of stuff in the free software community you may suspect not being the first one having that great idea and trying to do something about it).

Management? These projects need help! Being no coder is not an excuse. Testing, ideas, mockups, promotion, documentation, user support... and above all continuous support and regular commitment in the smallest tasks. All this leading to tangible results being reflected in new versions with increased download rates and more happy users.

Next time you feel like telling to a corporation how to do business, how to design devices, how to make technology selections, how to launch products, how to watch the competition... think it twice. I'm not saying you are wrong: it's just an invitation to consider where are your skills and energies better invested. Maybe in the meantime there is a single developer of a piece of software you actually like, needing much more your attention and your time.

Re: The cohesive community: from talking to doing
 

What reward does the person get for doing something? I'm not talking about monetary, possessions etc but rather : https://bugs.maemo.org/show_bug.cgi?id=3519#c21

A community member has made a feature for Nokia, which Nokia couldn't be arsed to do for themselves for diablo, with the result that it will never be included officially into diablo (despite the code being more stable than some of the other **** Nokia has put out. Modest, anyone?) and the usual response of "wait for Fremantle".

Re: The cohesive community: from talking to doing
 

Well, this isn't really accurate (and isn't really on-topic for the thread—we're talking about community projects, not Nokia projects we don't have influence over), as the patches exist thanks more to Nokia than to the community. :)

Re: The cohesive community: from talking to doing
 

I was talking about helping small community projects... but anyway.

Ask the people who contributed to those patches what were the gratifications and rewards today. Ask them again in one year time. I'm sure all them feel rewarded in one way or another.

About the patch rejected I have nothing to add to what Eero, myself and others commented in your link.

About the feature itself, let's look it from the overlaps/gaps perspective:

- There was a gap, and the community effort done around this patch covered it. Now it can be used for Diablo community editions. Good!

- There is also an overlap, since Maemo SW covered that feature for Fremantle. The code itself can't be the same for many reasons. The community code goes for Diablo community and the Nokia code goes for Fremantle official. Overlap solved? Users happy?

Re: The cohesive community: from talking to doing
 

Post #2 is bollocks in this thread, I don't think those points are not valid but I do not think this thread would serve well by making it a discussion for #2. I apologise for posting #2 in this thread because it's not fair to derail the original topic described in the long post which qgil took time to write.

Yes, this thread is about community projects and I apologise for bringing an outside topic in. I'm willing to delete #2 but I'm not a ***** so I don't see the point in covering my mistake.

This is not to say that I agree with Nokia's decision regarding the bug but it does not serve well to discuss it here.

PS, qgil, I do appreciate your taking the time to give reasons as to why Nokia can't do something.

Re: The cohesive community: from talking to doing
 

Diablo only gets bugfixes (often, not even security fixes).

Look at it from this angle: feature enhancement should not be applied to Stable. Its for Testing. Diablo is Stable. Fremantle is Testing. Mer is Testing (but different distribution).

It is very difficult (and expensive) to test features like this in order to be good enough for release. What if there is a chance of 1/10000 a bug gets triggered crashing the X server? Many Diablo users would not like that. Therefore, those who want to live on the edge can use Mer. But Nokia assumes the user only uses the official Nokia repositories, and uses the tablet for mission critical work. They have to; its their reputation. Same for SSU. These cannot take into account deep changes. So, what you want to do is protect users who do not have the ability to understand advanced changes to be able to apply advanced changes. You can do this by making it a bit harder to apply the advanced changes, and informing them of the side effects (but not impossible; that implies a vendor lock-in). For example, some 'hacks' apply text settings in /usr but this is potentially dangerous causing regressions.

So, in other words: your point is completely valid but not for the official Nokia distribution; its for Fremantle or a 3rd party distribution such as Mer.

Re: The cohesive community: from talking to doing
 

It's funny that you bring up this topic, because I too have noticed a downturn in the number of people willing to contribute to any kind of project at all. It could be that we have the same number of contributors as before, but a bigger user base (thus making it appear like less are contributing by skewing percentages) and/or more projects which ultimately thin out that already narrow contributor base.

Honestly, it could be either. But I'm also seeing an uptick in the number of people who want something in return for their hard work, and not just a pat on the back and a little recognition anymore. Heck, I'm almost to the point of having to offer cash payments for articles and other stuff from members in order to get people to contribute to my site. I doubt I ever will, as that destroys the exact FOSS principles I'm fighting so hard to maintain, but in general I'm seeing that across the board.

It might also be the economic downturn causing people to be a bit more stingy with their resources too. When times are good, people give freely. When they're bad, you need a crowbar just to pry a penny out of their hands. *rolls eyes*

Either way, something needs to happen as far as contributions go. I contribute anywhere I can, and while my skills don't typically lay in the coding field, I do find lots of things I can do. One project I'm involved in for example is Floss Manuals. It's a great project, but it doesn't require coders, as it's simply a documentation project. But that's fine. Those are needed too.

Re: The cohesive community: from talking to doing
 

Many community projects, and specially those headed with a single developer or two, don't make things easy for potential contributors either. This is a problem known in the free software community.

Proposal: once you ave decided to which project you want to give a hand go there and try to find a task to do without asking them, looking at their website, wiki, bug tracker, roadmap, mailing list archives... If you find a "Get Involved" or a list of open tasks, excellent. If not, probably the guys are too busy and looking not much beyond their releases. Consider starting helping them by putting a Get Involved page in place.

Re: The cohesive community: from talking to doing
 

there are different levels of participation to any project.
If I spot a bug in something I use often and think I can solve it I have a go, but on the whole there is a high barrier to entry due to the sheer amount of knowledge required for anything more than a trivial app.

You need to learn the libraries and get the correct expected development chain configured and get into the mindset and intent of the original developer.

Its *hard* to get involved in a project which explains why so many apps end up stagnating and dying due to bitrot once the original visionary leaves.

I am paid in the daytime to manage and maintain a whole set of applications and keep them ticking and slot new features into the existing framework, but as with many jobs I was not useful for many months simply because I did not know everything required.

A person will not sit down and gain a xenlike knowledge of anything without strong personal motivation (monetary or otherwise) so why expect different here?

Re: The cohesive community: from talking to doing
 

A lot of the problems are solved if instead of trying to be the Master of Every Topic in 1001 discussions you stick to a couple of projects contributing there something that has to do with your skills.

If you are a user with attention to details and you like liqbase go and concentrate there, bugging lcuk pervasively not accepting easy eacuses from him. ;)

Giving a shot to the app in 1h, commenting in a thread on ITt about your first impressions, telling the authors why they should prioritize that great feature you came up with and then vanish forever (while reappearing tomorrow doing the same on another app) brings almost nothing. Only noise and some % of non-satisfaction to the developers.

I was just reading yesterday that user saying that FBreader is great but without autoscrolling is just crap, the developers have no clue what users want and please hurry hurry tell me another app doing just that. Well, this isn't useful. Instead, it would be better asking what is the problem with autoscrolling (maybe it implies a lot of recoding, maybe the maintainers just don't see the point yet) or asking why it is low priority and what would be needed to push it up. And chase the thing until you get one day FBreader with autoscrolling. Because you pushed it and helped making it happen.

This is rewarding.

Re: The cohesive community: from talking to doing
 

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?

Re: The cohesive community: from talking to doing
 

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 :)

Re: The cohesive community: from talking to doing
 

@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.

Re: The cohesive community: from talking to doing
 

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

Re: The cohesive community: from talking to doing
 

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.

Re: The cohesive community: from talking to doing
 

@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.

Re: The cohesive community: from talking to doing
 

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.

Re: The cohesive community: from talking to doing
 

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.

Re: The cohesive community: from talking to doing
 

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

Re: The cohesive community: from talking to doing
 

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.

Re: The cohesive community: from talking to doing
 

Those are good points as well.

And Quim extracted only half of my complaint in order to peel off this separate discussion but I take exception to that: I see the two (hardware and community software) as intertwined.

Back to fms' point about motivation: I suspect the uncertainty about hardware may be contributing to the current state of community development. I see a lot more doubt and cynicism where I used to see eagerness and optimism. Granted, there are those who will point to the Newtons and Palms that enjoyed long post-production lives but how big were the communities and more importantly, the general user bases?

The tablets still have yet to make the mainstream to the extent that other products have. Nokia's official line is that step 5 will do it-- but even there the focus is on future hardware. Yes, there will be software advents with Fremantle and Harmattan but I daresay if you stuck Diablo on faster iron that would go 80% of the way to satisfying user needs.

Anyway I have not yet had morning coffee and I realize I may be largely incoherent so I'll stop here for now. :D

EDIT: ok, coffeed up and ready to go!

I guess I need to make something perfectly clear, especially to Quim:

When I engage in this sort of discussion, it is often in one of the following roles: product advocate, idea stimulator, discussion facilitator or devil's advocate. Sometimes all of the above. This is what I mean by "talking can BE doing". Conversations need to be directed and prodded (although certainly not controlled). That is how I have mostly seen my role here.

Quim, you have a tendency to downplay my involvement with the tablets but the fact is I was highly instrumental in the successful US launch of the N800 and a very important reason why initial quality was as good as it was out the door (I would love to fill you in on details if I have not already). That's not said just to brag-- I am pointing out why I feel confident to self-describe myself as an authority of sorts. Plus, I do have considerable experience as a facilitator in general and enjoy the role of challenging assumptions, asking stimulating questions and drawing out great ideas.

So yeah... in my case, talking IS doing. That's my skill. ;)

Re: The cohesive community: from talking to doing
 

Another thing to remember is that a successful product will have vibrant sub-communities springing up in all over the place, not just in the "official vendor-supported place".

For example the iPhone has a passionate photo-oriented community at Flickr, totally unrelated to the sub-communities that are involved with iPhone music or iPhone applications.

For a product with open sourced software, the diversification should be even greater.

Roger.

Re: The cohesive community: from talking to doing
 

Agreed, but as I'm sure you and most others here are already aware the internet tablets are in an awkward spot: mostly open source software with somewhat open source hardware. They're treading a fine line between open and closed that is largely unprecedented. That's why IMO corporate guidance and support is the most important aspect of the device platform's and OS platform's successes (they can be so independently).

Re: The cohesive community: from talking to doing
 

Texrat, my comments are not personally on you. I always wonder what is this language that has the same word for you-singular and you-plural. The thread started with your quote just because you raised a good point about community projects having plenty of gaps and overlaps, and how to manage that.

This is a topic widely discussed in umbrella communities with no corporate presence where it is easy to get gaps, overlaps and not the best coordination. Here the debate about what the own community can improve hasn't started since you seem to want to discuss first the role and responsability of Nokia.

Well, maybe it's a fair point.

Hardware plans are important to grow a vibrant mobile community nowadays. True. Maemo talks about hardware from a software perspective, certainly more useful for developers than for gadget scoop hunters.

Developers can get a good idea after the OSiM/Summit announcements last September and the Fremantle pre-alpha released in December. There are a couple of threads here and a couple of posts in Planet Maemo with plenty of data. We have said that the trend is going mass-market and we have said that 'Internet Tablet' is not a label we see living much longer.

Should we stress more all this stuff that is known and is coming? Should we stir more discussion about new use cases, potential evolution of applications, areas where third parties could bring more features? Would this help to the cohesion of the community and its vibes?

What else can we do? What would be your concrete and specific

Re: The cohesive community: from talking to doing
 

Yes, I think it probably would. New hardware (and especially new hardware features) are the sorts of things that get many people excited and makes them think about writing cool apps.

On the other hand, things like the feed browser, etc. are applications that could be worked upon now. From your previous thread, Quim, it appears that you'd like the community to do some work on this (which is fine, I think we should), which I presume means that any work we do won't be wasted (i.e. there isn't a Fremantle version being prepared right now which will make any work done on the current one redundant).

That last point, about work becoming redundant is a real problem, people are less inclined to do work on things that may be replaced.

Re: The cohesive community: from talking to doing
 

Yes. Choose one facet of upcoming features if you don't want to disclose everything. The best element would be something which will be most likely changing in upcoming months so each few weeks you could show something new.

Re: The cohesive community: from talking to doing
 

I would have to put some more thoughts into specifics, since as I acknowledged I have been generalizing at a high level. I think there are many areas that need to be tackled so I will think about fundamentals some more. I will probably post further thoughts on my blog and link back here.

Re: The cohesive community: from talking to doing
 

Expressing criticism is easy especially when it is concerning another persons work. I understand criticism is difficult, especially when you know arguments are sound or completely wrong but you are not allowed to say for benefit of all who are involved. Also I understand you feel people spend time wrong.

However, sometimes there is a lot of talking before walking. Some individuals are like that, and some sound decisions are made this way. In the end, we all want common, abstract results such are happiness. If you don't wish to listen to arguments made in discussions, so be it. I sometimes notice bright insights in such discussions though, and others are doing what they're good at as well and sharing this e.g. on UI aspects.

You must also understand some people want certain features in their next device, and because there are disagreements about this rest assured you will pull and push different individuals and groups with the next Maemo release and the next tablet release. Some of people are now indifferent. Others are disgruntled with what they know. Yet others are excited with the information they have. This is normal. We have to accept this. By sharing more information you can create clarity or vagueness. Shadows and riddles can create excitement, but as it seems now, for some its not the right way to tickle them because they're not sure about the new way Nokia is heading at all.

qgil you said elsewhere, addressing readers, if you were excited about Nokia 770 -> Nokia N800 and Nokia N800 -> Nokia N810 you will be excited about the new device. While this holds truth for sure, some people experienced sour aspects of these transitions, and generally speaking every change has its positive and negative aspects.

Lets outline what users can do and where they should head to for what. If some kind of cohesive organisation develops thats great. There are other tasks than bug reporting...

Personally, I tried to contribute to the wiki today, but not much happened (also had to do some house cleaning and such.. and this snow..). For example, when I wade through the old ItT wiki I see a lot of information, but a lot I never experienced (Nokia 770/Nokia N800) so I don't know what is important and what isn't (anymore) so it is difficult for me to understand this let alone export this to Maemo wiki.

Re: The cohesive community: from talking to doing
 

I wish I could pinpoint what exactly it was; I really can't tell you what the problem was.

All I know is that since the high-water mark that was the Summit, I've crashed into a real despair about Maemo and the future of this community.

Perhaps part of the problem is that I just don't see the rewards that fms is talking about coming to developers that I really respect in this community. I can't really elaborate much on this, since this is just a feeling I get from some private discussions.

Perhaps a big part of the problem is that we're in a real state of limbo right now.

Developers don't want to waste huge amounts of effort developing for the current platform right now with all of the talk about the new platform coming in a few months, and, in the meantime, we're being encouraged from all sides to join in the Mer project, which I think is honourable, but completely uninteresting for me. Some people get a great kick out of reverse engineering and building replacement products; however, I have no interest in re-inventing the wheel. I want to work on projects that leverage the existing infrastructure to do cool new things.

But there are serious problems in the areas I'm interested in.

Just one example: The kernel is broken when it comes to recording audio and video, so all my ventures along this line have come to dead ends. Sure you can patch the kernel, but the next SSU overwrites your patch and you're back where you started.

Re: The cohesive community: from talking to doing
 

Texrat, when you talk about hardware uncertainty, are you talking about the rapid pace of obsolesce right now? I've been seeing that too, but then again, it's not at all unexpected. Especially since we're nearing the top arc of a tech boom period. It goes in cycles and has since the first steam engine, although the peaks and valleys are getting slightly closer together as time progresses.

This upswing should petter out in the next year or two as people grow tired of the overly rapid change of things, and we'll soon settle into more moderate changes in hardware. Things like point oh releases instead of full versions, to use software versioning for my example. So for example, once the speed of improvement slows again as it did around 2000, devices like the n810 would no longer become superseded within 9 months to 2 years by a new product. Instead you'd have things where the n810 would become the N810a with a few minor improvements, but still sold as the n810, and it would remain an active product for the better part of 3-5 years rather than 9-24 months.

I think that when the rate of hardware change slows again here soon, and people have time to catch their breath, volunteer work will pick up again, because, like myself and thousands of others, we don't like to spend countless hours on something, only to find out it's going to be obsolesced tomorrow. So a lot of people are skittish about hardware right now because it's obsolescing so fast. Of course, in the MID and IT markets, you almost have to right now until the MIDs/ITs get to a settling point, likely somewhere in the area the rumored n900 will rest.

With Maemo 5, and the n900, things should settle down for a while with the Nokia NITs and after it does, you should see things pick up again on the community side.

Re: The cohesive community: from talking to doing
 

There's a much more important (IMHO) one: scratching an itch. People contributing to Free software on their own time generally do so because they can enjoy the fruits of their labour immediately on their own computers.

Exactly. Maemo is a bit different to, say, Debian or Fedora in that you can't hack on and use the development version until the hardware that supports it is available. I would expect participation to increase dramatically once people can buy RX-51s.

Re: The cohesive community: from talking to doing
 

There are indeed many things that will be obsoleted by the new hardware. But there are more things that won't. And I would also guess that many of the fundamental concepts in code development will transition.

If you hildonize an existing application, I would bet that would run with a recompile on the new hardware/software platform. And what you learn doing it will make it that much easier next time around.

I was initially hesitant to continue before learning more about the next iteration. But it all came back to what about my existing tablet makes my life more convenient. If there's something I can improve, I do it (or try to). Heck I recently dusted off the OS2006 compiler because I wanted a paint program for the 770.

I've got some things that I'm looking forward to on the next hardware/software platform that my current application can take advantage of. But I don't plan on waiting on anyone. Things get delayed or changed.

Frank

Re: The cohesive community: from talking to doing
 

well, i haven't been idle.
i have been beavering away splitting liqbase up into two distinct halves.

One half is the new libliqbase (yes, its a mouthful)
The other part is the apps themselves.

I am hesitant to release updates to these for the very short term due to the api being incomplete.
as soon as I import existing liqbase functionality into the new framework I will be releasing a completely standalone set of core applications. I will need help to make them and I might make some mistakes along the way, but we might just get something really nice out of them.

They will be small, simple, incomplete examples of doing interesting fullscreen applications which with guidance and teamwork we could shape into a decent set of dream apps for this platform :)

Its possible to install enough of the dev kit directly on the tablets and compilation time is quick for most programs.
You can edit your files and store the source directly on the tablets if you desire.

Re: The cohesive community: from talking to doing
 

Pretty much the point I was trying to make in the previous thread, too.

Nokia is finally getting the closed-source parts opened, but there's been a lot of frustration building up behind wanting (or even being able) to patch/fix things that simply wouldn't survive an official update that will hopefully diffuse once we get Mer.

"Building up" being the keyword here; It's not that running into off-limits parts alone is the problem, it's the length of time doing so.

Re: The cohesive community: from talking to doing
 

We used to have a lot of interest in the it line because of the constant upgrades it recieved in hardware and software. but after the n800 there has been no actual hardware revision and with the ssu no great software upgrade. This gap has brought the community to think negatively. if nokia would just have released the new hardware with updated diablo by this cwe wouldn't have had this discussion

Re: The cohesive community: from talking to doing
 

Isn't it a positive thing that the hardware platform has been stable this long to allow a vibrant software platform to develop?

Frank

Re: The cohesive community: from talking to doing
 

Granted, but the discussion revolves heavily around a community context, and that example can actually serve to work against the concept.

Re: The cohesive community: from talking to doing
 

Yes and no.

It would be without question IF the tablet products were not being killed off so quickly without direct replacements. It's getting rather difficult for customers, for example, to buy new N800s.

So while the hardware may be stable, the releases are not.

Re: The cohesive community: from talking to doing
 

I understand all that, but that's only part of it. I was definitely using "uncertainty" very broadly for economy of verbiage (imagine that :D). It also includes the irregularity of releases from Nokia, the delays from planned release dates and the lack of continuity. By the latter I mean (as I've said often lately) that I strongly believe there should have been a direct N800 follow-up, for example. There wasn't and doesn't look like there will be. I find that exasperating and I see that other users as well as developers share that with me.

There is a void in the market where an N800-like tablet would sell and I suspect it's hurting the tablet platform's prospects. Then again, as I've also said, that may be largely moot given the economy...

Re: The cohesive community: from talking to doing
 

It is true but only partially so. Depending on the effort required to scratch an itch and the frequency of the event, you either try to fix it or you move to a platform that does not itch that often (and this can be highly personal for we all itch at different spots). So, yes, an itch can motivate you, but only this far.