Firefox Peak – First impressions

The Firefox OS phones were advertised with “daily updates”, but there hasn’t been a single update since the end of April. That’s why I started my hunt for information.
Searching for Firefox OS roadmap quickly brings you to this page:

https://wiki.mozilla.org/B2G/Schedule_Roadmap

Too bad, this roadmap is from 2012. At least that is what it’s saying. Maybe just a typo? No, it says: “Detailed Milestone tracking was here” for Milestone 3, Target Date 6/1/2012. To my knowledge the verb form “was” indicates the past.

So I started to look for builds. Hooray, Firefox OS nightly builds gain a top ranking in the search results. However, it is only a directory listing of builds. There are instructions on how to install the OS into a simulator and onto an Android phone, but no info about getting it on the Peak device. I am sure spending a few additional hours will get me there, but why do I and likely hundreds or even thousands of developers need to waste this time? Being able to choose between a milestone and a nightly update channel seems a straightforward solution for this issue – and would enable the feedback the Firefox OS developers are looking for.

As I couldn’t believe that there is no roadmap, I went back to looking for one and landed on the Schedule_Roadmap page again. Following the link to the past detailed milestone tracking revealed two surprises: The development of the milestone is under full steam (so it is current) and the tracking is done in a couple of google spreadsheets. While it is great to see that there is a lot of stuff going on, I find the choice of tools inadequate.

From my point of view, running an open source project the way that Firefox OS is run is problematic. I agree that writing code has the highest priority, but if you fail to create an “architecture of participation” you severely limit your chances of success.

The Mozilla Foundation has proven that they can run projects in a way that enables early feedback. Please, Firefox OS team, let a few features slip for the next milestone and allow us to participate more.

I will share my experience with the phone in a couple of blog entries, from first impressions to user experience topics, to trying Eclipse RAP and various mobile frameworks on the peak phone. Obviously I am also interested if Firefox OS should be a target for our Tabris framework. However, that will have to wait, lets get started with the first impressions:

Packaging
The packaging is made of recycled cardboard – good. Geeks care about the environment.

Contents
Phone, earphones (including microphone), USB-cable and USB-charger. For my taste they could have saved both the earphones and the charger, or do you know any developers that don’t have at least a couple of these items anyway?

The Phone: Peak
Case
Makes a good impression at first sight, although it does not look “expensive”. The haptic perception is slick, with a tendency to slippery. I find it annoying that the back of the phone is uneven – the camera lens sticks out on one side of the upper half of the case. This makes it hard to type when you lay down the phone on its back, not  really ideal for a development phone.

Display
The display is ok, but the viewing angle is very narrow and the reflexions can be quite disturbing. Good that geeks love dimmed rooms …

Firefox OS
Unlocking and browsing the main screens is easy, swiping between multiple panes with Apps is the established standard that Firefox OS is sticking to.
Setting up accounts for mail and calendar worked well (Google Apps), only data entry is annoying. The on-screen keyboard is far from the responsiveness I am used to from my iOS / Android devices. Because the keyboard did not accept some of my strokes I had to try and put the cursor at a specific position in the text field, which is really a pain. Especially if the text is longer than the space available it is almost impossible to get to the position at the end of the entry. Not that I am very fond of the iOS magnifying glass or Android Cursor / Range Selection mechanism, but this is close to completely unusable.

When testing the mobile browser I almost gave up on entering a somewhat longer URL. Beside the problems described above, the browser started to load the URL while I was still typing, so I had to go and try to add something at the end of the URL multiple times.
Calendar and Mail that are coming with Firefox OS show that there is potential for a browser-based operating system, but Palm OS has been there as well, with even sleeker apps and did not quite make it.

I am going to use the phone over the next couple of days – I will write about the browser in the next post as it is at the core of the entire system.

How often have you spent hours fixing a layout bug for an otherwise finalized presentation? Indentation is my favorite. Or dealt with moving content into another slide deck with a different design and finally ended up with a complete mess?

For our Tabris Overview slide deck we tried something new, a completely web-based presentation. The slides are built with reveal.js. Reveal allows you to separate content (HTML, MarkDown) from layout (CSS) and offers a couple of nice features:
* You can navigate in 2 dimensions, which allows you to dive into specifics if necessary.
* Fancy animations.
* Some nice JavaScript allows you to zoom in (Alt-click), very handy for diagrams.
* You can get an overview of all slides (ESC).
* They even support speaker notes in another browser window (haven’t tried that).

The really nice thing about this approach is that slides can be put into git, be versioned, branched, forked and everything we like about version control. Plus, the slides can be put online on your web presence (yes, I know that slideshare exists, but then the content is hosted somewhere else).

So what do you think about the Tabris slides and reveal.js in general? How are you building your slides?

With RAP 2.0 we are changing the project name from Rich Ajax Platform to Remote Application Platform (RAP as a short name remains the same), so there is something really significant happening. RAP has always been an implementation of the half-object pattern – synchronising the User Interface between a server and its clients. A specialty of RAP is that the half objects are implemented in different languages. The server part uses Java, the browser client is using JavaScript (and HTML5) for implementing the half objects. Recently we added (commercial) clients for Android and iOS providing native widgets to mobile users. The implementations of the clients are using the corresponding languages – Java and Objective-C. With version 2.0 RAP is no longer only an AJAX framework for creating powerful web applications, it is becoming a platform for remote applications independent of the UI technology that renders the client.

Implementing clients in other languages has become possible with the introduction of the RAP protocol, which standardizes the synchronization of objects between the RAP server and its client based on JSON based messages.

The protocol does not only enable clients in other programming languages, it also opens the door to a new class of applications – applications that need to address a wide range of hardware from desktops to specialized devices (e.g. mobile data entry or point of sales solutions). Or applications that require an integration with attached hardware devices. We think that this is a major new achievement for RAP warranting a major release – and a feature that sets RAP apart from other frameworks.

My colleague Ian Bull created a proof-of-concept implementation of a native SWT client. This is interesting because SWT already implements support for 14 platforms. The creation of the proof-of-concept took only a single day using our Android implementation as a template.

If you want to get your feet wet and implement a client for another platform the only thing you need is the latest milestone build from RAP. If you need help, existing code or a partner for the imiplementation just contact us.

The results are not representative for the entire developer community because the Eclipse community is strongly Java biased, but the size of the sample of 891 is pretty large and statistically significant for developers with a Java background.

So here are the results:

n=891

The majority of developers target more that one mobile platform (71,16%). The most popular combination – and this does not come as a surprise is the combination of Android and iOS (38.05% of all responses) followed by Android, iOS and Windows (15.60% of all responses). A group of 9.76% target all four platforms.

As a result a really large group of developers has to either bridge a skill gap and develop the apps multiple times for the platforms or use a multi-platform toolkit.

The technical skills chart clearly shows the bias towards Java in our sample.

A really interesting observation can be made regarding the Look & Feel of the applications

• 42.20% want a pure native look & feel
• 31.09% want a customized native look & feel
• 23.57% favor an identical look & feel for their apps on all mobile platforms

These results hold a few interesting insights for producers of mobile frameworks. First of all, cross-platform mobile development remains relevant. Secondly there is a large group of developers that would like to use their Java skills for mobile development, with only a limited set of solutions available in the space. Thirdly there is a strong trend towards apps with a native look and feel.

If you would like to contribute your data points simply give the Mobile Select-O-Matic a run and we will give you an update in a couple of weeks.

So here it comes: Mobile Select-O-Matic

You answer a couple of questions (8 to be exact) and we compute a recommendation and a set of helpful resources for your mobile project(s). The evaluation is based on more than 60 facts, considers 18 different frameworks and contains more than a hundred resources.

Inner workings of the original Select-O-Matic

There is also some fun involved – I am sure you will find some easter eggs.

No, this is not another farewell. We have had too many of them over the last few years. Following the recent discussion [1][2][3] about Eclipse Juno one can get the impression that Eclipse is going to be “demolished” anytime soon to make space for a new hyperspace bypass. Reality is, there is no new hyperspace bypass. Not even a plan for one*. Eclipse is the market leading IDE, and receives millions of downloads with a trend going up. The dolphins can stay another decade. But how is it possible that a) the internal community is shrinking b) people are getting criticized for their open source work?

Open Source is not a business model in itself
Historically the Eclipse Platform and the exemplary Java IDE has been built by IBM engineers. There was a clear business model for IBM, because the Eclipse platform serves as the foundation for 300+ tools that IBM is selling to its customers in one or another way. And the Java Developer tools demonstrated the “best practice” in using the platform. This has been working very nicely for the last decade. But something must have changed for IBM because they are putting less energy into Eclipse as a platform. That is nothing that we can or should blame them for, they are a commercial company and need to optimize their profit.

Eclipse describes itself always as an “ecosystem”, so why are there no other companies stepping up to close the gap IBM’s change in strategy is leaving? Because the ecosystem is not making money with the platform and the Java Developer tools. Millions of users are using the – good enough – tools that they can get for free. The ecosystem is making its money with extending Eclipse for various use cases and industries ranging from aviation to utility.

No more satisfaction
Now some of the users of the free tools are less satisfied with Eclipse Juno. We could argue that we don’t care, because there is no claim for perfection attached to the free and open source tools. But that could start a downward spiral for Eclipse many community members seem to be afraid of.

Who is going to pay?
Bottom line is: Some new people will have to pay if we want to put more work into core pieces of Eclipse again. The proposal to put a toll on the companies participating as strategic members is likely not going to work out – as described before they are not making their money with the free tools. But why shouldn’t the users that profit the most from the free tools pay a share for developing and maintaining them. Before you cry foul – “Eclipse is open source and needs to remain free for everyone” – let me explain where I think we should be heading.

There are hundreds of companies out there that have saved big bucks by switching from commercial tools to open source. From my point of view we should involve them in paying for the Eclipse platform and the Java IDE. But we have to offer something that you can’t get for free, otherwise they are not going to pay (there are a few notable exceptions of companies that strategically invested into the health of Eclipse). Paying for maintenance and support is an established Open Source Business Model and we will be giving it a try. With “we” I mean a group formed of the Eclipse Foundation and ecosystem companies that have agreed to start the “Long Term Support (LTS) Working Group“. Because Eclipse provides a really broad set of technologies no single company is able to support the entire breadth of Eclipse. The Eclipse Foundation will orchestrate LTS and provide the infrastructure, and companies of different size and different technology skills will provide the support. As a company you can get the “claim” that is missing from Open Source, and the resulting work will remain open source. Sounds like a “win-win” for everybody, doesn’t it? Expect to hear more about Eclipse LTS very soon.

* One could argue that JavaScript and the trend towards html is removing the necessity of an IDE. But if you look at the Tiobe Programming community index or Redmonks programming language rankings it is obvious that there are still a lot of people in need of an IDE. Unless you are a super geek you shouldn’t develop Java and C without a tool suite IMHO.

Resources:
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=385272 Bug on Eclipse Juno Performance Issue
[2] http://mmilinkov.wordpress.com/2012/09/10/juno-performance/ Mike Milinkovich on Eclipse Juno Performance
[3] http://www.jroller.com/andyl/entry/something_is_really_broken_with Andrey Loskutov on Eclipse Juno
[4] http://www.imdb.com/title/tt0371724/quotes – The Hitchhikers guide to the galaxy – quotes
[5] http://wiki.eclipse.org/LTS/Charter – Eclipse LTS Charter
[6] http://de.slideshare.net/KarstenSchmidt1/econ-2011-eclipse-lts EclipseCon slides on Eclipse LTS
[7] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html – Tiobe Programming Community Index
[8] http://redmonk.com/sogrady/2012/09/12/language-rankings-9-12/ Redmonk Programming Language Rankings

Some people compared Google’s decision to release GWT into the open source community to IBM’s decision regarding Eclipse in 2001. Eclipse transition into Open Source was extremely well managed and a clear vision and a dedicated management team was established at the very beginning. When I became member of the Eclipse Board of Stewards in 2002 I was impressed by the breadth of companies and the resourcefulness of its members. And its vibrant community of committers, even if most of them were employed by a single company – IBM. Comparing this to what’s happening now with GWT it looks more like Google is dumping GWT. Or the transition has been managed very poorly, but that is somewhat hard to believe. There is no visible leadership in the steering committee and everybody seems to be busy with other more important things. While there is nothing wrong with this in general it makes it hard to assess the viability of GWT. At Eclipse the “Open Source Rules of Engagement” have proved to work really well when you are trying to establish an open source community (openness, transparency, meritocracy, permeability and vendor neutrality). Especially when uncertainty is starting to spread it is a good idea to have open communication.

So what does that mean for GWT’s future? From the information that has been made available so far it seems that Google has quite a few applications that rely on GWT so they will have to support it for the next little while. There is no reason to worry if you have GWT based applications in production. IMHO it is a different topic to start new projects based on GWT. Especially the discussion on the introduction of “vendor branches” is a bit disturbing. Google will have its own branch of GWT on which they enforce rigorous testing procedures based on internal applications (that they can’t make available). And they are not sure if they have the resources to validate all changes on trunk. This hints more into the direction of maintenance than active development. But maybe some of the other members of the steering committee will step up and lead GWT into the wild. In the meantime we will have to wait and hope that it is only a lack of communication and not a lack of activity.

Resources:
[1] http://developer.eclipsesource.com/tabris/ – Tabris – multi-platform mobile app framework
[2] https://docs.google.com/presentation/d/1pC… – History and future of GWT
[3] https://docs.google.com/document/d/1oG… – Steering Committee meeting #3 minutes
[4] http://www.eclipse.org/projects/dev_process/development_process_2011.php – Eclipse development process
[5] http://sites.google.com/gwt-steering – GWT steering committee website
[6] https://groups.google.com/forum/?fromgroups#!forum/gwt-steering – GWT steering committee mailing list
[7] https://groups.google.com/forum/?fromgroups#!topic/gwt-steering/O3Yl25n16Xs%5B1-25%5D – Discussion on vendor branches for GWT

Use the word “awesome” as often as you can. You can even do better by using “totally awesome”. Or “insanely awesome” if you know what you are doing – ehm typing.

The widespread use of awesome has been brought to mastership by the JavaScript community. Is this also the true reason that JavaScript has become so popular? (116 million search results and tons of domains including awesome and js).

You are not surprised that jQuery is awesome. And node.js. And NoSQL. And just about everything that is cool today.

But how about Eclipse? There is one Eclipse bug on the topic: 347564

But this is simply not enough. And also there is no such thing as being too awesome. If you are a serious fan of Eclipse you should get going now and buy a few awesome_eclipse domains. At least you should make sure you use awesome in your blog posts.

p.s: Dear Orion team, considering your target audience please make sure you use awesome at least 3 times in every upcoming blog post. That is going to make a difference …

p.p.s: If you don’t want your technology to be successful consider using one of these words:
astonishing, awe-inspiring, beautiful, breathtaking, cool, formidable, frantic, great, impressive, magnificent, majestic, mind-blowing, overwhelming, shocking, striking, stunning, wonderful

p.p.p.s: I hope you are not taking this serious as I enjoy reading planet.eclipse as a mostly awesome-free zone. It is bad enough to have to read that word in every second sentence everywhere in the tech community.

If you are looking for real content about Eclipse being awesome have a look at the top ten Eclipse Juno features.

The announcement is a surprise as Github has always refrained from taking venture money. No surprise is their goal of making Github an essential infrastructure component for all software development. I have heard that sentence a couple of times already. But I haven’t seen it working out for anybody taking venture funding so far.

JBoss was innovative and disruptive and they claim they had commercial success (see how they have done it). When they took venture capital they started defending their trademark in a way that drove away the ecosystem they built before. Luckily RedHat’s acquisition brought things to a happy ending for both the founders and the community.

SpringSource was innovative and disruptive and the technology broadly adopted. When they took venture money they made a couple of very smart acquisitions, but also tried to sell maintenance they previously offered for free. The community didn’t like this at all. Then they became acquired themselves by VMWare and their business model changed completely. It seems the negative vibrations around the technology have gone away with that acquisition.

Github is innovative and disruptive and very broadly adopted. Lets hope that they do not have to change their business model to fulfill the ROI expectations of their investors. I don’t mean to be negative, Github is an excellent company and they have gotten very far already in becoming an essential pillar of software development. And an investment of 100 million into a development tools company is a great signal for the tools industry. The software revolution can only be accomplished with the right set of tools, and the Eclipse ecosystem is a great place for tools that complement Github. So I am looking forward to them to succeed.