Developing MoSync

We love open source software, and for the first time we can also give something substantial back to the open source community. By opening up the Mosync SDK under the GPL license, we aim to give a large group of desktop developers the opportunity to go mobile in a short time frame under Windows desktop environment. We look forward to working together with you in creating new, great applications in mobile, as well as receiving your bug reports, contributions and suggestions on how to make Mosync even better!

Participation from our community is very important in the success of the MoSync Open Source project. 
We invite you to participate on many levels:

These activities require a certain level of technical skill. As a MoSync community member, you as a user can contribute in many other ways; i.e. by participating in the forum or by blogging about MoSync on the Internet.

Share your MoSync demo application

We'd really like to see what people have done with the MoSync SDK, and cordially welcome everyone to share their applications. We've written some ourselves, found under the examples' page, but we are certain there are many, many better one's out there.

Right now, we're collecting applications to put in a showcase right upfront on the website, with due credit to all who's work will be presented. So if you as a developer want to share your portfolio to attract customers to your skill set - this is a great opportunity!

Code contribution

Before you add a code contribution to the MoSync SDK, we need to go through a couple of things:

Send your patches to us for review, to tony(at)mosync.com


Bug reports

How to Report a Bug

Bugs are reported as issues at our Google Code page Issue tracker.

What follows are some additional tips on ways to make your bug report better so that someone will be able to help you.

The basics: what you did, what you wanted to happen, and what actually happened.

There are the three basic elements of a bug report, this may be only to basic but bear with us. You need to tell us exactly what you did:
"I instructed the program to draw a polygon on the canvas",
what you expected to have happen:
"I expected a red polygon to appear on the screen", and lastly what actually happened
"I got a blue circle, flickering on screen".

Always search the bug database first.

The odds are good that if you've found a problem, someone else has found it, too. If you spend a few minutes of your time making sure that you're not filing a duplicate bug, that's a few more minutes someone can spend helping to fix that bug rather than sorting out duplicate bug reports.

If you don't understand an error message, ask for help.

Don't report an error message you don't understand as a bug. There are a lot of places you can ask for help in understanding what is going on before you can claim that an error message you do not understand is a bug.

Be brief, but don't leave any important details out

This is a fine line to walk. But there are some general guidelines:

  • Remember the three basics: what you did, what you expected to happen, and what happened.
  • When you provide code that demonstrates the problem, it should almost never be more than ten lines long. Anything longer probably contains a lot of code that has nothing to do with the problem, which just makes it take longer to figure out the real problem. (But don't forget to make sure that your code still demonstrates the bug you're reporting and doesn't have some other problem because you've accidently trimmed out something you thought wasn't important but was!)
  • If the product is crashing, include a backtrace if possible

Use English

Yes, the MoSync developer community is global and include a great many people who can speak a great many languages. But if you were to report a bug in a language other than English, many (if not most) of the people who would otherwise help you won't be able to.

Don't report bugs about old versions

Every time a new version of a MoSync product is released, many bugs are fixed. If you're using a version of a product that is more than two revisions older than the latest version, you should upgrade to the latest version to make sure the bug you are experiencing still exists. (And it's not a bad idea to try upgrading even if your version is only a version behind the most current one.)

Only report one problem in each bug report

If you have encountered two bugs that don't appear to be related, create a new bug report for each one. This makes it easier for different people to help with the different bugs.

Suggest a feature

While commerical customers and partners can influence the direction and feature set of the MoSync SDK, you can too.

The backlog allows you to vote and comment on features that have already been documented and specified.

If you can't find your suggestion, the best way to submit a feature request is to file a bug report marked as "Feature Request" in the issue tracker at our Google Code page.

Blog about it! Gather support from others for your idea! Find someone who can implement it!

Comment and write stories

Apart from suggesting new features of your own, you can comment and vote on the items in the backlog. We call them stories, since they often are more of a story than a pragmatic description of a feature or piece of functionality.

Write a usability report

Usability reports are feedback from the community about usage of (new) features in the real world. A usability report is a short account of the user's first impact on a newly tried feature, recording his/her expectations and the level of satisfaction achieved.

An usability report should have the following components.

  • Product identification
    • product name
    • version used
    • date of experience
    • any other relevant information to identify what is being tested.
  • Expectations
  • Clarity of documentation
  • Ease of use
  • Real world usage
  • Bugs
  • Missing pieces
  • Level of satisfaction
  • (optional) Test units

These reports are like any other contribution very important to us, and we like to post them on the website (please use Wiki markup for simplicty).

‹ Reference GuidesupThe Issue Tracker ›
»