Here’s a dilemma for you.
I own a iPhone 3G 8GB. I want the new iPhone 3GS because it has a better camera and it’s faster.
AT&T wants $399 for me to upgrade… !@#$ that.
Solution? Sell the old iPhone on eBay for $305
This effectively makes the upgrade price about $100!
I highly recommend this approach… it was painless!
At this time of year within the Eclipse community, a lot of reflection goes on as we just shipped a major release. Personally, I have been reflecting on a statement from an article:
…the strength of Mozilla, for example, is that it has figured out how to enable 40 percent of its development to be done by outside contributors. The downside is that these contributors are techies, but the upside is that they’re techies who add language packs, accessibility features, and other “niche” areas that Mozilla might otherwise struggle to deliver.
This suggests a start: enable your open-source project to accept meaningful outside contributions that make the project reflective of a wider development community.
But the real goldmine is broadening the definition of “developer” to include lay users of your software. The day that I, as a nontechnical software user, can meaningfully participate in an open-source project is the day that open source will truly have won.
What has Eclipse done to broaden the definition of a developer?
As Bjorn Freemen-Benson wrote, Eclipse enabled people to contribute translations via the Babel project. The Babel project is setup to accept translation contributions in 34 languages for about 40+ Eclipse projects. As a matter of fact, Babel had a recent release where there were some positive statistics on how translations are coming along.
What else? How about improving our documentation process?
I’m fond of what the Mylyn project does with its documentation. The Mylyn User Guide is crowdsourced via the Eclipsepedia wiki. This enables the Mylyn team to leverage their user community to help contribute documentation and have it appear in the official help documentation. As far as I know, the Mylyn project is currently the only Eclipse project doing this.
How about interacting with talented artists within our user community? I griped about this awhile ago. I had an idea about creating a GraphicsZilla where people can submit requests for graphics and having things tracked… just like we do with bugs!
Also, how about us making it easier for users to file bugs? My ideal would be to see some type of feedback agent included in Eclipse to facilitate users filing bugs. I think we have come a long way with Mylyn integration in Ecilpse… there’s some just loose ends that need to be tied up to make the experience even easier for users.
Other than that… that’s all that comes out of my head at the moment.
In my opinion, we have a great community… we just need to figure out how to leverage it more.
What do you think Eclipse can do to broaden the definition of a developer?
As a Eclipse committer, it’s hard for me to put myself in the perspective of a user… but I try 😉
If you’re bored and interested in JSR 294, it looks like Peter Kriens hit the send button last night:
There’s some interesting points brought up by Peter that I need some time to digest.
Anyways, I highly recommend following the discussion as the changes proposed in JSR 294 may have broad implications for you and your Java friends.
I’m doing the Urban Assault race in Austin tomorrow.
The race involves cycling to various checkpoints and completing obstacle courses! It’s very fun because when you’re done, you get to drink a bunch of beer provided by the New Belgium Brewing company (famous for their Fat Tire beer). What’s awesome about this race is that it’s pretty much a real world version of the famous Traveling Salesman Problem covered in most Computer Science programs. The problem can be summed up as given a list of cities and their distances away from each other, find the optimal path to visit each city exactly once.
So what did I end up doing with my Computer Science background? I entered the various Urban Assault checkpoints into a online TSP solver:
Now I have a good idea of what the best route would be given the constraints!
Who says Computer Science doesn’t have its uses in fitness related activities 😉
Follow your folly!
I’m thrilled to finish running in the Rogue Trail Series this year. I finished the last race this morning, called ‘The Bluff’ in about 54 minutes. Its probably the hardest trail race I’ve run so far, the course was very technical and I even managed to slip and get some cactus needles in my right hand. Fun!
On the bright side, I’ve managed to get 3rd place in the male division and won some hardware!
I only hope to improve my trail running skills in the future. For now, some rest is in order… to help with that, next week I’ll be cycling and drinking beer during the Austin Urban Assault race :)!
I read an article where James Gosling comments on OSGi and Jigsaw, here’s what I found:
According to James, OSGi is:
So… I’m sorry, all due respect to James but I’m going to have to call shenanigans on this one.
Why? Well, let’s go through his three points.
First, Gosling claims that OSGi is from a different universe. I’m not sure which universe he’s referring to, but OSGi has been around since 1999 (in fact, the OSGi Alliance was founded in March 1999). OSGi initially targeted things like set top boxes, mobile, automotive and the home automation market. If you look at the OSGi membership, you see the diversity of companies involved. About 5 years ago, OSGi moved into the desktop application space via Eclipse and the Rich Client Platform (RCP). Now you see companies building applications on top of OSGi. Here are some examples:
A couple years ago, OSGi started to move into the server and enterprise space. Now, I can’t find any major application server that doesn’t use OSGi under the covers. From IBM’s Websphere, GlassFish to SpringSource’s dmServer.
So on the contrary James, I believe OSGi is well entrenched in the universe we live in. In fact, OSGi has continued to evolve since its inception, the specification didn’t come out of nowhere.
Second, James claims that OSGi is kind of huge. I’m not sure what he means by this, there are various flavors of OSGi that come in different sizes based on your needs:
I wouldn’t call any of these implementations huge. If OSGi was huge, you wouldn’t see companies like BugLabs power their BUG device to enable modularity for building cool little devices:
Finally, James claims that OSGi doesn’t play well in the smaller space. Well, as we saw with the BUG example above, that’s obviously not true. If you look at the history of OSGi, James’ statement is ludicrous as OSGi’s initial mission focused on the mobile and embedded space. Nokia and Sprint have shipped phones running OSGi technology. There are even companies like Band XI running Equinox OSGi-based applications on embedded devices like the Catalyst EC:
Heck, you can even plug a device into your wall socket that runs OSGi.
I can go on and on… so what’s my point?
If James wants to talk about OSGi, he should learn more about it first, otherwise he perpetuates misconceptions that help no one. I think we all agree that modularity is a good thing for the software industry and we should be working together to push that concept forward.
On a side note, James, if you want to learn more about OSGi and its history, I would gladly set some time aside to chat. I’m sure people like Peter Kriens and BJ Hargrave would do the same. You’re also welcome to attend a free OSGi mini-course that Jeff McAffer and I are giving on Equinox and OSGi in a couple of weeks.
I was in Berlin last week… for the Eclipse Board Meeting. The meeting mainly focused on brainstorming and strategy sessions. Stay tuned to the Eclipse Committer Representative Blog next week for a full update on how the meeting went.
On a side note, Berlin is a beautiful city with a lot of history.
While I was there, I was introduced to Kaiserschmarren.
It was like an episode of Man v. Food… and food won.
Thanks to everyone for showing me around Berlin during my short stay!
Do you love Git?
Do you want to see Git at Eclipse (like other people)? Do you already mirror some of the Eclipse code base with Git?
If so, I think a good first step would be to host a Git mirror for the Eclipse code base, similar to what Apache does. In my opinion, this would at least enable people who already maintain forks of the Eclipse codebase make it easier to contribute back.
If you like this idea or have some experience with git mirroring, feel free to comment on this bug.
Are you in Berlin tomorrow?
Do you want to have some frosty beverages with the Eclipse Board of Directors and chat about Eclipse-related things?
If so, please join us at the Bavarium at 7pm.
Personally, I’m excited to practice my German, “Eine Berliner Weiße mit Schuss, bitte!”
Since I have reviewed the past two Eclipse release trains, I’d figure I’d throw in my thoughts for Galileo.
In the last Eclipse annual release, Ganymede, there were 23 projects on the train. On the Galileo train, we have grown by 10 projects and are at 33 projects. In terms of enhancements, there are so many new things in Galileo that I’ll only talk about my five favorite things from the various projects.
SWT Cocoa
For Mac users, Eclipse 3.5 will be great since now it’s possible to use Cocoa as the windowing library. As a result of the Cocoa port, you can also run Java 6 since Apple has only provided a 64 bit Java 6 VM. Furthermore, you can even use the new SWT.SHEET style bit to make your Eclipse-based applications look more native on the Mac:
In the end, it was amazing to see how quickly the Cocoa port was developed. I was one of the early adopters helped shape the port by quickly filing bugs with any issue I came across. I have to admit the first month was a bit rough as some of the crashes were very unforgiving, but hey, we’re past that now, right Kevin ;)?
Target Definitions
As PDE project co-lead, one of the biggest things we pushed for was for revamping the target management story in Eclipse. For many years, we had a terrible preference page where you just pointed to a location on disk and got your target setup. There’s really no way to manage that in any sensible fashion so the first step was to come up with a way to specify what composes a target platform. We came up with the concept of target definitions and bundle containers. Along with that concept, came a new editor that allows you to compose target definitions and share them with your colleagues:
As a result, we also revamped the target platform preference page to be simpler and just list all the target definitions we can find:
From early feedback, most people have been very pleased with the work that the PDE team did. All I can say is that in Eclipse 3.6, look for more improvements in this area. Our goal is to make bundle development as easy as possible for people!
API Tooling Enhancements
It shouldn’t be a secret, but one of my favorite projects at Eclipse is PDE’s API Tools. The main reason is that once you start building complex applications with OSGi, good version management tools are critical. The main reason for this is that people tend to treat versions as a marketing number and not an indication of contract. The travesty of how we treat version numbers in the software world deserves its own posting, so I’ll save that for later. API Tools helps us crafting the right version number based on the changes in our code. Add a new API method, well that will be a minor version bump for you! Break API? Well that will be a major version bump for you!
In Eclipse 3.5, the API Tools team added support for execution environment validation:
This basically solves the problem of developing for a certain version of Java and using methods from a newer version of Java. Inside the Eclipse platform project, we’ve had many builds broken due to people doing this so we finally invested in creating the tooling to rectify the situation.
Another thing that was added was the ability to compare baselines within the UI:
You are now easily able to compare a bundle in your workspace with one in your baseline to see what’s changed. You can easily take a gander at what methods, fields and classes were added or removed.
In Eclipse 3.6, look for the PDE API Tools team to further improve the tooling and focus on package level versioning.
MAT
The Eclipse Memory Analyzer (MAT) project makes it debut this year as part of the Galileo train. In my opinion, it’s one of the hidden gems at Eclipse. In short, MAT will is the best heap dump analyzer out there. It has the magical ability of finding memory leaks. The best thing I can say is snap a couple heap dumps from your application and run it through MAT… see what shows up. Here are some useful resources to get you started:
Packages
We have two new packages part of the Galileo release which really representing Eclipse’s growing constituency of developers:
There is a PHP Package now for the PHP community. It’s quickly becoming one of the more popular packages people download at Eclipse.org based on the stats. The other new package is Pulsar which was built specifically for the Mobile Java community. Pulsar is essentially a mashup of the Eclipse SDK and the Eclipse MTJ projects with the ability of downloading more tools from different handset manufacturers.
I wonder what next year will hold for new packages?
Thanks for reading and hopefully I’ll see you next year for the Helios release train 🙂