At Pay4Bugs we have always been avid users and supporters of OpenID. In the world of far too many user names and passwords, the promise of OpenID was fantastic. Who wouldn’t want a single set of credentials that would authenticate users everywhere? In fact, we got so infatuated with OpenID that we even built an OpenID service, targeting the Asia Pacific region. There was no business model, no banner, just our desire to play our part as software evangelists.

OpenID proved decent as a user, fun as a provider, but a nightmare as a business to support.

More and more of today’s internet powers, Facebook and Google to name a few, have taken the concept of OpenID and applied their own liberal interpretation. The original pure form of OpenID has practically faded away as a result.

As a business, when you rely on OpenID, you live at the mercy of the OpenID providers. We’re not even talking about up-time and down-time, but having to support their ever changing specifications. In my role at another web-based firm, most of our customer service inquiries involve login problems. With OpenID not only is this issue not alleviated, but instead the business is left feeling helpless to support its own customers.

Goodbye OpenID. Welcome back to the good ol’ system of usernames and passwords. With frameworks, this should be a breeze.

For a great article on the negatives of OpenID, read this: http://blog.wekeroad.com/2010/11/17/open-id-is-a-party-that-happened/

As some of you may know, Pay4Bugs was first conceived to fulfill an internal need. We needed to debug, and wanted a good platform to do so. Since then, we’ve developed Mobile Software Testing (we wrote apps), and integration with Basecamp (we love 37Signals). When there’s a need that can be resolved with some code, we do it.

Of course we can’t always be building just for ourselves. A client of Pay4Bugs recently requested integration with Lighthouse. So what are they? From the Entp website (the fine folks behind Lighthouse), Lighthouse is described as “a hosted ticket/issue tracking application that we built to handle our own product development in the most simple workflow environment we thought possible.” Sounds good to us.

So after a few days of coding, we’ve completed integration with Lighthouse. Now when you approve a bug, Pay4Bugs will automatically send the information over to Lighthouse via the API. Find bugs here, track it there. Synergy.

Know any other software that you want to see us integrate with? Let us know via the comments below.

As we described previously, when you enter your Basecamp API key into your Pay4Bugs profile, every time you approve a bug, it’ll enter a to-do list item automatically in your Basecamp project. However we didn’t think that was enough, since the integration was only one way.

Now when you complete a to-do item in Basecamp, we send the information back to your bug list on Pay4Bugs. This way as soon as a bug is resolved, it’ll appear as “fixed”, making it easier for testers as they approach your project.

Got any productivity APIs that you think we should connect to? Chime in with the comments section below!

Now that we’ve got the codebase up to date, Pay4Bugs customers can look forward to a number of new client requested features and refinements on an accelerated schedule.

Last Friday, we launched a new email digest feature for customers. By default, clients will no longer receive an email for every new bug.  We realize how annoying this was.  Instead, clients will receive daily summary emails on days when new bugs are submitted and weekly email summaries otherwise.  Miss the per bug emails? You can turn them back on by clicking My Info.

The fact that Ruby on Rails was actually a framework extracted from their work on Basecamp makes them that much cooler. Need more convincing? the creator of Ruby on Rails Heinemeier Hansson commissioned his own special edition Italian sports car , but I digress…

Therefore we’re thrilled to announce that Pay4Bugs has now integrated with the Basecamp API, creating the bug squishing tag team that’s designed to deliver results.

Here’s how it works it a nutshell:

1. Developers create new software products that could benefit from real life testing and debugging. A Pay4Bugs project is created with a bounty. In the project settings, connect to Basecamp using the Basecamp API.
   
2. Testers around the world step up to the challenge, and submit bug reports to the developer.
3. The project manager vet the incoming bug reports. Legitimate bugs are approved, and the information is automatically sent into your Basecamp project.
   
4. Track your open bugs via the awesomely simple “To-do” lists in Basecamp, and watch the developers squash bugs with epic efficiency.

Software bugs, meet your worse nightmare.

For more information on Pay4Bugs, visit Pay4Bugs.com. You can learn more about 37signal’s Basecamp at http://www.basecamphq.com

To find your token, login to your Basecamp account, then click on “My Info” on the top right hand corner. Scroll down past the contact information to a box labeled “Authentication tokens.” Click on the “Show your tokens” link and grab your unique API Token, which permits Pay4Bugs to send bug reports directly to your project t0-do list.

The Red Herring editorial team selected the most innovative companies from a pool of hundreds from across Asia. The nominees are evaluated on both quantitative and qualitative criteria, such as financial performance, technology innovation, quality of management, execution of strategy, and integration into their respective industries.
This unique assessment of potential is complemented by a review of the actual track record and standing of a company, which allows Red Herring to see past the “buzz” and make the list an valuable instrument for discovering and advocating the greatest business opportunities in the industry.

“This year was very rewarding,” said Alex Vieux, publisher and Chairman of Red Herring. “The global economic situation has abated and there are many great companies producing really innovative and amazing products. We had a very difficult time narrowing the pool and selecting the finalists. Pay4Bugs shows great promise therefore deserves to be among the Finalists. Now we’re faced with the difficult task of selecting the Top 100 winners of Red Herring Asia. We know that the 2011 crop will grow into some amazing companies that are sure to make an impact.”

Finalists for the 2011 edition of the Red Herring 100 Asia award are selected based upon their technological innovation, management strength, market size, investor record, customer acquisition, and financial health. During the several months leading up to the announcement, hundreds of companies in the telecommunications, security, Web 2.0, software, hardware, biotech, mobile and other industries completed their submissions to qualify for the award.

Today we’re thrilled to launch the Pay4Bugs Rep System, a reputation engine that takes your testing activity on Pay4Bugs, and through an algorithm determines a numeric rep score. Testers are rewarded when their bug reports are approved by clients, and the score is lowered when their bug reports are rejected.

In the first phase, we’re providing the Rep score to iOS Mobile Testing clients, to help them decide to should be admitted to their testing program. Going forward, we’ll make changes so that testers with higher Rep scores will be given more unique testing opportunities, with higher bounties. There are a lot more we plan to do with Pay4Bugs Rep, so stay tuned for more in the coming weeks!

About a year ago, Apple’s management team brought up the growing issue of Android fragmentation during a conference call, drawing the ire of many Android supporters. Many Android developers were quick to point out that Apple also has a fragmented ecosystem consisting of the iPhone (4 versions), iPod Touch (4 versions), and iPads, along with various different versions of iOS. It was believed that Android would fare no worse.

The problem is, handset manufacturers and carriers actually sometimes think they know better than Google. (Whereas nobody knows better than Apple)

If manufacturers and carriers all followed Google’s specifications on Android, then there would not be an issue. The PC market worked this way for decades. However the open nature of Android OS allows handset manufacturers to tinker the device, for better or worse. Usually worse.

For example, a few weeks ago a Pay4Bugs client was presented with a bug report on its VPN service, claiming he could not connect with his Android powered phone. Worried that the service might have issues, the the VPN connection was tested repeatedly via PC, Mac, iOS, and finally Android. Everything worked.

Digger further into the issue, the Motorola Droid forums had the explanation. The support for VPN with passwords was REMOVED from the original Motorola Droid, running Android 2.1. Why Motorola (or perhaps Verizon) thought this was necessary we’ll probably never know, but needless to say the reporter of the bug (and VPN customer) was quite disappointed, and even angry for his handicapped device.

That was but one small example of fragmentation, feel free to share yours in the comments below. With Google’s recent proposed purchase of Motorola, hopefully future handsets will stick with the rules as defined by Google’s Ice Cream Sandwich. All Google have to do now, is make sure Verizon and AT&T doesn’t boss them around, because for the most part, I still believe you know better.

btw, if anyone knows how to get VPN to work on Droid, please also let us know below. I’ve pretty much given up on solving that issue.

When apps first came onto the scene, every company wanted to build apps because it was relatively cheap, brings great PR, and makes a firm seem technologically advanced. However as time moves on, and technology continues to fragment, the decision is no longer just iOS and/or Android, but also the many different versions of the OS software….. plus tablets.

With so much demand for apps, and increasing fragmentation, some companies attempt to save money by choosing a one size fit all solution. There are plenty of development shops, many outsourced overseas, that will build an app for you that is then “ported” to work on all major mobile platforms. One size fits all…… or is it?

Despite the trend in cell phone design. Touch screen, 4G, candy bar form factor. Users have very different behaviors, and expectations about how an app, on a certain phone, should behave. When you build an one size fits all application, it just might not fit any of them.

Case and point. Scottrade recently released their iPhone app, which was also ported to Android and Blackberry. The app looks nearly identical across all 3 platforms, but due to the difference in user expectations, are not faring well at all. iPhone users expected Retina Graphics, Android users were disappointed by the use of screen real estate, and Blackberry users were just disappointed it didn’t work well. While the company can claim that they “have” an app, the reviews are overwhelmingly negative, and many users state they’re leaving because of this.

On the other hand, E*Trade also has apps on all 3 of these platforms, and all 3 look remarkably similar. However, any user can tell that the apps were purpose built for the devices, taking advantage of all of the hardware and OS features. The high rating confirms that users are satisfied with the experience.

Our thoughts as purveyors of mobile technology? For the growing, dominant platforms of iOS and Android, still with building native apps, natively. As for BlackBerry, Windows7, WebOS (whatever HP ends up doing), or Symbian, start by making a wap based website that does what your users expect. If you must build apps, then I suppose one size fit most solutions are somewhat acceptable.

Regardless if you build it in house, or build it via a porting tool. Remember to test extensively. The 1 and 2 star ratings can be vicious.