Re: [maemo-developers] Too busy to accept help?
ext koos vriezen wrote: 2006/10/21, Carlos Guerreiro <[EMAIL PROTECTED]>: ext Murray Cumming wrote: > I'm not seeing any significant improvement to this situation, and > Nokia's developers seem no less busy. So I'm still wasting time chasing > incredibly minor patches. > > I still think a dedicated empowered community liason would fix this. > Murray, you have suggested this before and we have taken notice. At some point that would most probably improve things and it might very well happen. However, at this point our difficulties mainly stem from internal development processes that are not well good at enabling community platform development. I don't fully agree with this, Nokia isn't doing so bad IMO. First the $99 campaign was a smart move to start up a community. The maemo.org and garage are great infrastructures for developers. Scratchbox simply rocks IMHO. And @nokia.com is often one of the answering ones on this list. Certainly. All of this is great infrastructure for _application_ developers. That's the original focus of Maemo, to provide a good platform for _application_ development on the 770. My understanding of Murray's frustration is that it is mainly about the difficulty of doing _platform_ development, meaning contributing to Maemo itself, not simply building on top of Maemo. It is hardly surprising that community platform development has been so difficult given that was not originally a goal for Maemo. Sure, the platform is open, the source code is available and we've tried to enable tinkering with it as much as possible since having an open platform helps and encourages application development and hey, contributions to the platform wouldn't hurt. But we (Nokia) didn't prepare ourselves or Maemo for developing Maemo itself openly with the community, In terms of infrastructure, processes and even mindset. That's why Murray and others find it so hard to contribute. Recently we have selected the HAF as the playground for experimenting with community platform development. Why the HAF? Mostly because it contains many of the open-source components originated by Nokia (e.g.: maemo-af-desktop). Those are the ones that would benefit the most from attracting a community of developers. So it's the HAF software and the HAF team that are the primary focus of process and infrastructure adjustments. May I humbly suggest that not only the haf is important, but also the community applications may need some more attention. New releases from Nokia almost looks like calling processEvents() on the community, apps update/improve suddenly faster. Someone that pushes the community other ways may do this also. That's true, point taken. Br, Carlos ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
2006/10/21, Carlos Guerreiro <[EMAIL PROTECTED]>: ext Murray Cumming wrote: > I'm not seeing any significant improvement to this situation, and > Nokia's developers seem no less busy. So I'm still wasting time chasing > incredibly minor patches. > > I still think a dedicated empowered community liason would fix this. > Murray, you have suggested this before and we have taken notice. At some point that would most probably improve things and it might very well happen. However, at this point our difficulties mainly stem from internal development processes that are not well good at enabling community platform development. I don't fully agree with this, Nokia isn't doing so bad IMO. First the $99 campaign was a smart move to start up a community. The maemo.org and garage are great infrastructures for developers. Scratchbox simply rocks IMHO. And @nokia.com is often one of the answering ones on this list. We are working hard to adjust them but this is something that is difficult to do within the constraints of product development and internal infrastructure. It takes time. Please be patient, things are improving at many levels. > As ever, I'm not complaining so much as trying to suggest how to make > things perfect. > Your suggestions and help are as always welcome and motivating. May I humbly suggest that not only the haf is important, but also the community applications may need some more attention. New releases from Nokia almost looks like calling processEvents() on the community, apps update/improve suddenly faster. Someone that pushes the community other ways may do this also. Koos ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
ext Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Murray Cumming schreef: I'm not seeing any significant improvement to this situation, and Nokia's developers seem no less busy. So I'm still wasting time chasing incredibly minor patches. I still think a dedicated empowered community liason would fix this. A liason that actively comminucates, instead of passively. Things like herring are a great initiative, but if it's only mentioned on IRC after some questioning it will never be of great value to non-developers. Hi Koen, Herring will be announced soon during the next few days, once the repository is minimally ready. Please be patient. For those who cannot absolutely wait here's a few words about herring, which you can find on http://sardine.garage.maemo.org/about.html Herring Sardine will always contain the latest component versions. However, in order to make releases it is necessary to feature freeze the software and concentrate on polishing, bug-fixing and otherwise stabilizing the code. Doing this without stopping forward development requires branching off the code. This is done in the revision control system, component by component as it becomes necessary. When components start branching in the revision control system the Sardine distro branches as well: a separate stabilization distro is created. The current stabilization HAF distro is Herring. _Please note that the Herring is still under construction but should be available very soon_ We are preparing the herring repository here: * deb http://repository.maemo.org herring main non-free However, I wouldn't encourage anybody to try it out just yet, it's just not ready. Br, Carlos ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
ext Murray Cumming wrote: I'm not seeing any significant improvement to this situation, and Nokia's developers seem no less busy. So I'm still wasting time chasing incredibly minor patches. I still think a dedicated empowered community liason would fix this. Murray, you have suggested this before and we have taken notice. At some point that would most probably improve things and it might very well happen. However, at this point our difficulties mainly stem from internal development processes that are not well good at enabling community platform development. We are working hard to adjust them but this is something that is difficult to do within the constraints of product development and internal infrastructure. It takes time. Please be patient, things are improving at many levels. As ever, I'm not complaining so much as trying to suggest how to make things perfect. Your suggestions and help are as always welcome and motivating. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Murray Cumming schreef: > I'm not seeing any significant improvement to this situation, and > Nokia's developers seem no less busy. So I'm still wasting time chasing > incredibly minor patches. > > I still think a dedicated empowered community liason would fix this. A liason that actively comminucates, instead of passively. Things like herring are a great initiative, but if it's only mentioned on IRC after some questioning it will never be of great value to non-developers. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFOdi2MkyGM64RGpERAtvMAJ9mRvLjup8BXOC4NQlDEQnowHc0iQCdGbXL nB0DIBEMkpkjtmuKd2C8HXM= =Z1BW -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Too busy to accept help?
I'm not seeing any significant improvement to this situation, and Nokia's developers seem no less busy. So I'm still wasting time chasing incredibly minor patches. I still think a dedicated empowered community liason would fix this. As ever, I'm not complaining so much as trying to suggest how to make things perfect. On Wed, 2006-04-19 at 20:42 +0300, [EMAIL PROTECTED] wrote: > Hi Murray, > > > The Maemo community is alive, but not thriving as much as it > > could. This > > is because the Nokia developers are so busy and are often unable to > > respond to the simplest of requests for changes or information, and > > often unable to even acknowledge that contributions have been > > accepted. > > It's OK to be busy, so this isn't a personal attack on those > > developers. > > It's a suggestion for how to take the weight off them. > > Yes, the Maemo community could be more thriving, and insufficiently > open development is a key limitation. > Developers are busy working on the next release and don't have as much > time as they would wish to interact with the community. > Things will not always be like this, but at the moment that is the focus > we have. There are many ways to disappoint, slow developer community > development is one of them, but there's also the product. > > However, as Tommi pointed out, an equality important factor here is that > our product development processes and infrastructure are not yet fully > adapted to open platform development. Developing consumer electronics > products takes a lot more than platform software development. So those > processes take time to change. They touch a countless number of aspects > that constrain how development can be done, and often for good reasons, > even though from the outside one cannot see why. > To open up development in order to be more able to make good use of > the community's help, we are changing the way we do many things. As > Marius pointed out, a lot is actually happening there. It takes substantial > energy and time to make it happen. Some of this results in things you can see > (e.g.: bugzilla) but even more in things you cannot see, as it's about > fixing internal obstacles and bottlenecks and preparing the ground. > Things are moving, slowly but surely. > > > I think Nokia needs to assign a dedicated community liaison, full time > > or part time, while still demanding that all developers are involved > > with the community as much as possible. This person would maintain the > > web site, and help the community to maintain it by extracting > > information from Nokia. This person would also do simple patch and bug > > triage and apply obvious changes without bothering the developers with > > trivial stuff. > > > > It must be politically acceptable for this person to be under less > > pressure than a regular developer. If the community liaison > > ever has no > > problems to solve then that's good. > > > > If you need a more traditional job title, you could squeeze these > > responsibilities into "Documentation" or "Q & A". > > > > Nokia will get a lot of the advantages of open source if they don't do > > this, and the community will survive if they don't do this, > > but I think > > the extra salary would be a good investment to get even more valuable > > advantages. > > All of these tasks are important. Many of them are being done to the > extent possible by their available time by a number of hard working > people who (too modestly) "hide" under [EMAIL PROTECTED] > They are more constrained by the current process and infrastructure > limitations than anybody else. > But it's the developers that are not involved enough. That's also > slowly improving. > > Having a full-time community liason is one option, and athought provoking > suggestion to be taken seriously. It's not the only option however. > > Definitely we could use more people. > You'll notice we are hiring, we currently have a couple of positions > open in nokia.com/careers, and we'll have more. > http://careers.nokia.com/nokia/hr/recrsyst.nsf/WB2RR/C33176FEA7866248C22571380056A811?OpenDocument&Lang=Global > > http://careers.nokia.com/nokia/hr/recrsyst.nsf/WB2RR/8A7C8A276B3D1F63C22570B3002683DB?OpenDocument&Lang=Global > > Best regards, > Carlos -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Too busy to accept help? I'm not complaining
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of ext Dave Neuer > Sent: 12 May, 2006 00:02 > To: Kothari Devesh (Nokia-M/Tampere) > Cc: maemo-developers@maemo.org > Subject: Re: [maemo-developers] Too busy to accept help? I'm not > complaining > > > On 5/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > can you be more specific ??? > > > > > > I can remove all software for which I cannot access and > re-publish the > > > source code and all of the hardware capabilities (power > management, > > > DSP and whatever other little doodads Nokia packed in > there) are still > > > accessible; I can compile a kernel and a corresponding > initfs and root > > > fs from source. Etc. > > > > Those are the goals but i have to admit we have not yet > reached there. We are > > working on most parts e.g you can compile your own kernel, > create your custom rootfs, > > remove stuff etc with package management. There are still > certain piecies which are > > either not in our direct control (e.g TI/DSP related > stuff), and some which we > > just cant give out (e.g battery related software). > > As far as the DSP stuff goes, if a developer has linux-dsp-tools, > what's the issue? The actual code which implements the DSP tasks > should be distributable under just about any license, no? developers are free to use the linux-dsp-tool and write dsp tasks (there have been some previous discussion on the mailing list about that)if they want to (and distribute it in a license terms they like), for us mostly the licensed codecs run as dsp tasks which we cannot give out. sorry > > > For us it is important to strive a balance at product > creation and at the same > > time persue the openness goal > > I certainly understand that being a software developer by profession > myself. However, to some extent, the two goals are either at odds, or > the second one is actually more important, to whit: In my opinion, they are more complementary goals, like our desire towards openess results in us thinking more about customizable, extendible and generally better architecture which has clear points for openness and product differentiation. It also makes us think about enabling MOST developer use cases to enable cooperation and working with communities as well as engaging commercial ISV developers > > If Nokia has a product which is viable in the marketplace as it > currently stands, it actually doesn't need the community and can do > only what it has to do legally to comply with the licenses of the Free > Software it ships. In which case pursuing openess is just a > distraction and internal development effort focussed on that goal is > probably wasted. This of course puts the community in a position where Maemo and Nokia 770 is based on large majority or open software and has benifit from the open source, and that brings into us a sense to work together with the community as a constructive partner. To us open source and openness strategy is a long term investment and not a one time opportunistic goal. > it has little option but to reverse-engineer the parts that Nokia > won't release and pursue whatever course makes the community's > software usable and effective, even if it means forking. As with all open source projects and initiatives these are individual choices :) The better option is to identify areas which are close, and then come up with extendible architecture, so the nokia solution can coexist with a reference implementation (so its more worth while to work on stable interfaces and reasonable standardization). This provides 2 advantages, first better architecture and second, points of differentiation for vendors (i.e there could be optimized battery and power management features, or better DSP optimized multimedia) > > On the other hand, if Nokia is hoping that it can leverage the > comminity to *create* the software that makes the device a compelling > product for consumers, then it's in a bind; it must please the > developer community *first,* so that we'll be motivated to do the > lifting required to get the product to that point; speaking > personally, my own enthusiasm for the device is directly tied to its > openess, and my interest in contributing is entirely linked to this As i mentioned earlier, every individual needs to make or find his/her happiness and hence reason for contributions. I am sorry to hear you werent, but that only helps us to keep improving :) > (hence my not developing software for the various Windows-based > tablets and handhelds or purchasing said devices). > > To put this in a slightly different perspective, c
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On 5/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > can you be more specific ??? > > I can remove all software for which I cannot access and re-publish the > source code and all of the hardware capabilities (power management, > DSP and whatever other little doodads Nokia packed in there) are still > accessible; I can compile a kernel and a corresponding initfs and root > fs from source. Etc. Those are the goals but i have to admit we have not yet reached there. We are working on most parts e.g you can compile your own kernel, create your custom rootfs, remove stuff etc with package management. There are still certain piecies which are either not in our direct control (e.g TI/DSP related stuff), and some which we just cant give out (e.g battery related software). As far as the DSP stuff goes, if a developer has linux-dsp-tools, what's the issue? The actual code which implements the DSP tasks should be distributable under just about any license, no? For us it is important to strive a balance at product creation and at the same time persue the openness goal I certainly understand that being a software developer by profession myself. However, to some extent, the two goals are either at odds, or the second one is actually more important, to whit: If Nokia has a product which is viable in the marketplace as it currently stands, it actually doesn't need the community and can do only what it has to do legally to comply with the licenses of the Free Software it ships. In which case pursuing openess is just a distraction and internal development effort focussed on that goal is probably wasted. This of course puts the community in a position where it has little option but to reverse-engineer the parts that Nokia won't release and pursue whatever course makes the community's software usable and effective, even if it means forking. On the other hand, if Nokia is hoping that it can leverage the comminity to *create* the software that makes the device a compelling product for consumers, then it's in a bind; it must please the developer community *first,* so that we'll be motivated to do the lifting required to get the product to that point; speaking personally, my own enthusiasm for the device is directly tied to its openess, and my interest in contributing is entirely linked to this (hence my not developing software for the various Windows-based tablets and handhelds or purchasing said devices). To put this in a slightly different perspective, compare it to the situation in desktop and server operating systems: it is widely accepted that it's the open source development process itself which makes Linux a stable server platform, so it's strongly in the self-interest of vendors shipping said hardware to support *the community* well. On the other hand, desktop users are used to crappy software and expect all the latest whizbang USB devices to work with their machine out of the box; it's less clear why vendors selling products in that market should care about fostering open-source communities because their bottom-line depends on getting products to market quickly with (perhaps poorly-functioning) device drivers for a million devices they don't control. I'm not sure which category Nokia finds itself in with the 770 (I'm prepared to admit that I also may be creating a false dichotomy here, but in order to be convinced I'd want to hear evidence); however, in order for me to expend any effort on making the device a compelling one, I need it to be compelling for me, and for me what makes any type of computer or electronics device compelling is that I can run it w/out using proprietary software. I don't mean to lecture here, but that's what I believed I was getting myself into when I bought the 770. Anyway, I of course appreciate you taking the time to respond and to engage in the discussion, I seriously hope that it eventually becomes moot due to the device living up to the openess promise (and sincerely hope it doesn't become moot because it fails in the marketplace before that happens). Dave ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On Wed, 2006-05-10 at 14:45 -0500, ext Larry Battraw wrote: > On 5/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Behalf Of ext Dave Neuer > > > Sent: 04 May, 2006 23:39 > > > To: Kothari Devesh (Nokia-M/Tampere) > > > Cc: maemo-developers@maemo.org > > > Subject: Re: [maemo-developers] Too busy to accept help? I'm not > > > complaining > > > I can remove all software for which I cannot access and re-publish the > > > source code and all of the hardware capabilities (power management, > > > DSP and whatever other little doodads Nokia packed in there) are still > > > accessible; I can compile a kernel and a corresponding initfs and root > > > fs from source. Etc. > > > > Those are the goals but i have to admit we have not yet reached there. We > > are > > working on most parts e.g you can compile your own kernel, create your > > custom rootfs, > > remove stuff etc with package management. There are still certain piecies > > which are > > either not in our direct control (e.g TI/DSP related stuff), and some which > > we > > just cant give out (e.g battery related software). > > I'm curious-- when you say you can't give out the battery-related > software are you referring to the power management system as it stands > OR any of the details about how to talk to the battery control > interface? I can understand either one, as the power management is > difficult/proprietary, and the battery interface might allow someone > to overcharge or destroy the battery. That being said, it would be > nice to have an entry in /proc of the raw battery voltage and any > additional available power info. > > Larry Hi, please note that the the vast majority of 770 power management stuff is opened already, since it lives in kernelspace. -- Cheers, Igor Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On 5/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of ext Dave Neuer > Sent: 04 May, 2006 23:39 > To: Kothari Devesh (Nokia-M/Tampere) > Cc: maemo-developers@maemo.org > Subject: Re: [maemo-developers] Too busy to accept help? I'm not > complaining > I can remove all software for which I cannot access and re-publish the > source code and all of the hardware capabilities (power management, > DSP and whatever other little doodads Nokia packed in there) are still > accessible; I can compile a kernel and a corresponding initfs and root > fs from source. Etc. Those are the goals but i have to admit we have not yet reached there. We are working on most parts e.g you can compile your own kernel, create your custom rootfs, remove stuff etc with package management. There are still certain piecies which are either not in our direct control (e.g TI/DSP related stuff), and some which we just cant give out (e.g battery related software). I'm curious-- when you say you can't give out the battery-related software are you referring to the power management system as it stands OR any of the details about how to talk to the battery control interface? I can understand either one, as the power management is difficult/proprietary, and the battery interface might allow someone to overcharge or destroy the battery. That being said, it would be nice to have an entry in /proc of the raw battery voltage and any additional available power info. Larry ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Too busy to accept help? I'm not complaining
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of ext Dave Neuer > Sent: 04 May, 2006 23:39 > To: Kothari Devesh (Nokia-M/Tampere) > Cc: maemo-developers@maemo.org > Subject: Re: [maemo-developers] Too busy to accept help? I'm not > complaining > > > On 5/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > Well, since you brought up "truely open product" and "expectation > > > management," what are Nokia's expectations about when the > 770 will be > > > a truely open product (i.e., I can run all free software > on the device > > > > > Maemo 2.0 would take it closer, with real package > management. It is even today > > an open product, you can get root and install whatever you > want today :) but > > remember the hardware limitations of the device itself :) > > > > > without losing any functionality)? > > can you be more specific ??? > > I can remove all software for which I cannot access and re-publish the > source code and all of the hardware capabilities (power management, > DSP and whatever other little doodads Nokia packed in there) are still > accessible; I can compile a kernel and a corresponding initfs and root > fs from source. Etc. Those are the goals but i have to admit we have not yet reached there. We are working on most parts e.g you can compile your own kernel, create your custom rootfs, remove stuff etc with package management. There are still certain piecies which are either not in our direct control (e.g TI/DSP related stuff), and some which we just cant give out (e.g battery related software). The important thing i believe is still to work with (work around;) limitations, and strive towards abstraction and generic architecture which would enable to make maemo more extensible, adaptable and customizable for different hardware configuration (though for the moment we pretty much product driven and that takes the priority, BUT i firmly believe that community with its experience can really help on this front), remember Nokia 770 is NOT a kind of reference platform :) for us For us it is important to strive a balance at product creation and at the same time persue the openness goal Rome was not built in a day :) cheers Devesh > > Dave > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On 5/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Well, since you brought up "truely open product" and "expectation > management," what are Nokia's expectations about when the 770 will be > a truely open product (i.e., I can run all free software on the device > Maemo 2.0 would take it closer, with real package management. It is even today an open product, you can get root and install whatever you want today :) but remember the hardware limitations of the device itself :) > without losing any functionality)? can you be more specific ??? I can remove all software for which I cannot access and re-publish the source code and all of the hardware capabilities (power management, DSP and whatever other little doodads Nokia packed in there) are still accessible; I can compile a kernel and a corresponding initfs and root fs from source. Etc. Dave ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Too busy to accept help? I'm not complaining
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of ext Dave Neuer > Sent: 02 May, 2006 21:07 > To: maemo-developers@maemo.org > Subject: Re: [maemo-developers] Too busy to accept help? I'm not > complaining > > > On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > no offense, it always look simpler from the other side. > Developing and > > bringing a product to market (in all my experience) is no > simple task > > combine that with new challenges working with open source, > and OS communities, > > new processes and at the same time building a truely open product. > > I am not saying we havnt and we will not make mistakes > (maybe we will), > > but we are ready to listen and willing to learn. > > > > And as i see right now, I am ready to take small baby steps > and disappoint few > > than going grand. There is a natural order of things, and > lot what you suggested > > would/may happen but lets take patience as a virtue. > > > > > > As your rightly said, its about expectation management :) > > cheers > > Devesh > > Well, since you brought up "truely open product" and "expectation > management," what are Nokia's expectations about when the 770 will be > a truely open product (i.e., I can run all free software on the device Maemo 2.0 would take it closer, with real package management. It is even today an open product, you can get root and install whatever you want today :) but remember the hardware limitations of the device itself :) > without losing any functionality)? can you be more specific ??? Devesh > > This has been the #1 reason why the device has mostly sat unused in my > house rather than constantly traveling with me and sucking up a lot of > my time. I honestly expected based on Nokia's (admittedly limited) > advanced advertising of the product that that would be the case > immediately, rather than at some unspecified point in the future. > > Dave > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: no offense, it always look simpler from the other side. Developing and bringing a product to market (in all my experience) is no simple task combine that with new challenges working with open source, and OS communities, new processes and at the same time building a truely open product. I am not saying we havnt and we will not make mistakes (maybe we will), but we are ready to listen and willing to learn. And as i see right now, I am ready to take small baby steps and disappoint few than going grand. There is a natural order of things, and lot what you suggested would/may happen but lets take patience as a virtue. As your rightly said, its about expectation management :) cheers Devesh Well, since you brought up "truely open product" and "expectation management," what are Nokia's expectations about when the 770 will be a truely open product (i.e., I can run all free software on the device without losing any functionality)? This has been the #1 reason why the device has mostly sat unused in my house rather than constantly traveling with me and sucking up a lot of my time. I honestly expected based on Nokia's (admittedly limited) advanced advertising of the product that that would be the case immediately, rather than at some unspecified point in the future. Dave ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
--- Lorn Potter <[EMAIL PROTECTED]> wrote: > > There is also the problem of free software that is > > GPL-incompatible (MAME etc). They can't link > against > > GPL libraries, nor will anyone buy a commercial > > license for them. Which means you are pretty much > screwed. > > No, this just means that MAME is screwed. In case you missed it, I wrote "MAME etc" in my message. MAME is far from being the only program with this problem, see for example here: http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses Among the software listed as GPL incompatible are OpenSSL, Apache, original BSD stuff, anything Eclipse related etc. Not that I'm saying that most of those would make sense on a portable device, but the point remains that _you can not use those programs and libraries on an all GPL platform_. In principle even compiling and using them on your own machine would be illegal. > MAME has it's own legal problems, so I really doubt > any company would > take the chance on delivering that on a device. And here is the other problem. This is not about "a company delivering a product". It is about an individual developer's right to develop and port free (but GPL incompatible) software and distribute those programs to other people. Under a GPL/commercial dual licensing method you can't do that without paying some company money. A lot of people object to that. There are disadvantages to both approaches. LGPL allows closed source development without giving back to the community and GPL is incompatible with some free software licenses. During this and other similar threads you have vehemently denied any and all problems with GPL/commercial licensing while downplaying LGPL. There is a word for blindly refusing to accept any other point of view than your own as having any merit. Figuring out what that word is is left as an exercise to the reader. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On 4/20/06, Lorn Potter <[EMAIL PROTECTED]> wrote: > Kalle Vahlman wrote: > >> The only "legal" difference of GPL and LGPL is > >> that GPL insures derived sources remain open. > > > > No. Sources will always remain open with LGPL too. It's the combining > > and linking with non-free (in fact, any) licensed work that LGPL > > allows (and GPL doesn't). > > Which means sources are not open (those that are non free that are > allowed to link to LGPL), which was my point. Sources _derived_ from LGPL code will be, which was the fault in your statement. Sources _combined_ with LGPL need not be, naturally. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
Lorn Potter ([EMAIL PROTECTED]) wrote: > Kalle Vahlman wrote: > >>The only "legal" difference of GPL and LGPL is > >>that GPL insures derived sources remain open. > > > >No. Sources will always remain open with LGPL too. It's the combining > >and linking with non-free (in fact, any) licensed work that LGPL > >allows (and GPL doesn't). > > Which means sources are not open (those that are non free that are > allowed to link to LGPL), which was my point. To nitpick: You originally were talking about "derived sources", which is something different than "clean room sources, using some LGPL library". Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
Jussi Pakkanen wrote: --- Lorn Potter <[EMAIL PROTECTED]> wrote: Correction. Qtopia is dual licensed, commercial and GPL. GPL of course has no licensing cost. The only "legal" difference of GPL and LGPL is that GPL insures derived sources remain open. There is also the problem of free software that is GPL-incompatible (MAME etc). They can't link against GPL libraries, nor will anyone buy a commercial license for them. Which means you are pretty much screwed. No, this just means that MAME is screwed. MAME has it's own legal problems, so I really doubt any company would take the chance on delivering that on a device. -- Lorn 'ljp' Potter Trolltech Qtopia Community Manager Opie Core Developer http://qtopia.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
Kalle Vahlman wrote: The only "legal" difference of GPL and LGPL is that GPL insures derived sources remain open. No. Sources will always remain open with LGPL too. It's the combining and linking with non-free (in fact, any) licensed work that LGPL allows (and GPL doesn't). Which means sources are not open (those that are non free that are allowed to link to LGPL), which was my point. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
Kalle Vahlman wrote: On 4/20/06, Lorn Potter <[EMAIL PROTECTED]> wrote: Weinehall David (Nokia-M/Tampere) wrote: [snip] Just using plain Qtopia wouldn't have been an option, just as using plain GTK+ without Hildon wasn't an option; we had to use a UI that looks somewhat like Nokia's earlier products, without forking too wildly. So the work effort would've been the same either way; the difference being that Qtopia would've incurred the added penalties of a licensing cost, C++, and of course the extra legal issues surrounding the fact that Qtopia is GPL, not LGPL. The Nokia legal Correction. Qtopia is dual licensed, commercial and GPL. GPL of course has no licensing cost. I remember seeing (but cannot confirm right now) a statement that some modules were not allowed to be used on GPL when I compiled the opensource version of Qtopia last night. So I guess to really have that edge whith all the readily available thingies that were mentioned one must pay the fee anyway? The only missing 'modules' in pda commercial thats not in gpl version is qtmail. or are you meaning the phone version? Then there is always Opie which has more programs than you need, and is also GPL and in some ways better than Qtopia. Any company is going to have to pay some kind of fee, regardless whether it's a licensing fee, or fee's of developers to update and maintain your code base. -- Lorn 'ljp' Potter Trolltech Qtopia Community Manager Opie Core Developer http://qtopia.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
--- Lorn Potter <[EMAIL PROTECTED]> wrote: > Correction. Qtopia is dual licensed, commercial and > GPL. GPL of course > has no licensing cost. The only "legal" difference > of GPL and LGPL is > that GPL insures derived sources remain open. There is also the problem of free software that is GPL-incompatible (MAME etc). They can't link against GPL libraries, nor will anyone buy a commercial license for them. Which means you are pretty much screwed. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
"ext [EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > And as i see right now, I am ready to take small baby steps [...] First baby-step for you, Devesh: use a real mail program and not one that corrupts your From: header... :-) (From what I have heard, these annoying [EMAIL PROTECTED] addresses are due to some Outlook or Exchange mis-feature that tries to clean outgoing mail addresses.) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On 4/20/06, Lorn Potter <[EMAIL PROTECTED]> wrote: > Weinehall David (Nokia-M/Tampere) wrote: > [snip] > > > Just using plain Qtopia wouldn't have been an option, just as using > > plain GTK+ without Hildon wasn't an option; we had to use a UI that > > looks somewhat like Nokia's earlier products, without forking too > > wildly. So the work effort would've been the same either way; the > > difference being that Qtopia would've incurred the added penalties > > of a licensing cost, C++, and of course the extra legal issues > > surrounding the fact that Qtopia is GPL, not LGPL. The Nokia legal > > Correction. Qtopia is dual licensed, commercial and GPL. GPL of course > has no licensing cost. I remember seeing (but cannot confirm right now) a statement that some modules were not allowed to be used on GPL when I compiled the opensource version of Qtopia last night. So I guess to really have that edge whith all the readily available thingies that were mentioned one must pay the fee anyway? > The only "legal" difference of GPL and LGPL is > that GPL insures derived sources remain open. No. Sources will always remain open with LGPL too. It's the combining and linking with non-free (in fact, any) licensed work that LGPL allows (and GPL doesn't). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On tor, 2006-04-20 at 18:05 +1000, ext Lorn Potter wrote: > Weinehall David (Nokia-M/Tampere) wrote: > [snip] > > > Just using plain Qtopia wouldn't have been an option, just as using > > plain GTK+ without Hildon wasn't an option; we had to use a UI that > > looks somewhat like Nokia's earlier products, without forking too > > wildly. So the work effort would've been the same either way; the > > difference being that Qtopia would've incurred the added penalties > > of a licensing cost, C++, and of course the extra legal issues > > surrounding the fact that Qtopia is GPL, not LGPL. The Nokia legal > > Correction. Qtopia is dual licensed, commercial and GPL. GPL of course > has no licensing cost. The only "legal" difference of GPL and LGPL is > that GPL insures derived sources remain open. Yes, but since we're talking about a library here, we would have to pay the licensing cost, since we have several applications on our device that are closed source and thus cannot use the GPL-version of the library. So there would be a licensing cost. And yes, I already know the difference between the GPL and the LGPL, thank you very much... Regards: David Weinehall ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
Weinehall David (Nokia-M/Tampere) wrote: [snip] Just using plain Qtopia wouldn't have been an option, just as using plain GTK+ without Hildon wasn't an option; we had to use a UI that looks somewhat like Nokia's earlier products, without forking too wildly. So the work effort would've been the same either way; the difference being that Qtopia would've incurred the added penalties of a licensing cost, C++, and of course the extra legal issues surrounding the fact that Qtopia is GPL, not LGPL. The Nokia legal Correction. Qtopia is dual licensed, commercial and GPL. GPL of course has no licensing cost. The only "legal" difference of GPL and LGPL is that GPL insures derived sources remain open. -- Lorn 'ljp' Potter Trolltech Qtopia Community Manager Opie Core Developer http://qtopia.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Too busy to accept help?]
> > > Original Message > Subject: [maemo-developers] Too busy to accept help? > Date: Wed, 19 Apr 2006 13:14:13 +0200 > From: ext Murray Cumming <[EMAIL PROTECTED]> > To: maemo-developers@maemo.org > > The Maemo community is alive, but not thriving as much as it > could. This > is because the Nokia developers are so busy and are often unable to > respond to the simplest of requests for changes or information, and > often unable to even acknowledge that contributions have been > accepted. I agree. but sometimes, I believe also community cannot be pushed too hard either, things just take time (simple example is if something itches, you step in to solve :) > It's OK to be busy, so this isn't a personal attack on those > developers. > It's a suggestion for how to take the weight off them. > > I think Nokia needs to assign a dedicated community liaison, full time > or part time, while still demanding that all developers are involved > with the community as much as possible. This person would maintain the > web site, and help the community to maintain it by extracting > information from Nokia. This person would also do simple patch and bug > triage and apply obvious changes without bothering the developers with > trivial stuff. I rather turn this other way to identify clear problems today and expectations e.g (here is my list), feel free to add 1. Responsive discussion on mailing list (this should decrease, as Maemo matures, and more things get documented) - so patience advised [Thing community can do for us] : Create a Wiki page with concrete How-To's needed. Remember so many things are discussed on mailing dev list, which are asked again and again. Also it is easier to update things at one place, when things change 2. clear forums for feature/enhancements discussion 3. more transparency from Nokia about Maemo roadmap (with ability for community to be involved) 4. responsive bugzilla [this should now start to work :) 5. ability for community to be involved with bleeding edge Maemo, to contribue and experiment baby step [http://maemo.org/pipermail/maemo-developers/2006-April/003550.html] 6. ability for community to contribute and share Maemo applications 7. Clear process from each project (in Murrays case HAF) - how they accept contributions (e.g access rights, patches, feature enhancements) I still see a lot of value in Murrays proposal, and as Carlos pointed out :) there are hiring announcements :). Devesh > > It must be politically acceptable for this person to be under less > pressure than a regular developer. If the community liaison > ever has no > problems to solve then that's good. > > If you need a more traditional job title, you could squeeze these > responsibilities into "Documentation" or "Q & A". > > Nokia will get a lot of the advantages of open source if they don't do > this, and the community will survive if they don't do this, > but I think > the extra salary would be a good investment to get even more valuable > advantages. > > > -- > Murray Cumming > [EMAIL PROTECTED] > www.murrayc.com > www.openismus.com > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Too busy to accept help? I'm not complaining
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of ext > Shawn Gordon > Sent: 19 April, 2006 23:06 > To: maemo-developers@maemo.org > Subject: Re: [maemo-developers] Too busy to accept help? I'm not > complaining > > > At 12:23 PM 4/19/2006, Philippe De Swert wrote: > >Hello Shawn, > > > >On Wed, 2006-04-19 at 11:59 -0700, Shawn Gordon wrote: > > > I've already got Nils slamming me privately because I dared to > > > mention Qtopia, but let me provide some perspective as a > company who > > > was very successful with Qtopia and the Sharp Zaurus and > what Sharp > > > and Trolltech did both right and wrong that Nokia could > learn from (I > > > don't care if they use Qtopia at this stage, I just > honestly think it > > > would have been faster and cheaper than going the route > they did, but > > > I am not privy to the information that went in to making > that decision). > > > >Why would Qtopia be faster and cheaper? > > faster because it is done, has been used, refined, debugged and > developed for for years, so other than device drivers in the kernel > it wouldn't have taken hardly any time at all to get it up > and running. no offense, it always look simpler from the other side. Developing and bringing a product to market (in all my experience) is no simple task combine that with new challenges working with open source, and OS communities, new processes and at the same time building a truely open product. I am not saying we havnt and we will not make mistakes (maybe we will), but we are ready to listen and willing to learn. And as i see right now, I am ready to take small baby steps and disappoint few than going grand. There is a natural order of things, and lot what you suggested would/may happen but lets take patience as a virtue. As your rightly said, its about expectation management :) cheers Devesh > > cheaper - I'm assuming cheaper based on what I know of the licensing > costs and the costs to hire a bunch of developers for years to > develop and support the software. Nokia is not going to just rely on > the open source community for something that they depend on, they > will certainly have their own developers and these are going to be > far more expensive than simply paying a small per unit license cost > (I'm talking ones of dollars per unit). > > >I am not trying to troll here > >but both have wide support in the Free Software community. > (However in > >the embedded space GTK might have an edge. GPE is atm better > supported > >and has more active developers than Opie for example. And I am not > >stating that because I happen to be involved with GPE, but > because both > >Opie and GPe are involved with familiar we know about each other > >projects and we even co-operate on certain parts.) > > Keep in mind that Opie is simply a fork of the GPL version of Qtopia, > so they get the advantage of all the things I spelled out above. > > > > > Now by the time the Zaurus was commercially available, my company > > > already had a dozen products running on it, maybe more, > and there was > > > a big and healthy open source movement that was also producing > > > software, I don't remember how many apps, but it was a good amount > > > and grew very rapidly. > > > >Well Nokia might not have had applictions readily available > before the > >product was released. But I do remember porting an app in > the maemo SDK > >before the device was actually available > > > > > What was done right: > > > > > > 1.Sharp actually located about 50 companies and > individual developers > > > 2.They worked with Handango to create a web site where > commercial and > > > 3.Trolltech hired a liaison to work directly with the embedded > > > community and keep the line of communication open. > > > >Ok. That indeed are valid points that could contribute to > success with > >an "open" project. However *again* I see no reason why > Qtopia would have > >been an advantage. In it's own right I believe the technical > choice GTK > >vs QT(opia) has nothing to do with the success of these > projects. As you > >point out political choices are much more important. Nokia > has supported > >Gnome and has hired professional companies to support them as can be > >seen in Ari Jaaksi's presentation from Boston see (slide 7): > >http://www.kotiposti.net/jaaksi/ME9_LinuxWorld_2006_AriJaaksi_.pdf . > >So the one thing they really need to do
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On ons, 2006-04-19 at 13:06 -0700, ext Shawn Gordon wrote: [snip] > faster because it is done, has been used, refined, debugged and > developed for for years, so other than device drivers in the kernel > it wouldn't have taken hardly any time at all to get it up and running. > > cheaper - I'm assuming cheaper based on what I know of the licensing > costs and the costs to hire a bunch of developers for years to > develop and support the software. Nokia is not going to just rely on > the open source community for something that they depend on, they > will certainly have their own developers and these are going to be > far more expensive than simply paying a small per unit license cost > (I'm talking ones of dollars per unit). Just using plain Qtopia wouldn't have been an option, just as using plain GTK+ without Hildon wasn't an option; we had to use a UI that looks somewhat like Nokia's earlier products, without forking too wildly. So the work effort would've been the same either way; the difference being that Qtopia would've incurred the added penalties of a licensing cost, C++, and of course the extra legal issues surrounding the fact that Qtopia is GPL, not LGPL. The Nokia legal process is not a smoothly operating machine, it's more akin to the Spanish inquisition... [snip] The world is only black and white if you filter out the greys by deliberately ignoring to see some things and are not privy to other things. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
Am Mittwoch, den 19.04.2006, 13:06 -0700 schrieb Shawn Gordon: > Keep in mind that Opie is simply a fork of the GPL version of Qtopia, Hmm... "simply a fork"? That does it no justice... :/ If it wasn't for C, I think there would be some more people that you could've dragged from the Qtopia/Opie c++ developer community to maemo... that's why I keep wishing those hildonmm bindngs would be there sooner than later. -- Regards, Mickey. -- Dipl.-Inf. Michael 'Mickey' Lauer <[EMAIL PROTECTED]> -- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
On Wed, 2006-04-19 at 13:06 -0700, Shawn Gordon wrote: [snip] > cheaper - I'm assuming cheaper based on what I know of the licensing > costs and the costs to hire a bunch of developers for years to > develop and support the software. Possibly Nokia are thinking longer term. After all, they are trying to create a platform, and one that's attractive to other companies, not just one product. In the long term, dependence on a single vendor could be a huge cost. And in the short term, they can get wider involvement more quickly by lowering the initial costs for third-party developers. I'm just guessing. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
At 12:23 PM 4/19/2006, Philippe De Swert wrote: Hello Shawn, On Wed, 2006-04-19 at 11:59 -0700, Shawn Gordon wrote: > I've already got Nils slamming me privately because I dared to > mention Qtopia, but let me provide some perspective as a company who > was very successful with Qtopia and the Sharp Zaurus and what Sharp > and Trolltech did both right and wrong that Nokia could learn from (I > don't care if they use Qtopia at this stage, I just honestly think it > would have been faster and cheaper than going the route they did, but > I am not privy to the information that went in to making that decision). Why would Qtopia be faster and cheaper? faster because it is done, has been used, refined, debugged and developed for for years, so other than device drivers in the kernel it wouldn't have taken hardly any time at all to get it up and running. cheaper - I'm assuming cheaper based on what I know of the licensing costs and the costs to hire a bunch of developers for years to develop and support the software. Nokia is not going to just rely on the open source community for something that they depend on, they will certainly have their own developers and these are going to be far more expensive than simply paying a small per unit license cost (I'm talking ones of dollars per unit). I am not trying to troll here but both have wide support in the Free Software community. (However in the embedded space GTK might have an edge. GPE is atm better supported and has more active developers than Opie for example. And I am not stating that because I happen to be involved with GPE, but because both Opie and GPe are involved with familiar we know about each other projects and we even co-operate on certain parts.) Keep in mind that Opie is simply a fork of the GPL version of Qtopia, so they get the advantage of all the things I spelled out above. > Now by the time the Zaurus was commercially available, my company > already had a dozen products running on it, maybe more, and there was > a big and healthy open source movement that was also producing > software, I don't remember how many apps, but it was a good amount > and grew very rapidly. Well Nokia might not have had applictions readily available before the product was released. But I do remember porting an app in the maemo SDK before the device was actually available > What was done right: > > 1.Sharp actually located about 50 companies and individual developers > 2.They worked with Handango to create a web site where commercial and > 3.Trolltech hired a liaison to work directly with the embedded > community and keep the line of communication open. Ok. That indeed are valid points that could contribute to success with an "open" project. However *again* I see no reason why Qtopia would have been an advantage. In it's own right I believe the technical choice GTK vs QT(opia) has nothing to do with the success of these projects. As you point out political choices are much more important. Nokia has supported Gnome and has hired professional companies to support them as can be seen in Ari Jaaksi's presentation from Boston see (slide 7): http://www.kotiposti.net/jaaksi/ME9_LinuxWorld_2006_AriJaaksi_.pdf . So the one thing they really need to do is having somebody that can put time in co-ordinating the community and pass on all interesting developments to the people in Nokia who take the decisions. This last part has not yet been done. And if they manage to pick up the good things from the community it will become a killer product. So they definitely need to work on point 3. Apart from that the used toolkit point is completely moot. The 770 would probabely be as good/bad as it is now regardless of GTK or QT. I'm not espousing the benefits of one technology over another here, I'm simply making the point of how the business was and was not well handled in my opinion. Regards, Philippe -- | Philippe De Swert | | GPE developer: http://gpe.handhelds.org | Emdebian developer: http://www.emdebian.org | | Please do not send me documents in a closed | format.(*.doc,*.xls,*.ppt) | Use the open alternatives. (*.pdf,*.ps,*.html,*.txt) | http://www.gnu.org/philosophy/no-word-attachments.html Regards, Shawn Gordon President theKompany.com www.thekompany.com www.mindawn.com 949-713-3276 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
Hello Shawn, On Wed, 2006-04-19 at 11:59 -0700, Shawn Gordon wrote: > I've already got Nils slamming me privately because I dared to > mention Qtopia, but let me provide some perspective as a company who > was very successful with Qtopia and the Sharp Zaurus and what Sharp > and Trolltech did both right and wrong that Nokia could learn from (I > don't care if they use Qtopia at this stage, I just honestly think it > would have been faster and cheaper than going the route they did, but > I am not privy to the information that went in to making that decision). Why would Qtopia be faster and cheaper? I am not trying to troll here but both have wide support in the Free Software community. (However in the embedded space GTK might have an edge. GPE is atm better supported and has more active developers than Opie for example. And I am not stating that because I happen to be involved with GPE, but because both Opie and GPe are involved with familiar we know about each other projects and we even co-operate on certain parts.) > Now by the time the Zaurus was commercially available, my company > already had a dozen products running on it, maybe more, and there was > a big and healthy open source movement that was also producing > software, I don't remember how many apps, but it was a good amount > and grew very rapidly. Well Nokia might not have had applictions readily available before the product was released. But I do remember porting an app in the maemo SDK before the device was actually available > What was done right: > > 1.Sharp actually located about 50 companies and individual developers > 2.They worked with Handango to create a web site where commercial and > 3.Trolltech hired a liaison to work directly with the embedded > community and keep the line of communication open. Ok. That indeed are valid points that could contribute to success with an "open" project. However *again* I see no reason why Qtopia would have been an advantage. In it's own right I believe the technical choice GTK vs QT(opia) has nothing to do with the success of these projects. As you point out political choices are much more important. Nokia has supported Gnome and has hired professional companies to support them as can be seen in Ari Jaaksi's presentation from Boston see (slide 7): http://www.kotiposti.net/jaaksi/ME9_LinuxWorld_2006_AriJaaksi_.pdf . So the one thing they really need to do is having somebody that can put time in co-ordinating the community and pass on all interesting developments to the people in Nokia who take the decisions. This last part has not yet been done. And if they manage to pick up the good things from the community it will become a killer product. So they definitely need to work on point 3. Apart from that the used toolkit point is completely moot. The 770 would probabely be as good/bad as it is now regardless of GTK or QT. Regards, Philippe -- | Philippe De Swert | | GPE developer: http://gpe.handhelds.org | Emdebian developer: http://www.emdebian.org | | Please do not send me documents in a closed | format.(*.doc,*.xls,*.ppt) | Use the open alternatives. (*.pdf,*.ps,*.html,*.txt) | http://www.gnu.org/philosophy/no-word-attachments.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
I've already got Nils slamming me privately because I dared to mention Qtopia, but let me provide some perspective as a company who was very successful with Qtopia and the Sharp Zaurus and what Sharp and Trolltech did both right and wrong that Nokia could learn from (I don't care if they use Qtopia at this stage, I just honestly think it would have been faster and cheaper than going the route they did, but I am not privy to the information that went in to making that decision). Now by the time the Zaurus was commercially available, my company already had a dozen products running on it, maybe more, and there was a big and healthy open source movement that was also producing software, I don't remember how many apps, but it was a good amount and grew very rapidly. What was done right: Sharp actually located about 50 companies and individual developers (of which we were part) about 6 months before the release of the device, flew us all to San Jose, gave us a limo ride to the hotel, put us up with food and lodging, gave us a day seminar on the device and gave us devices. They hired some people that were specifically meant to interface with the developers and actually were almost always available in IRC for immediate chat and feedback. They worked with Handango to create a web site where commercial and free applications could be hosted. I don't care for the site much, but at least it was a central repository that Sharp would point to. Trolltech hired a liaison to work directly with the embedded community and keep the line of communication open. What was not done right: Sharp in Japan wouldn't trust Sharp Americas decisions and really pulled the rug out from under them. One example was that while they got the device in places like Best Buy they never sent anyone out to the stores to educate the sales people, so consequently they steered people away from the device. Sharp Americas support team kept getting gutted and the contact people in Japan kept changing till the point that you could no longer get information and it basically killed off any interaction between Sharp and the developers to the point that I was actually told by Sharp that they didn't want third party developers to do anything for the device. Sharp Japan making major changes to the OS and backend engine without telling any of the 3rd party developers and we only found out after the devices were released and then documentation was thin or non-existent. Confusing licensing - the Opie and OZ initiatives were really pushed by one of the people at Sharp US to try and commercialize his own embedded system, the problem was with the licensing because if you strictly followed the license, then a commercial application could not be legally sold for a device running Opie and OZ (I don't want to get mired in this again, I spent a lot of time working on this with lawyers at the time, and this was the end result). It was confusing to the point that Trolltech couldn't even explain it. Those are some bullet points of what we went through. We still sell a good amount of software for the Zaurus and Archos every single day, even with these issues. My point here is not advocacy for one windowing toolkit over another, it is to illustrate what works and doesn't work in this environment. I'd be more than happy to have a really detailed conversation with Nokia on this and share more details of my experience. At 10:51 AM 4/19/2006, Kasper Souren wrote: The product is on the market for less than half a year. There are already tens of usable free software applications ported or created. That's pretty impressive for the first 'open product' of such a big company. I'm not complaining. I'm a pretty satisfied customer _and_ developer myself. Just a little thank you to all the Nokia folks who made this possible... ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers Regards, Shawn Gordon President theKompany.com www.thekompany.com www.mindawn.com 949-713-3276 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Too busy to accept help?
On Wed, 2006-04-19 at 20:42 +0300, [EMAIL PROTECTED] wrote: [snip] > However, as Tommi pointed out, an equality important factor here is that > our product development processes and infrastructure are not yet fully > adapted to open platform development. That would be necessary to have the most ideal open source development process. Based on your achievements so far, I'm confident that you'll get there. But for now, that's not necessary in order to fix the very simple bottleneck problems that we are currently experiencing. It just needs someone on the inside who has a little time, and not even anyone very special. Your regular developers will have enough work to do with the community dealing with bigger issues. They don't need to be annoyed with trivial stuff. You have the luxury of being able to assign a janitor to deal with that instead. [snip] > Definitely we could use more people. > You'll notice we are hiring, we currently have a couple of positions > open in nokia.com/careers, and we'll have more. > http://careers.nokia.com/nokia/hr/recrsyst.nsf/WB2RR/C33176FEA7866248C22571380056A811?OpenDocument&Lang=Global > > http://careers.nokia.com/nokia/hr/recrsyst.nsf/WB2RR/8A7C8A276B3D1F63C22570B3002683DB?OpenDocument&Lang=Global -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help? I'm not complaining
The product is on the market for less than half a year. There are already tens of usable free software applications ported or created. That's pretty impressive for the first 'open product' of such a big company. I'm not complaining. I'm a pretty satisfied customer _and_ developer myself. Just a little thank you to all the Nokia folks who made this possible... ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Too busy to accept help?
Hi Murray, > The Maemo community is alive, but not thriving as much as it > could. This > is because the Nokia developers are so busy and are often unable to > respond to the simplest of requests for changes or information, and > often unable to even acknowledge that contributions have been > accepted. > It's OK to be busy, so this isn't a personal attack on those > developers. > It's a suggestion for how to take the weight off them. Yes, the Maemo community could be more thriving, and insufficiently open development is a key limitation. Developers are busy working on the next release and don't have as much time as they would wish to interact with the community. Things will not always be like this, but at the moment that is the focus we have. There are many ways to disappoint, slow developer community development is one of them, but there's also the product. However, as Tommi pointed out, an equality important factor here is that our product development processes and infrastructure are not yet fully adapted to open platform development. Developing consumer electronics products takes a lot more than platform software development. So those processes take time to change. They touch a countless number of aspects that constrain how development can be done, and often for good reasons, even though from the outside one cannot see why. To open up development in order to be more able to make good use of the community's help, we are changing the way we do many things. As Marius pointed out, a lot is actually happening there. It takes substantial energy and time to make it happen. Some of this results in things you can see (e.g.: bugzilla) but even more in things you cannot see, as it's about fixing internal obstacles and bottlenecks and preparing the ground. Things are moving, slowly but surely. > I think Nokia needs to assign a dedicated community liaison, full time > or part time, while still demanding that all developers are involved > with the community as much as possible. This person would maintain the > web site, and help the community to maintain it by extracting > information from Nokia. This person would also do simple patch and bug > triage and apply obvious changes without bothering the developers with > trivial stuff. > > It must be politically acceptable for this person to be under less > pressure than a regular developer. If the community liaison > ever has no > problems to solve then that's good. > > If you need a more traditional job title, you could squeeze these > responsibilities into "Documentation" or "Q & A". > > Nokia will get a lot of the advantages of open source if they don't do > this, and the community will survive if they don't do this, > but I think > the extra salary would be a good investment to get even more valuable > advantages. All of these tasks are important. Many of them are being done to the extent possible by their available time by a number of hard working people who (too modestly) "hide" under [EMAIL PROTECTED] They are more constrained by the current process and infrastructure limitations than anybody else. But it's the developers that are not involved enough. That's also slowly improving. Having a full-time community liason is one option, and athought provoking suggestion to be taken seriously. It's not the only option however. Definitely we could use more people. You'll notice we are hiring, we currently have a couple of positions open in nokia.com/careers, and we'll have more. http://careers.nokia.com/nokia/hr/recrsyst.nsf/WB2RR/C33176FEA7866248C22571380056A811?OpenDocument&Lang=Global http://careers.nokia.com/nokia/hr/recrsyst.nsf/WB2RR/8A7C8A276B3D1F63C22570B3002683DB?OpenDocument&Lang=Global Best regards, Carlos ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
I don't want to flame it at all, but try reading this article to get them better ... ;) http://software.itmanagersjournal.com/article.pl?sid=06/02/02/2129251&from=rss On 4/19/06, Murray Cumming <[EMAIL PROTECTED]> wrote: > On Wed, 2006-04-19 at 15:14 +0300, Jussi Kukkonen wrote: > [snip] > > Still, doing things in private is going to keep everyone else in the > > dark, and hinder community involvement... I fear one liaison won't help > > that. > > I don't think it's done intentionally. I think they just don't have time > for it. So I'd like there to be someone with the time to do it for them. -- --Antonio Gomes ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
On Wed, 2006-04-19 at 14:25 +0200, ext Murray Cumming wrote: > On Wed, 2006-04-19 at 15:14 +0300, Jussi Kukkonen wrote: > [snip] > > Still, doing things in private is going to keep everyone else in the > > dark, and hinder community involvement... I fear one liaison won't help > > that. > > I don't think it's done intentionally. I think they just don't have time > for it. So I'd like there to be someone with the time to do it for them. Yeah, it's more like we have these familiar internal processes we need to follow at least. And we have those processes and infrastructure and such already defined and managed by *other* people. On the public side there are no such things, so the barrier for entry for us is bit too high. We could probably handle managing the content (even if it meant updating some content in two places), but setting up the infrastructure first is just too much, for me at least. (That's why haf.maemo.org is still as informational as it is...) Joel Spolsky recently wrote an article I found interesting and I guess it remotely matches our situation in certain aspects: http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
disse --> Murray Cumming originais -> The Maemo community is alive, but not thriving as much as it could. Perhaps there is some learning curve involved here. This has much to do with both language and cultural differences I think. A lot of 770 work is done at INdT in Manaus and while this is obviously good for the people/economy etc of Manaus it has difficulties too. Perhaps the biggest one is the idea of instantaneous communications. The Amazon is like *big* so a typical journey to the next town will take probably 2 days by boat.As such a couple of hours either side of this do not make a lot of difference in the great scheme of things. Trying to change this mindset is not easy as the Nokia guys running training sessions here can testify. I am not making excuses for Nokia or taking a cheap shot at the Amazonhenses but just calling it as I see it. []'s Ian -- .''`. : :' : `. `'` `- Orgulhoso ser MetaRecicleiro ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
On Wed, 2006-04-19 at 15:14 +0300, Jussi Kukkonen wrote: [snip] > Still, doing things in private is going to keep everyone else in the > dark, and hinder community involvement... I fear one liaison won't help > that. I don't think it's done intentionally. I think they just don't have time for it. So I'd like there to be someone with the time to do it for them. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
Murray Cumming wrote: > The Maemo community is alive, but not thriving as much as it could. This > is because the Nokia developers are so busy and are often unable to > respond to the simplest of requests for changes or information, and > often unable to even acknowledge that contributions have been accepted. > It's OK to be busy, so this isn't a personal attack on those developers. > It's a suggestion for how to take the weight off them. > > I think Nokia needs to assign a dedicated community liaison, full time > or part time, while still demanding that all developers are involved > with the community as much as possible. ... > Nokia will get a lot of the advantages of open source if they don't do > this, and the community will survive if they don't do this, but I think > the extra salary would be a good investment to get even more valuable > advantages. Good suggestion, I second this. There are probably other solutions too. Something that would go a long way is opening the development a little more: I've been really trying to follow what's happening in maemo development and have found it really difficult... * None of the development discussions/meetings/decisions seem to happen in public * The bugzilla doesn't seem to be actually used for bug tracking * I still don't even know who works on what The only way to follow anything seems to be maemo-commits. It could of course be that I'm just slow -- it's a large project, and I'm not that familiar with the components, after all. However, I have succesfully gotten familiar with other large projects before. This time I feel like I haven't progressed at all. I understand that keeping design docs in the wiki or having development discussions on public mailing lists or in IRC is more work and in some cases impossible. I also understand that some employees might not want to be 'in the public eye' and that some bugs need to be Nokia-only. Still, doing things in private is going to keep everyone else in the dark, and hinder community involvement... I fear one liaison won't help that. Best wishes to the developers -- don't burn yourselves on the release, we'll need you after that too :) -- Jussi Kukkonen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Too busy to accept help?
"ext Murray Cumming" <[EMAIL PROTECTED]> writes: > The Maemo community is alive, but not thriving as much as it could. This > is because the Nokia developers are so busy and are often unable to > respond to the simplest of requests for changes or information, and > often unable to even acknowledge that contributions have been accepted. *Cough* Being one of the non-responsive Nokia developers, I agree totally. Things need to improve a lot on our side. People here agree with that, too, and good things are actually happening to lower the 'activation energy' that is needed to actually take the community input in. We are now starting to deal more seriously with bugs in the maemo.org bugzilla, for example. As far as I am concerned, it really helps to tell me again and again what you want me to do, that helps me get my priorities right. Don't feel bad about it. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Too busy to accept help?
The Maemo community is alive, but not thriving as much as it could. This is because the Nokia developers are so busy and are often unable to respond to the simplest of requests for changes or information, and often unable to even acknowledge that contributions have been accepted. It's OK to be busy, so this isn't a personal attack on those developers. It's a suggestion for how to take the weight off them. I think Nokia needs to assign a dedicated community liaison, full time or part time, while still demanding that all developers are involved with the community as much as possible. This person would maintain the web site, and help the community to maintain it by extracting information from Nokia. This person would also do simple patch and bug triage and apply obvious changes without bothering the developers with trivial stuff. It must be politically acceptable for this person to be under less pressure than a regular developer. If the community liaison ever has no problems to solve then that's good. If you need a more traditional job title, you could squeeze these responsibilities into "Documentation" or "Q & A". Nokia will get a lot of the advantages of open source if they don't do this, and the community will survive if they don't do this, but I think the extra salary would be a good investment to get even more valuable advantages. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
