Archive | Community Showcase RSS for this section

March 2014 Staff Pick Project of the Month, Win32 Disk Imager

The Win32 Disk Imager project is a father (Tobin) / son (Justin) team, plus another developer, Jeff. Tobin is a regular in our IRC channel (Freenode: #sourceforge). This is a pretty cool story. Read on!

SF: Tell us what the Win32 Disk Imager project can do for folks…

Tobin:  Win32DiskImager is a tool to take filesystem images and raw files and write them to memory devices (USB memory sticks, SD/CF cards, etc).  It can also read from the device and save the image as a backup.

SF: What was the problem you were trying to solve with this effort?

Tobin:  This tool was originally developed for the Ubuntu 9.04 (Jaunty) Netbook release, targeting users of Netbooks with Windows preloaded.  At the time, Ubuntu only shipped CD ISO images and Netbooks don’t have a CD drive.  This was created as an easy to use solution for Windows users interested in trying the Ubuntu.  I should note that the program went from concept to working release in a weekend.  Justin can comment more on this.

Justin: Tobin simply called me up on a Thursday after school (Senior year of high school if I remember correctly), and needed a screenshot by the end of the weekend so they could do preliminary documentation. I sent a screenshot only a few minutes later (gotta love developing with Qt) and then had to learn the win32 API *shudder* and by Friday night I had a fully functional prototype.

SF: Has your original vision been achieved?

Tobin:  For the targeted release, it went quite well.  After it was released in April, 2009, Ubuntu changed the format of their ISO images and combined the Desktop and Netbook images, so the tool was no longer needed for this purpose.  At this time, it was all but abandoned.

Justin: My original vision for it was simply a temporary tool for a temporary problem, that had other uses as well. After being asked to allow Ubuntu to take over the project and turn it into an Ubuntu specific tool, I kindly refused since I wanted to keep it a generalized tool with a wide range of uses. I didn’t quite imagine that that decision is what would ultimately allow it to explode in popularity like it has done.

SF: Who can benefit the most from Win32 Disk Imager?

Tobin:  Anyone that is using Windows based systems to do development work on embedded systems or users that want to test the latest Cyanogenmod on their Android devices.  I have also heard from users that use it to just back up their SD cards from their cameras.

SF: What’s the best way to get the most out of using Win32 Disk Imager?

Tobin:  The program is very simple in design.  The first thing to remember is to backup any important data you may have on your memory device before writing to it.  And also, read the readme.txt file.  If you have questions, please ask.  We try to answer all questions that we can.

SF: What is the Win32 Disk Imager release philosophy; do you all use the release early, release often precept?

Tobin:  There are currently two people actively maintaining it (Justin is focusing on another project also hosted on SourceForge).  We also have received a few translations from other users, which is great. Unfortunately, we don’t spend nearly as much time on it as we probably should.  We try to outline what features or bugs we want to resolve in the next release, then work towards that goal.  My biggest issues are the constantly changing API’s in Windows, and having to find out how to integrate them in when something breaks.

SF: If not or if so, why?

Tobin:  Time and resources are the biggest factors here.

SF: What are the key features from your most current release?

Tobin: As of v0.9, we support generating MD5 checksums for image verification (helpful for downloaded images), Drag and Drop images from Windows Explorer, and the ability to define a default directory for images through an environment variable (defaults to the user’s Downloads directory).  This works quite well in Windows XP, but we have seen issues in newer Windows releases due to API changes.

SF: What did the project team do to make sure these were completed in a timely manner?

Tobin:  Timely???  Due to our sporadic release cycle, just getting an updated release out was challenging enough.  :P

Justin: As a side note here the first release was dubbed the “Truck Stop” release since one of the guys debugging it was doing so from a truck stop since we had very little time to get the project ready for the initial release.

SF: What was the first big thing that happened for your project?

Tobin:  It wasn’t until mid-2010 when I had bought a Nook Color from Barnes and Noble that I discovered other interests in this program.  The guy selling the Nooks was trying to also sell a book on using the Nook. I told him I was a Linux developer and could pretty much figure it out on my own.  Then he showed me the chapter on “Rooting your Nook”. Glancing through it, I saw a screenshot of our program along with a url to the Wiki page instructions that I had written.

I immediately ran a Google search and found an entire community of users, mainly in the Android Hacker community, but also developers of embedded Linux systems and other types of devices.  There were also a large amount of open bugs.  Since Justin had moved on to other projects, I took over as lead maintainer, and along with Jeff, we have cleaned up all of the original bugs and added some new features along the way.

The other major event was moving the project to SourceForge (YEA!!!). This has helped out a lot, both in exposure and in the tools now available to us to make this project more noticeable. Since moving (and subsequently being targeted as a SF Project of the Week), our user base has grown a lot.  Last time I was at Barnes and Noble, I found 6 different publications recommending our tool to their target audiences.

SF: What helped make that happen?

Tobin:  For the first part, word of mouth, I guess.  I can definitely say that just being on SourceForge has been a big thing.

Justin: It’s quite interesting that this project had received such worldwide fame despite having zero forms of advertising on our part. I guess that’s what you call going viral.

SF: What was the net result for that event?

Tobin:  I recently received an email from a German magazine editor, saying they were going to write a feature on our project.  I have also seen countless reviews, blogs, and even several video tutorials on Youtube.  Downloads are continuously growing week over week (I check the stats daily while sipping my morning coffee).

SF: What is the next big thing for Win32 Disk Imager?

Tobin:  We have a lot planned for upcoming releases.  First and foremost is to move to either a newer release of mingw or something equivalent, as there are a lot of new API issues in Windows that aren’t addressed in the release we currently build against.  Once we get that resolved, we have a wish list of features we want to integrate, starting with image compression/decompression on the fly.

Justin: A couple things I’ve been experimenting with outside of the project was to possibly have the drop-down-box show not only the drive letter but also the label on the device (for example mine might show up as “F: TuxDrive”). This would help a lot of people I think since my own personal experience of safely removing the drive on XP where it only tells you the letter has been annoying when the computer has 3 or 4 different removable devices plugged in. Also, it would be nice to eventually support batch processing of multiple images since the program is now also being used a lot in major tech companies where they’re flashing dozens of cards all hooked up to one system.

SF: How long do you think that will take?

Tobin:  Hard to say.  We already missed our soft target of 1.0 for the end of 2013.  But we do have an installer in the tree now.  That was one of my goals for 1.0. Right now I am focusing on an updated tool base that supports the newer APIs for Windows 7/8.

Justin: As for the pieces I’d like to see, it might be difficult as I’m tiding up other projects, most notably my Open RPG Maker, before going off to college this fall. However, I may be able to squeeze enough time in there to get those two small parts easily done.

SF: Do you have the resources you need to make that happen?

Tobin:  We could definitely use more help.  We are always open to contributions. We have already received a few translations from users, along with some code contributions.  I would also like to thank Jeff B (skydvr68) for his contributions in both code and with the questions forum.

SF: If you had it to do over again, what would you do differently for Win32DiskImager?

Tobin:  I’ll let Justin answer the next few.

Justin: I don’t really think there is anything I’d do differently since the initial release, while a bit buggy, was still fully functional.

SF: Is there anything else I should know?

Tobin: If we can get our development environment issues resolved, 2014 will be a great year for new features.  Hopefully.

Justin: Really awesome to have this project recognized as project of the month, especially seeing some of the other projects that usually get nominated. Feels pretty awesome to have played a part in getting this project there.

Convertigo, Mobile Application Development Platform for Enterprises

convertigo-enterprise-mashup-logoThis is a guest blog post from Convertigo. Enterprise mobility projects are spreading like wildfire. When they deliver value, business leaders in every department seem to want more – and that’s when the bottleneck happens. Instead of connecting one data source to one type of mobile device, your IT infrastructure is faced with multiple device platforms, complex security issues, and disparate enterprise applications and data sources – many with no API.

To accommodate the many-device to many-platform mobile application integration scenario and the BYOD (Bring Your Own Device) paradigm that most IT teams operate within, Convertigo brings one of the most advanced Open Source Mobile Application Development Platform to Enterprises willing to embrace mobility in an industrial, secured and managed environment.

Convertigo platform features front-end cross-platform development tools linked with a powerful back-end orchestration middleware able to connect to any Enterprise back-office data and process whether there is an API or not.

Convertigo leverages standard open source technologies such as Eclipse, jQuery Mobile, PhoneGap and many others to build an industrial platform to build, run and manage any B2E, B2B and B2C mobile application connected to back office data.

February 2014 Project of the Month, Clover EFI Bootloader

Here is the interview we conducted with our latest Project of the Month winner, Clover EFI Bootloader (CEFIB). The community has picked a pretty interesting project in this one.

SF: Tell me about the Clover EFI bootloader project please…

CEFIB: Clover is a graphical boot loader that can run on both (U)EFI and legacy firmwares. It can auto-detect (U)EFI and legacy installations of Windows, Mac OS X, multiple flavors of Linux, and tools, such as the EFI shell. There is also the ability for custom entries and tools. Theming is another feature which is currently expanding and producing some very nice animated menus, thanks to some dedicated users. Clover also has the ability to expand OEM firmware capabilities with EFI drivers which makes it quite powerful and universal.

SF: What made you start this?

CEFIB: It started as a more future proof Mac OS X boot loader and evolved into more than that out of necessity and want to remove multiple chain loads, which shortens boot times and reduces the risk of failure.

SF: Has the original vision been achieved?

CEFIB: Yes the project is becoming quite mature and we’re starting to add features that catch the eye instead of perform a vital function, but we still haven’t lost the focus either!

SF: Who can benefit the most from your project?

CEFIB: Anyone who boots multiple operating systems can benefit from Clover, or anyone who might want a themeable and powerful graphical boot loader.

SF: What is the need for this particular bootloader?

CEFIB: One thing that sets Clover aside from other boot loaders is that it can natively run Mac OS X on PC hardware.

SF: What’s the best way to get the most out of using Clover EFI bootloader?

CEFIB: By trying it out!

SF: What has your project team done to help build and nurture your community?

CEFIB: We try to communicate with our user base as much as possible and solve any issues they might have quickly. Whether it’s by adding features, fixing bugs, or just helping them configure or understand what’s happening during parts of the boot process.

SF: Do you all follow the release early release often (RERO) model?

CEFIB: We try to release any time a new feature or bug fix is out, there are also tools out there that help build the source from the repository. As often as possible while still trying to maintain a stable pathway through the releases.

SF: Have you all found that more frequent releases helps build up your community of users?

CEFIB: I’m not sure, sometimes we find new users with issues who are using ancient versions, although I’d like to think it does.

SF: What was the first big thing that happened for your project?

CEFIB: Just getting it started and out there.

SF: What helped make that happen?

CEFIB: Slice (not sure he wants his real name out there) and that other boot loaders development seemed to be dying or already dead.

SF: What was the net result for that event?

CEFIB: Lots and lots and lots of time reading debug output, lol, and eventually a great boot loader!

SF: What is the next big thing for Clover EFI bootloader?

CEFIB: There are a few things that some users would like to see such as secure boot and implementing firmware features that are not present like target disk mode and file vault.

SF: How long do you think that will take?

CEFIB: Hopefully not long, lol.

SF: Do you have the resources you need to make that happen?

CEFIB: Ingenuity, and discussion amongst the community usually gets it done!

SF: If you had it to do over again, what would you do differently for Clover EFI bootloader?

CEFIB: I think everyone working on the project would probably say something different here, but I’m going to say that I wish the GUI was written from scratch instead of using rEFIt as a base.

SF: Why?

CEFIB: It’s just not sufficient for multicore cpus that could be using one core for system actions and another for graphics. This would allow for more seamless graphical operation and animation of entries as they are found, like usb disks.

SF: Any reason you can’t do that now?

CEFIB: It’s definitely possible but I think that may be a large undertaking at this point and may not have the reward to cost ratio that would merit it.

SF: Is there anything else we should know?

CEFIB: We hope that everyone finds our project useful and uses it! You can also visit‘s clover topics, and of course source forge for help, feature requests, or just to talk about Clover. Thanks!

Project of the Month Changes…

Hi folks,

As most of you know, we have been doing a Project of the Month on SourceForge since October of 2002. When we feature a project, it’s a little like the Colbert Bump, projects get some visibility, and often, good things happen for these projects.

Starting this month, we are making a change in the program. We have recently returned to a Project of the Month voting process where you in the community have the power to select a project from a set of nominees we draw based on project growth, releases, and other data. This project is the “Community Choice.”

We are adding an additional project that is selected by our team, we’re calling the “Staff Pick.” Simply put, a member of our team generally comes across a project they have used, one they love, or one that solves an interesting problem. We consider such nominations from our team and pick one to highlight.

Both projects will get featured on the SourceForge front page. As well, we’ll do a blog post about them both, and continue to track them in our running PoTM historical list. As usual, we’ll also mention these in our monthly newsletter.

Many thanks to you all for your contribute to OSS; the Project of the Month has become what is is because of your contributions to making software that is important to you and that others love.

Using WURFL for Device Detection

WURFLDeviceDetectionbySMThis is a guest post from WURFL. There are literally thousands of device types in use today. In the Android OS alone, there are over 4,000 permutations of device, screen size, and other significant capabilities. This device diversity provides great choice for consumers. However, this diversity also poses problems for companies and their developers when planning, designing, and analyzing their mobile internet offerings.

One way you can address this device diversity by deploying WURFL. WURFL is a tool that lets you detect a mobile device accessing your service and take decisions based on what that device can or cannot do. There are a few important use cases for device detection.

Web Optimization

Whether your approach to mobile is having a separate mobile experience (e.g., or you have adopted a Responsive Web Design (RWD) strategy, device detection can help improve the mobile experience. Detecting and redirecting mobile users to a mobile experience is the most obvious use case for sites, but image resizing and employing advanced graphics on smartphones are also compelling cases. Responsive Web Design provides a good first step for the mobile web. However, for companies that want to take the next step to reduce payload, increase control, and improve the overall experience, device detection is the solution. With a few lines of code, developers can serve right-sized content, multi-serve tricky navigational elements, and guarantee that web pages behave well on all devices.


Consumers have been transitioning away from traditional laptops and towards mobile devices as their primary way of accessing the Web. Advertisers have followed this transition and are investing to make sure their mobile advertising reaches viewers.

To effectively deliver rich media advertisements to mobile devices, Ad Servers use device detection to 1) assess the size and capabilities of a device to view ads, 2) quickly serve ads targeted to specific devices or device families, and 3) provide analytic support to campaigns. For example, smartphones, feature phones, and tablets sport different dimensions of screens. To overcome this challenge, Ad Networks must detect each device’s capabilities and match rich media advertisements suitable to those capabilities. Next, they quickly serve the advertisements so that the publishers’ pages can maintain a good mobile web experience.


Device detection can feed intelligence into the analytical tools that organizations use to segment and target their content and services. Intelligence about a user’s device and its capabilities can yield critical insights as part of a broader analytics platform. For example, Advertisers can target specific device types and measure the success of their targeted campaigns. Or, device data can be combined with
location or demographic data to generate a richer profile of visitors to your website.


For over 10 years, the WURFL project has provided device detection. For many developers, WURFL is the first step in creating a great mobile experience. In addition, for enterprises that need a solution with the limitations of AGPL, ScientiaMobile offers a number of innovative WURFL products.