The Puppet community is great and we’re glad to be a part of it. But there’s a new community to jump into – Jenkins, the leading platform for continuous integration- and a new domain to address – continuous deployment.
Since we released Stack Hammer earlier this year, we’ve been getting the same two questions over and over:
- “The validation testing in Stack Hammer (and Wham!) is really powerful. Can Stack Hammer trigger our other tests the same way?”
- “We’re deploying continuously. How can we integrate Stack Hammer’s configuration testing/validation service into a continuous process?”
We’ve taken the hint, and we’ll be adding more explicit support for continuous deployment. In fact, this will be our major product priority over the rest of this year.
Our first step is a Stack Hammer plug in for Jenkins, which we’ll be previewing at a Jenkins User Conference we’re co-sponsoring this week in NYC. The plugin lets you add Stack Hammer validation and deployment steps directly to a Jenkins project.
A typical usage scenario would be to trigger these steps using a Git hook, so that your stack is revalidated and deployed, for example, each time someone makes a commit to GitHub. Kenn will be demoing this at the conference, using Stack Hammer and Jenkins to continuously deploy and test a Jenkins stack (yes, it’s very *meta*), with the code edited directly at GitHub and the Jenkins stack running at Amazon.
The plug-in needs to call out to Stack Hammer as an external service, so we’ve added support for a RESTful API. We’ve implemented this in a generalized way, so pretty much any external application can now call Stack Hammer as a service. A number of people have asked for this, and we’ll be documenting it so anyone can use it.
A key point is that in continuous deployment scenarios Stack Hammer generally will be filling a specific gap – configuration testing – rather than providing a complete, end-to-end configuration management service. This is a direction we want to take in any case, because we’re finding that many prospective users are relatively far along the Puppet investment curve and want to fit Stack Hammer into an existing workflow. So current and future Stack Hammer functionality will be applied to a more focused value prop – continuous configuration testing – where most organizations still have a hole.
Our next step will be to introduce a more general purpose capability to drive testing based on configuration changes. The necessary framework for test integration is substantially complete, and we’ll be doing some refactoring of the Stack Hammer UI to cleanly separate the validation, test and deployment domains. We plan to preview the complete story at the Dublin Puppet Camp in early July.
May and June will be very busy.
There are three secrets to being an extremely successful and charismatic leader. (1) Build a team that can make you look awesome. (2) Pretend to listen to that team even when you know they’re completely wrong, then overrule them. (3) Have the confidence to admit that although, with the full benefit of hindsight, you may not have been 100% correct on every little detail, you still totally nailed the big picture.
All three of those management principles were on display in the case of Geppetto. When Kenn and Henrik came up with the idea of an Eclipse-based IDE for Puppet early last year, Management politely heard them out before telling them it was one of the dumbest ideas of all time. Who would ever want to use something that? Eclipse is for old men! The kids today are all using command line, not IDEs!
As usual, the team ignored Management and did whatever they damn well pleased, working on Geppetto in secret through 15 long months of nights, weekends and vacations.
But the story turns out to have a happy ending: Geppetto is doing really well. Unique user downloads crossed the 3,000 mark in April, and are accelerating. Many of those users probably download Geppetto and then redistribute it internally, so more could be actually using it. These are pretty decent numbers, given the size of the Puppet user community and the fact that we’ve had very little time to promote it. It may not be for every Puppet user, but those that like it seem to really like it.
And so what if Management said that an Eclipse-based IDE for Puppet was a total waste of time, and Geppetto is an Eclipse-based IDE for Puppet? From the start, Management’s vision has been that, in the future, people were going to need a lot more stuff to make things way better. And isn’t that the the key takeaway regarding Geppetto? Doesn’t it make things *way better*? Let the team sweat the details. That’s their job, not Management’s.
Geppetto 2000
Not all of us here at Cloudsmith are dry and technical. Sure, those of us working down in the trenches may be a bit “serious”. But our most creative elements, such as Kenn and Henrik, the duo behind our new Wham! service, have all the style and flair you would expect of pop stars.
They created Wham! so that you’d have no remaining excuses to not pick up your stack hammer. Just type in the name of a module from the Puppet Forge, or a GitHub repository containing some Puppet code, and click. A graph magically appears, showing you color-coded errors and dependencies!
Wham! uses the same validation and graphing services as Stack Hammer. But while the flagship service is deep, powerful and (some may say) a bit complex, Wham! is shiny, sexy and simple. But still just as useful.
So instead of wondering what’s “lurking in the bushes” (figuratively speaking) of that code you’d like to use, get it all out into the open! You’ll feel better and stack safer!
Use Wham! as a standalone service right now. And wait for us to tie it into the rest of Stack Hammer over the next few months.
Having spent most of the last eighteen months holed up in the studio working on Stack Hammer, it’s time for the band to get out on the road.
We’ll be on tour with our friends from Puppet Labs over the next six weeks, starting in Edinburgh next week, moving to various capitals (Stockholm, Amsterdam, etc.) on the continent and then landing for a final gig in NYC. Then we’re be back on the road for a few more major venues.
If you can’t make the show, we’ll be sure to bang a gong for you…
A quick report on Kenn’s trip to Puppet Camp/Atlanta last Friday. Attendance turned out to be good. His Geppetto talk went well, and some quality time was spent with Kelsey Hightower of Puppet Labs talking about the future of the Forge and module development.
Interestingly, maybe a third of the audience now had some experience with Geppetto, which showed this exponential spike in downloads last month. Kenn must have been telling people down there that Management had originally declared Geppetto a complete waste of time, because Management’s ears were burning throughout the day on Friday.
But taking off our community hat and donning the crass chapeau of commerce, what we found most interesting were the results of the early look Kenn gave at the upcoming Stack Hammer release. Granted, Kenn was only able to show it to the six or seven people he ate lunch with, but it seems they all REALLY LIKED IT and might even want to USE IT! (At least that’s what they said.) So we’re getting a good feeling.
Our next report on this topic is imminent.
Our friends at Puppet Labs are hosting a globe-spanning series of Puppet Camps) this year, and we’ll be going all in.
First up is Atlanta, where we’re hoping to give folks an early look at our new release. Then we’re off to Edinburgh in March, followed a few days later by Stockholm, which we’re co-organizing with Puppet Labs.
New York, Chicago, D.C. and hopefully Amsterdam should follow, adding up to a year-on-year increase in our marketing activities of 250% for Puppet Camp alone.
Like any good start-up, we begin our year with a rousing offsite where we review the past year’s accomplishments and look ahead to the coming year. This year was no exception.
All in all, 2011 was a pretty good year. We pivoted to a new technology/user community (Puppet); built up credibility through a substantial open source contribution (Geppetto); worked through two betas of a new service based on that community (Stack Hammer); and generally just got our act together. We even found time to get this guy to do this. Most things took a little longer than we hoped, but that always seems to be the case for us.
2012 promises to be an even better year. That’s because we’re close to washing our hands of this whole *beta thing* and getting *out there* with a real service, as in, one people would be crazy not to use and hopefully pay us for.
Cleaning up after those contractors always takes a bit longer than expected. Since we’ve already missed our ideal release date of November 11 (Nigel Tufnel Day), we’ve decided to combine the release with all sort of capabilities we’d planned for later this year. The end result should be pretty awesome.
We’ll report back with the details when we have a date.
The team assembled for Management's rousing presentation
We’re back from PuppetConf, done reviewing the feedback we got there and back to work on Stack Hammer.
There were actually no real surprises. We hoped to put in place the foundation for a really useful product solving really important problems. That seems to have gone as planned. Stack Hammer seems able to do pretty much everything users want to do with it.
We also knew that we didn’t exactly know what really important problems people would want to solve with our really useful product. We’re relatively new to this particular user community, so we don’t have enough direct exposure to what bothers its members day-to-day and what they like and don’t like.
So we didn’t even try to include in Beta 2 much to help the user figure out how exactly to get started, because we figured it would be a waste of time. It pretty much violates every current best practice for building applications (or building buildings, where you generally put in doors and windows at the same time as the walls), but it made sense to us at the time.
So that’s what we’re working on now. We’ll be releasing features over the next month that show you how things fit together, how to get started and make it easy to navigate around. What’s underneath won’t change very much, if at all.
Another thing we’ve held off on is aggressively promoting Stack Hammer to the community at large. If we aren’t there to help you get started, we’re concerned you’d just get irritated and leave. (That’s what we’d do, after all.) So no Stack Hammer spam until next month!
Our first PuppeConf has come and gone. All in all, we declare it a success, with a number of key objectives achieved:
- Getting several hundred attendees to wear our ridiculous t-shirts or stick our ridiculous stickers on their notebooks.
- Getting a significant number of attendees to be photographed with their faces sticking through a ridiculous poster.
- Giving a slick Stack Hammer demo to everyone who walked by our station with only *one* bug encountered, which Kenn skillfully worked around in all subsequent demos.
- Verifying that that lots of people think Stack Hammer will be awesome (which we suspected but really didn’t know, because we hadn’t talked to two hundred potential users).
These were not isolated events. In fact, as our Creative Director explains to us, the site design, naming, t-shirts, stickers, cheap publicity stunts, etc. – everything plays a part in creating an edgy brand around an awesome product.
The biggest achievement was the fact that Kenn was able to give a few hundred Stack Hammer tours over three days with only one real bug discovered . What made this so amazing is that we entered testing a week late, lost almost another week due to GitHub API outages and other misfortunes and basically had three days to test and fix an almost completely new service.
Our developers write awesome product code!
John and I haven’t exactly been twiddling our thumbs while the rest of the team gets stuff working for PuppetConf. On the contrary, we’ve been spending lots of time giggling over youtube videos and coming up with clever catchphrases and double entendres.
It started innocently enough with a demo to show at PuppetConf. But somehow we ended up re-watching all the Old Spice Guy videos and decided we had to work that in. (We honestly can’t recall how it happened…Portland, Wieden+Kennedy, power tools…who knows?) And then we were inspired to try our own hands at producing edgy, offensive material that would appeal to the sort of young people we’re likely to encounter at PuppetConf.
And before we knew it, we had probably gone too far, but printers had been paid and the presses were already humming. Having recently skimmed Dick Cheney’s memoir at Barnes & Noble, however, we did remember to build plausible deniability into the most offensive material, so we should be ok.
We’ll have pictures from PuppetConf for you next week.
Remember that first beta we told you about in July? It was pretty nice, but it had a couple of gaps.
First, the product was called Stack Hammer, and you’re supposed to use it build software stacks. The problem was that there was nothing about stacks in the applications. There was plenty of really useful Puppet stuff, but you had to use your imagination to see the stacks. We’d definitely file that one under “shortcomings.”
Second, the company’s name is “Cloudsmith”, and has been since the beginning and that wasn’t an accident. Doing something with the “cloud” today is kind of like doing something on the Internet in 1999. But there was no “cloud” stuff to be seen in beta 1 either: another shortcoming.
We’re taking journalistic license, of course. Every witty blog post has “conceit” and this post’s conceit is to be dismissive of beta 1 when, as we already noted, it was actually pretty nice. So maybe we should just come out and say it: beta 1 was just fine, but beta 2 is an ELEVEN!
Pull your assets in from a GitHub repository, stack up your modules or create new ones. Put the stacks on a node. Configure a Puppet master. Validate it to make sure it’s right; graph it to visualize the dependencies and locate problems. Then deploy it all to your favorite Amazon AMI and spin it up. All from within a very slick looking Stack Hammer UI. Total eleven-ness.
We’ll be cutting over from beta 1 to beta 2 at the start of PuppetConf (this Thursday), and the next days will be kind of dicey. We’re finished development about a week late, which wasn’t bad given that the beta 2 cycle took up four three-week sprints.
But we committed to being out with beta 2 at PuppetConf, which means we have a week less for testing and tutorials etc. will have to wait until next week. We had more bugs than usual in the final sprint when we brought the front and back ends together (putting them on separate development tracks was the only way people were able to take vacations this summer). And, of course, the GitHub APIs we use became suddenly and mysteriously flaky during testing.
So this week’s beta will be an authentic beta, rather than the perfect, pseudo-beta that appeals to our sense of smugness. But….we do have t-shirts and stickers!
We’ve just pushed out the second major release of the Geppetto IDE for Puppet, just in time for PuppetConf in Portland next week.
The list of enhancements is pretty long, and lots of them were requested by early users, many of whom have been really helpful.
We should give a special shout-out to some of the folks at Puppet Labswho have been using it every day and giving us great feedback.
At this point, Geppetto is of at least 2.0 quality. If you’re a Puppet user and like an IDE-style interaction, there’s no reason not to try it.
If you’re going to be at PuppetConf this week, we’ll be glad to give you a tour.
What is a beta without beta testers? Not much, of course.
We assume that every able-bodied Puppet user immediately started knocking out stacks when we opened the beta last week. But in case you didn’t, we’d love to have you as a beta tester.
All it takes is a willingness to (1) try out Stack Hammer and (2) complain to us about what you don’t like using the Feedback link. (If you’d like to tell us nice things as well, we certainly won’t object, but we’re expecting you to complain.)
We’re also working directly with a small number of users to identify requirements for upcoming releases. If you’d like to join this elite and highly selective group, simply email us and you’ll be promptly ushered into the inner sanctum.
We look forward to hearing from you.
Stack Hammer Beta went live today!
We think the end result looks great and is a fantastic starting point for the service. On the other hand, anyone who launches a public beta without a feeling of apprehension, if not terror, for what is about to come is probably delusional.
As with any entrepreneurial venture, such as becoming an oil baron starting with nothing but a pick ax and a few dusty acres, getting here required a ruthless and single-minded focus, particularly on the part of Kenn Hussey and the rest of our engineering team. So hats off to them! (Whereas for “the management,” the key trait required was a zen-like combination of patience and equanimity.)
FYI, if you have no idea what we’re referring to with the picture and the reference to the oil business, this should help.
It’s taken about a year, and a redo, but we’re about ready to unleash Stack Hammer on an unsuspecting public. We’re just polishing up the site, and we’ll start opening it up in a few days.
We’d been feeling really good about how things came together. But then came this new Thor movie. One minute, big hammers are a completely “ownable” brand, and the next they’re on billboards everywhere you look. This is not just some *coincidence* – we’ve been, like, totally ripped off. The Hollywood suits got wind of our plans, and then rushed their film out to get “first-mover” advantage.
The good news is that this is definitely survivable. Our market is pretty different form theirs – movies, action figures and other commercial tie-ins (them) versus web apps that help you create, share and provision software stacks (us). Once things settle down, we don’t expect to be bumping into Kenneth Branagh and his “backers” at Paramount Pictures very often.
And who knows, maybe we’re partly to blame? We thought we got the hammer thing from “smiths” and “smithing.” But it does look kind of *Viking-chic*. Plus, we have all these Swedes on the team. So maybe we actually ripped them off subconsciously?
But we digress. Back to Stack Hammer.
The beta actually came out a bit different than we originally anticipated. Maybe a little less *vision* on display (in this first release), but hopefully useful and easy to understand. Plus, we’ve leveraged some really good and popular technologies Puppet, GitHub/Git and Elastic Beanstalk, rather than indulging the tendency to develop everything ourselves.
In this first version, we focused on doing something really good for existing Puppet users. We took our notion of a stack – a set of software elements you plan to deploy together – and mapped it to Puppet constructs (manifests, modules, catalogs, etc.). Then we provided a nice visual way of developing and sharing these “Puppetized” stacks. Our intention is to be 100% complementary to Puppet, which doesn’t provide much in the way of authoring and sharing support. We rely on the Puppet runtime for provisioning, deploying, monitoring, etc. Following the provisioning hand-off, we’re out of the loop until it’s time to modify the stack.
All the information relating to a user’s stacks (Puppet files, metadata, social info, etc.) is versioned and stored in a Git repo. So instead of inventing a new Git hosting service, we just used GitHub. (They provide a pretty good API for third-party apps.) This makes it really easy to work with assets you keep in Git, and also lets us leverage GitHub’s great social mechanisms.
Many users can’t keep everything at GitHub, so we’ll eventually need to support Git repos in other places. But we think GitHub is a very cool way to get started, and it makes Stack Hammer a kind of bridge between the code you develop and the code you deploy.
Something that isn’t directly visible to users, but has been really good for us, is Amazon’s Elastic Beanstalk. We’d built the first version of the beta on Google AppEngine, which seemed smart until they started to go wobbly on supporting “Internet companies” like us (their term). Then when EB came out this winter, it was exactly what we needed and we were able to take a lot of we’d created for AppEngine and just apply it to EB. So far the experience has been great….it’s the future!
We wanted to keep the first release as simple as possible, so there’s a lot we didn’t include. One area where there’s not much to see yet is the *cloud*. This is kind of ironic, given our name, founding vision, current fashion, the architecture of our service, etc. But we’ll be doing something about that in a release later this summer. Given our recent experience with Mr. Branagh et al., we’ll be keeping the details to ourselves until a later date.
Do not be fooled by cheap imitations like this. You need the real Stack Hammer.
The Geppetto release party is in there!
Geppetto 1.0 is released and ready for download. We want all the feedback we can get, so try it out and let us know what you think!
If you haven’t been following the project, Geppetto is an integrated toolset for working with Puppet modules and manifests. It’s built on the Eclipse platform. If you’re an Eclipse user, you can install it directly into your IDE. If you’re not, it’s also available as ready-to-run .zip’s with a much smaller footprint than the full Eclipse.
Although we’re calling it “1.0″ (actually “1.0.0″), Geppetto is is probably more mature than many 1.0 releases, and we have invested quite a bit of time in it over the last six months. (Actually, it didn’t come out of nowhere; it builds on work we’ve done in other domains over the last several years.)
We released the first beta at FOSDEM 2011 in Brussels in early February, and got lots of really useful feedback there and at PuppetCamp Amsterdam in April.
So thanks to everyone who’s offered help and encouragement along the way, with a special shout-out to the people at Puppet Labs.
We’re just back from Puppet Camp 2011 in Amsterdam. Great city and great conference. And we had a great time.
We were there to speak as newly minted “domain experts” in module development, meet the folks from Puppet Labs. And, last but not least, we wanted to give some early looks at Stack Hammer to attendees, and get some feedback for the public beta next month.
The conference was in this amazing building called the “Beurs van Berlage”, which is Dutch for a stock exchange built by a guy named “Berlage”. They built it to last at least 1000 years (ironically, it was too small and they had to move across the street after ten), so it has six foot thick internal stone walls faced with this incredible brickwork.
Unfortunately, those same architectural qualities make it a less than ideal place for a conference where you hope to demo a web app (such as Stack Hammer), because it was virtually impossible to get a WiFi signal in the building. That said, we did get some feedback and we were pleased with what we heard. We’ll have more on that in a few separate posts next week.
The talk and demo Henrik gave on module development didn’t require internet (Geppetto is a local tool) and was a big hit. (A lot of people were saying it was the best talk they heard, at least until Randall from Puppet Labs gave his talk on usability the next day.) It was both surprising and encouraging how many people are planning on using Geppetto, given that it’s only a few months old and just on the threshold of a real release.
Here’s the slides from Henrik’s talk; the video is below:
We also lead a breakout session on Puppet and the Cloud. The turnout was great, but the session turned out to be a bit disappointing. We really were hoping to talk about web apps/web services in the Puppet domain (hint: like Stack Hammer), but everyone else was just thinking about picking up their Puppet systems and running them over Amazon or Rackspace, or maybe even just on VMware).
No one had any experiences that were specific to Puppet, and there was no point in talking about blindingly obvious topics such as “what are the pros and cons of the cloud.” So the discussion never completely took off. But we did get some good data points, most importantly that it is still early in the actual adoption cycle in the EU.
Worth noting is that “cloud” now has a very definite meaning in users’ minds: general purpose compute infrastructure running at Amazon (or Rackspace, etc.). It *does not* include applications migrating from being on-premises to web apps or web services. So what we’re really interested in at Cloudsmith is “web apps (or SaaS) in the Puppet domain”, not “Puppet in the cloud.” This probably should have been obvious to us before the conference. But now we know.
Finally, we did get to spend some quality time with the Puppet Lab guys, as well as two days in Amsterdam, which alone made the trip worthwhile. Here’s a photo of us hanging out with Luke, Nigel and Randall from Puppet Labs at the end of the show outside the Beurs van Berlage, just as locals were getting started with their annual Queen’s Day partying. We were actually getting some work done, i.e. “aligning our respective visions for the future of” the Puppet Forge. FYI, this picture was snapped just before Kenn (sporting stylish new “architect glasses”) reached over and gave Randall’s beard a playful tug. (Only kidding.)
We’re looking forward to the next Puppet Camp.
We’re off to Amsterdam for Puppet Camp. In addition to doing *platinum sponsor* stuff such as giving talks and networking, we’ll be using the event to show what we’ve been working on for the last nine months.
First up will be Geppetto, which we’re declaring *ready for primetime* and bumping up to version 1.0 (from 0.1). The feedback from FOSDEM was that Geppetto was of at least of 1.0 quality when we introduced it in February, and he’s been significantly enhanced since then. But going directly from 0.1 to 2.0 seemed like cheating, so it’s 1.0 for now. Henrik will be showing Geppetto off in his talk tomorrow, and we’re hoping it takes off quickly over the rest of the year.
The other major event will be an early look at Stack Hammer. We’ve finished the first externally presentable version of Stack Hammer, and we’re pretty excited about how it came out. Nearly everything we wanted made it into this beta “preview”, which about 90% of what we think it needs to be for a full public release. We’ll use feedback from the PuppetCamp preview to finalize the scope of the first public beta, which we hope to finish developing next month.
No trip to Amsterdam is complete without some bicycling. So, time permitting, we (most likely just the “royal we”) plan to stay in shape tooling around town on one of these fifty-kilo Dutch cargo bikes everyone back home has been buying.
Here’s a webcast done by James Turnbull at Puppet Labs providing a good overview of Geppetto.
We introduced Geppetto at FOSDEM in February. We’ll be versioning it up to 1.0 and declaring *good to go* at Puppet Camp in Amsterdam later this month.
So more webcasts and demos to follow over the coming weeks.
It looks like there’s more Buckminster in our future than we thought. Buckminster was one of our most significant contributions to the Eclipse community, representing possibly 50 developer-months of work (Thomas-months, actually…) over the years.
Last summer, we decided that Buckminster was more or less mature. In our view, it was the best way to build Eclipse projects, whether headless or from the workspace, as well as a great solution to all sorts of other build/assembly problems. Roughly half of the projects in the Eclipse release train were built with it. And it had a healthy footprint inside Java development organizations (Eclipse doesn’t keep stats, so it was always hard to know how many).
We had all sorts of new ideas for simplifying the build and provisioning area with modeling and DSLs, etc., but jamming them into Buckminster didn’t make sense architecturally.
Plus, the Maven people were pushing a new technology (Tycho) that was important for their commercial plans. We didn’t see how it was a good use of our time, or good for the community, to get pulled into a fight with Maven partisans over what was, for us, purely a contribution to the commons.
So we figured that we would let the technology speak and users decide. We continued to support the user community. And we continued to use it for our own internal builds (which makes us really efficient). But in terms of focus, we more or less declared success and moved on.
Subsequent events confirmed our recent epiphany that sometimes (by the way, not always, just sometimes) the less you think about something the better it does. Because we woke up last week to realize that Buckminster was, if anything gaining momentum. New projects were using it (Google’s first Eclipse project, for example), and the community was pushing back on the Maven people’s assertion that Tycho has become the “new standard.”
So maybe we were too hasty in our pursuit of the “new.” (It wouldn’t be the first time.) It’s still true that Buckminster is mature. And we aren’t interested in a “Buckminster vs. Tycho” fight. But we will take some time to talk about how we’re using Buckminster (continuous build, GWT apps, Amazon Web Services, etc.) and help others who want to use it too.
-
Cloudsmith Team
Chris
Mitch
Thomas
Henrik
Karel
Filip
Michal
Kenn
John
Chris Horn Co-founder & chairman
Founder and CEO of IONA Technologies, leading middleware/platform vendors of the ‘90s. Started IONA with two of my computer science grad students at Trinity College Dublin and bootstrapped all the way to a US IPO (first for an Irish tech company). Spend lots of time on Cloudsmith, plus a few other teams of ventures in the US and EU.
Dublin, IrelandCurrent Temp:45 F°Mitch Sonies Co-founder & CEO type
Consider myself the “idea guy”, but I’m totally dependent on the rest of the team to actually implement anything. Studied math, but went to law school. Started out as a venture lawyer, became a technology analyst on Wall St. Went into the software industry. Cloudsmith is my second startup. Did the first one with Henrik and Thomas as well.
New York, United StatesCurrent Temp:60 F°Thomas Halgren Co-founder and chief architect
Like to lay a foundation that will last a long long time. Earlier in my career I concentrated on O:R mapping and modeling frameworks and languages. Drifted into the build and provisioning domain. Have done a lot of the heavy lifting for the Eclipse community for several years. Began my career working for Henrik more than 20 years ago. He is now my wingman.Stockholm, SwedenCurrent Temp:46 F°Henrik Lindberg Co-founder and CTO
I’ve been doing this a long time at many companies, startup to public, from operating system to application. Ran JRockit (Oracle’s JVM division) before Cloudsmith. Get most excited about newest stuff and hardest problems. Would solve every one with a Turing-complete language (plus an editor) if the team let me. Thomas is (still) my wingman.Stockholm, SwedenCurrent Temp:46 F°Karel Březina Developer & architect
Joined the team with Filip. Michal, Filip and I were all CS students together in the Czech Republic. I’m a Java type, but I like working on the user interface more than the other guys. Michal is my squash partner; he hits harder but I win with superior tactics.
Pilsen, Czech RepublicCurrent Temp:36 F°Filip Hrbek Architect & developer
I’m the anchor of Cloudsmith/East. Met the rest of the team through some open source projects. Got intrigued and joined early. Brought along former colleagues Karel and Michal. Used to focus on server-side of things; now having fun with UI development as well. (GWT is Java, after all).Pilsen, Czech RepublicCurrent Temp:36 F°Michal Růžička Developer & devops guy
Joined the team as a developer just after Karel and Filip. Handier with machinery than the others, so I also manage all our builds and infrastructure. Spend a lot of time helping enterprise customers with provisioning problems. Spend half my time developing, half my time doing devops and third half on customer projects.Pilsen, Czech RepublicCurrent Temp:36 F°Kenn Hussey VP Development
Modeling guy & toolsmith by background. Worked at Embarcadero and IBM/Rational before Cloudsmith. Spend half my time planning the product and managing the development cycle and other half coding. Originally from Nova Scotia, where we like to have kids early and sail. (I did/do.)
Ottawa, CanadaCurrent Temp:46 F°John Malcolmson Creative Director
Help focus the message, make everything look good. Try to add a dash of “flavor” as well. Originally from New Zealand; went to RISD and stayed here. Worked in large branding/design firms. Ran my own shop with a partner (Cloudsmith was a client.) Left after we merged with a bigger firm. Now divide my time into slices for 3-4 startups needing internal creative direction.New York, United StatesCurrent Temp:60 F°
