'Tis an exciting time for Java developers everywhere - a plethora of new JVM-based languages and frameworks are popping up every day. 'Tis also an exciting time to be a developer building with these frameworks or languages. If you are a framework developer or a framework user, you should read on to see how CloudBees is going to make your life better.
Let's tackle the case of the framework developer first. As you know, it is hard to build out new technologies and even harder to build a community around the technology. As a framework developer, you should surely not be betting your horses on a "build it and they will come" paradigm. If you are not making this bet, then read on.
Crossing the chasm*
The first friction point encountered by excited adopters is the post-download instructions step (RTFM anyone?) and I'll bet my horse that if you don't get this right, you can never cross the adoption chasm. Preferably, you would want your technology running somewhere to give developers a tactile feel, so that they are vested enough to further try your technology. Ideally, a running instance should be fired up and developers can just continue working on it from there - this is where ClickStarts come in.
The CloudBees ClickStart feature does exactly that. Developers get a running instance of your application - neatly bow-tieing a repository, a Jenkins build, a database and a deployed instance of the application. I have blogged extensively about multiple ClickStarts last month on the CloudBees blog. For developers focused on growing their communities, this is a fantastic resource. Just take your most popular (or all) sample apps, specify them as a ClickStart (relax, it is just a JSON file) and boom, your application is ready to run in the cloud. CloudBees has a number of ClickStarts in our curated gallery, and you can build ones that exist outside the gallery as well.
Our most recent example is the Liferay ClickStart. Installing Liferay requires developers to set up a database, download a special Liferay bundle, read the installation instructions or download a WAR file, and make changes to a configuration file to seed it with right information. The exercise takes a couple of hours. This is a couple of hours where the developer can be called by his boss and never come back to the app - or worse, yet, decide that it is not worth investing his time on the technology. On the other hand, the Liferay ClickStart starts up a standard Liferay installation in a couple of minutes.
Thus, it should be readily apparent that ClickStarts eliminate arguably the biggest friction point in a technology's adoption cycle - the one that gets adopters running with the application.
With these two in place - you can do interesting Lego block building. For example, we built a plain Java stack that can deploy plain old Java apps. We then used it to build a Play 2 ClickStack. Then, we built a simple Play 2 ClickStart application. Thus, someone who wants to try out the Play 2 framework can easily run the application through the ClickStart and their Play 2 app will be running on the Play 2 native stack on CloudBees. If you have a CloudBees account, check it out yourself.
PS: ClickStarts have just a bit of a head start over ClickStacks - we have a GitHub page that acts as a community hub for ClickStarts and ClickStacks. You can contribute a ClickStart today; meanwhile, if you wish to see your stack as a ClickStack - please feel free to email me (hsingh @ cloudbees.com) to make that happen.
Harpreet has 12 years of experience in the software industry. Prior to CloudBees, he was at Oracle and Sun for 10 years in various roles, including leading the marketing efforts for Java EE 6 and GlassFish 3.1. He was also product manager for Hudson, launching it within Sun's GlassFish Portfolio.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.