Bagging a Bug
In an ideal world, there would be no bugs in any of the software we use. LiveCode is no different. We all want stable releases that do what we expect. Nobody likes to encounter a bug.

With some apps that have a relatively small feature set and limited deployment platforms, this goal is sometimes attained. With LiveCode, it's an entirely different matter. The vast feature set and wide range of very diverse platforms it can be run on means that controlling bugs is a substantial task that requires a clear strategy.

For our part, we’ve invested heavily in improving our internal issue tracking, assigning engineers rapidly to new issues. We’ve invested heavily in our new test framework and it is starting to pay off. We used it extensively with the 7.0 release during an unprecedented three months of internal testing, before we even got to a public DP. And it really shows. For a release where we’ve touched every module within the engine source code, the number of issues being reported is no greater than for a more minor point release. We’ll continue to improve test coverage in the coming months.

From the community perspective, we’ve seen you contribute a number of valuable bug fixes and enhancements since we went open source. We’re very grateful to those of you that spend time working in the source base.
Sometimes issues that get reported aren’t simple bugs, instead they are unexpected or unintuitive behavior. LiveCode has been around for a while now and as such has built up a fair share of these. To new users these unexpected behaviors often appear like bugs. Therefore we consider them just as important to correct. Yet if we change them doing so would break backwards compatibility, something that is also critically important to us and to you.

The good news is that as when we get to open language and the new widgets framework we’ll be having a wholesale cull of all these inconsistencies. The old objects and old parser will still be available so backward compatibility won’t be affected. But the new parser and objects will be extremely consistent, having taken into account everything you’ve reported over the years. You’ll be able to use them alongside the older components and move forward step-by-step when you’re ready.

Our Philosophy on Bugs
We have three simple, pragmatic philosophies on how we deal with bugs. In all cases our goal is the same as yours, we want a stable and reliable platform for everyone and we are here to help. The approach that is right for you will depend on who you are and what you need.

The first tier is simple – you help us find it, we’ll fix it. This applies to all open source users and commercial license holders. At this level we see bug fixing as a partnership, where you locate the issue and provide us with a recipe and we then provide the fix. The majority of users at this level are either free and open source users, or holders of the starting-level commercial license, creating a closed source app. We’re very keen to fix your issues once we can reproduce them. However given the volume of reports we can’t spend time searching for an issue we can’t reproduce.

Once we can see the issue and agree it is a bug we will then schedule it for a fix or include it in our future planning. We’ll prioritize the bug in context along with all our other priorities, taking a judgment call as to how many people it affects and how easy it is to fix. Crashes go to the top of the list, followed by regressions.

Given that LiveCode is an open source platform, we welcome patches from the community. If you encounter an issue and are comfortable working in the engine source code, we’re more than delighted to get a patch for an issue. That way you don’t need to wait for us on something that is important to you.
If you’re a commercial developer who is building software to a deadline, this approach won’t always be enough. The next step up is the Pro license. We approach that with the view that we’ll help you find it, then fix it fast. At this level your account manager will work with you on any issues that you find, help you to track them down and your report will go right to the top of the list. You also have the option to have your project included in our internal test set so we can check that it runs well before we send out a test release of a major new version.

Having access to our help can be invaluable, sometimes just half an hour with your account manager can save you an afternoon of effort and get an issue resolved. We have access to the engine and internal workings, so we often see this sort of time saving applying equally to long-time experienced developers as it does to those building their first ever commercial app. This option is perfect for small businesses with medium length development cycles.

At the top of the tree is our Enterprise license where our philosophy is that we’ll help you find the issue on the same day, put it at the top of the list and aim to get it fixed within a few days. We’ll also bend over backwards on your feature requests and anything else you need support-wise. This option is there for anyone building apps that generate significant revenues and where deadlines, features and functionality are all critical.

We’ll work with you on every app and deadline in advance to ensure you get everything you need from the LiveCode platform to make your development process super smooth. This is the best way to gain the most from the features and productivity benefits the LiveCode platform has to offer, when you are undertaking major software development that pushes the feature set and has a short turn around time.

It’s a Partnership
No matter what you’re using the platform for, we hope you’ll report any issue you encounter as soon as you see it. That’s the best way to improve the platform for yourself and everyone else. And if you’re a lower level developer, we’re delighted when you create a patch to an issue yourself.

Sometimes however, issues don’t get reported. That's understandable. But I hope to convince you that reporting a bug early is the best course of action for everyone!

Here are some of the common reasons for not reporting bugs that we hear:

It’s so obvious I assume someone else has reported it
That's never ever a safe assumption to make! What may appear obvious to you may in fact be the result of some specific element of your setup, app code, OS or some other factor. If you encounter an issue then please do report it. Always.

I’m not sure it's a bug, it could be my code
If it crashes LiveCode, it's a bug. It doesn’t matter what your code looks like. If it’s some other unexpected behavior it may or may not be. We invite you to submit your report and we’ll work with you to determine if it is a bug or if there is some future way we can improve the platform to stop the unexpected behavior happening to other users just like you.

I don’t have time to spend tracking it down
It usually doesn’t take that much time to track down a bug. You’re best placed to track it down because it is probably something that comes about as a result of an interaction with your system, OS or app code. If your time is at a premium and you want us to help with this step, check out our pro and enterprise license options.

I mentioned it on the lists/forums/in the community so I don’t need to file it
We only address bugs that are filed in the database. Our entire team is involved in bug fixing and so we need a single centralized place to sort through, prioritize and track issues. Furthermore we now have a number of open source contributors some of whom value having access to the database. So please don’t feel singled out if we ask you to go file a report. It only takes a few minutes. Our development team even asks me to do that these days when I spot a problem and I’m the CEO!

It won’t get fixed
It is true that we have to prioritize the order we fix issues in. However our track record over the past couple of years has been excellent. We try very hard to fix all important issues and prioritize regressions and crashes. Even if it doesn’t get fixed immediately it will go into our planning process for a future version. This usually happens if the issue is caused by a design flaw or limitation rather than by a straightforward error in code. For example, with LiveCode 7 now in testing we recently closed dozens of old bugs that related to various aspects of Unicode handling. It took us a while to do that but we took every bug report we had ever received into account when designing the transparent Unicode support in 7.0. So it was well worth making all of those reports. If you need us to work with you on faster fixes for specific issues that are critical to you, consider a Pro or Enterprise license.

I may hit an issue that is critical in the future
We invite you to get into a habit of working with us and submitting bugs so you know your way around the system and get some practice in submitting a good quality report. If you are building software to a deadline and want to know we’ve got you covered, a Pro or Enterprise license is a small price to pay for the support and piece of mind that comes with knowing you won’t hit the wall at some key moment in your development cycle.

My code is confidential
We know that often your code will be confidential. We have arrangements in place in the bug submission guidelines that allow you to make a report, then email us your confidential code so that it doesn’t go into the public database. If necessary we can even sign a non-disclosure agreement.

I don’t want to send you my code until I’ve cleaned it up
We hear this surprisingly often. We know you’re proud of your work as a coder. We also know that not every line of code in your project is going to be created at the standard of your very best work. Maybe there is some code you wrote learning the platform or in a hurry on a deadline.

The big problem with waiting until you have time to clean it up is that that time never comes. You wrote it in a hurry so why do you think you’ll have more time in the future to go back and clean it up? By putting this rather artificial barrier in place, you turn submitting a bug report into something that takes hours or days for you to do instead of being a quick process. Then worst of all, you’ll be tempted to spend time working around the problem instead of asking us if we can help at an early stage! We’ve often seen a bug report come in after extensive efforts to work around it, where in fact we could have fixed it for you in 30 minutes and included it in the next build. You’ll have wasted time and by the time you’ve reported it you’ll probably be frustrated too.

Your code is what it is. And the truth is, it doesn’t make the slightest difference to us what it looks like. We’re not here to judge your code. In fact, in many cases, we won’t even look at it beyond a quick glance! Instead we’ll be busy running the engine in the debugger to find out why it isn’t working right when your code is running.

Contact us Early
No matter what the issue is, if you involve us as early as possible in the process everyone will win. You’ll usually save yourself a great deal of time, effort and potentially even some frustration. At the same time you’ll be helping us and the other contributors to our open source code platform to create a better platform for everyone. Surely that makes it worth filling out the bug report form? This is a partnership between our community and us and we’re here to help.

Do you have a niggling issue you haven’t got around to reporting? Read our detailed bug reporting guidelines then go and report it today.