I’ll focus on the technical stuff; I think I would only Peter Principle myself if I would try giving management advice.
What I’ve seen too much are community projects, companies or groups who think that the synchronization of Harmattan with Moblin or MeeGo was done well to make what is now the OS on the N9. Luckily is Jolla hiring Harmattan staff, so they understand the situation.
For me it was always clear that “MeeGo” was a more or less failed PR thing between Intel and Nokia. By the time the N9 was first released wasn’t Harmattan synchronized with Moblin or MeeGo technically very much. And after several updates of Harmattan it still isn’t.
The situation on the N9 now is an OS that has relatively few technical resemblance with “MeeGo”. For me is N9’s software Harmattan or Maemo 6. It’s the continuation of the software on the N900: Maemo 5 or Fremantle (after ~ two or three rather big rewrites, that much is true). That the rewrites happened doesn’t mean that during those rewrites Harmattan suddenly became MeeGo. MeeGo is, in other words, a different platform.
A successful project will have to work with what Harmattan is, and not try to replace it with what MeeGo is today. If they do want to end up with “MeeGo” on an N9 they will have to progressively improve Harmattan towards that goal by for example asking Nokia to open closed components, by developing fixes for softwares that are already open source (a lot are), by repackaging them and by explaining N9 owners how to add a repository and how to upgrade their phone safely.
I understand the idea isn’t to deploy on an N9, but if you want a new phone or device that resembles what the N9 is; the N9’s software is in my opinion not MeeGo but Harmattan. Rewrites have happened too often already. It’s my opinion that yet another rewrite of Harmattan isn’t a good idea at all.
For example replacing the Debian package management system with RPM doesn’t sound like a viable option to me at all. Nor is replacing any of the major middleware really doable within the timeframe you’d have to deliver to be relevant.
Instead software project per software project improve the phone’s OS. Kinda like how Ximian did Red Carpet many years ago (which also supported multiple package management systems).
No more big rewrites, no more starting from scratch. No more politics about how it should have been done. Start with the platform as it is. There are reasons why the OS is good, and among the reasons is that good middleware choices and compromises were made.
Kind regards, good luck.
“A successful project will have to work with what Harmattan is, and not try to replace it with what MeeGo is today.”
No, a successful project needs to work with the community and the community is with Mer: http://merproject.org/
If you had read the press release, you’d know that instead of trying to lift the whole distribution itself, Jolla will work as part of the Mer community.
“For example replacing the Debian package management system with RPM doesn’t sound like a viable option to me at all.”
Anybody in his right mind understands that zypper (the package manager used by MeeGo, openSUSE, and a few others) is in all areas ahead of apt. The fact alone that zypper supports more modern and effective compression standards for packages is reason enough to use that in a mobile environment with OTA package installation.
“Nor is replacing any of the major middleware really doable within the timeframe you’d have to deliver to be relevant.”
Which middleware would be needed to be replaced? Considering that you claim to “focus on the technical stuff”, I’d expect more details there.
A better compression standard for packages delivers no netto value for a phone other than maybe, maybe that packages and app upgrades are a little bit smaller to download. So if package management is your focus, your focus is wrong. Technically better doesn’t necessarily mean more successful. And a successor of the N9 should be successful. The N9 already is technically very good, and that didn’t cut it.
None of the middleware on the N9 should be replaced, and especially not for a first product or major upgrade for or based on the N9’s software. Unless you want to develop something that has no relationship with the N9 (then then don’t claim there to be any relationship).
It comes down to this: Any new platform that doesn’t integrate with Harmattan’s current package management system can’t be utilized by N9 owners. This means that it quite simply won’t be utilized within the timeframe to be relevant (between now and a few months, at most). Because you will not have a large enough set of users who’ll utilize your platform. You need them to buy the apps in the app store that you’re supposed to grow in size by attracting app developers.
Keep in mind that the vast majority of N9 users will not replace the OS of their expensive phone.
I’m all for communities and projects who want to develop experimental platforms for mobile phones. But if there’s one thing the Nokia years have taught me it is that without hardware, without sales and PR; your platform won’t be a success. No matter how technically advanced it is (and compared to almost all other software platforms for mobiles, including Harmattan, Android and iOS, isn’t Mer really technically much more advanced at this moment).
“None of the middleware on the N9 should be replaced”
Can you please finally answer which middleware you are referring to?
GStreamer, SQLite, Qt, Tracker, Telepathy, quillimage, QSparql, QtContacts, Qt Mobility, Aegis, the package management, the E-mail client and messaging services, etc.
And if you do want to replace any of those, and many more of the N9’s stock software, prepare to having to patch massive amounts of code in almost every other application of the N9. Including the closed source ones. Let’s say that the thumbnailer is replaceable, although I don’t know why you would do that. And if you do, your replacement should still implement the same D-Bus API that it provides (else you have again a big and important amount of code to rewrite in a wide range of applications).
Basically: start from Harmattan and not from a completely new situation (or don’t claim to be related to the N9’s software). Cutting out all the middleware and rewriting all the horizontal apps, providing replacements, equals rewriting the whole platform. And if that is what project Mer wants to do, great fine, do that! But it won’t be practically possible to get that installed somehow on the vast majority of people’s N9s.
Why do you keep talking about the N9 – Jolla repeatedly said they will not support it, nor base their product on it. The Mer project looks (I didn’t look closely) like a mature base start from, so they are not “replacing .deb with .rpm”, they are using Mer which happens to use RPM.
What you are saying makes sense for a community continuation of N9 Harmattan – but if you want to make a dent as a startup, basing your future on a failed product by a doomed Fortune100 company does not sound like a great approach.
Of course, I would *love* if the N9 UX was being supported/continued and I dread the developer (if there are any left) fragmentation between the Harmattan and the Jolla community, but I understand their reasoning.
@Michael Banck: Yes, sure if the Jolla team wants to base on Mer instead of Harmattan then that’s of course their choice. I indeed think that it’s more worthwhile to continue support and development of Harmattan and get updates on existing N9s.
*edit: +1 to sebsauer’s comment below
@Michael Banck
> Why do you keep talking about the N9 – Jolla repeatedly said they will not support it, nor base their product on it.
Correct, they will not support that device cause they a) cannot (legal and technical reasons) and b) that brings in no money. They cannot build up on it either cause of that two reasons. They need to create an own UI for example. But that is not what this is about. The UI and certain other parts are not even on gitorious. But that is not the majority of code, not where most of the people where working on (ergo where most of the time and resources where spend on and what WILL take lots of time to replicate if you do not reuse – to long even with near to unlimited resources as we saw). They can build up on it, reuse applications, middleware, libraries.
Re Mer: Mer is not incompatible. It does neither limit itself to certain APIs nor defines them but is inclusive what was and is a wise decision. Mer is the core and does not define what’s on top.
For rpm vs deb: That is really not important at all. It takes not much time to re-package. But it makes much time to reinvent everything that was done and is available on gitorious. It takes much time (and very likely never will happen) to port all the applications that are out there already.
> but if you want to make a dent as a startup, basing your future on a failed product
Well, binding your limited resources to rewrite anything that huge team did back then while having way lesser money and, more important, time sounds like the more worse choice. Better spend your limited resources on something else and come to market sooner cause later the demand may gone or be fit by somebody else.
> but I understand their reasoning.
You sound like there where any announcements made that they are not going to reuse Harmattan. I did not found any such sources. For me it sounds more like they plan to reuse as much as possible else the timeframe, product end of this year, is impossible to reach. Even not when you have 100x as much human and financial resources. But let’s wait and look till there are more informations out before forming opinions :)
How in the world did you get the idea that not using Harmattan directly means that no GStreamer, SQlite, Qt, etc. will be used and instead replaced by something else?
The official announcement (which you apparently didn’t bother to read) specifically said that Jolla will use Mer and Qt.
GStreamer is a dependency of QtWebKit and therefore will have to be included.
Jolla will use Mer as its base OS which already has lots of “middleware” packaged, including but not limited to Qt, GStreamer, SQlite, oFono, ConnMan, etc.
@Markus S.: I looked at the package list of Mer and noticed that a huge amount of both middleware and important key apps are missing. To the point that I conclude that Mer has almost nothing to do with the software that runs on N9. What I wrote in the blog is an opinion that a continuation of Harmattan is what should be done, and that I would join such a project. Apparently that’s not what Mer is doing. Which in itself is fine. But then Mer and the software of the N9 are for me two different things that have very few relationship with each other (which is what I pointed out in the blog item about MeeGo too).
No idea where you looked but http://gitweb.merproject.org/gitweb explicitly includes GStreamer, Qt, oFono (which is a GPL telephony stack by Nokia and Intel and used on the N9), ConnMan (network management stack by Nokia and Intel and used on the N9). etc.
@Markus S.: I didn’t say Mer isn’t using some of the N9’s middlewares. Some is not the same as all key ones. It doesn’t have all the key ones at this moment. I gave a small list and in that list there are already five key components that I don’t see in Mer’s package list. For a technical person this is also quite obvious and immediate to see himself. So I don’t understand what the point is that you are trying to make.
Even if those middlewares aren´t in Mer they can still use them (and I think they will).
Mer intends to provide a selection of packages as a base where others will build on top (like the Vivaldi tablet). They don´t intend to be Debian so I think they intend the base system to be small (Mer is aimed at embedded systems after all).
Right, and so what I hope is that a group or the company Jolla will indeed add all the missing middlewares and key apps of the N9 to their Mer based distribution. We’d still be left with RPM vs. DEB but I guess that a bit of alien to convert RPM to DEB might make it doable to still support the N9 (or to install the RPM package management system on a N9 as a first step).
What I´m more interested now is if they are going to base their product in Qt4 or Qt5. Qt 5.0 will be released in September and Qt4 is at the end of its active development.