WHAT IS CLOUDSMITH?

You can think of Cloudsmith as a big, open-ended map of dependencies among software components. We provide a simple way to create configurations (we call them "stacks") of components in the map that can be packaged up as complete, downloadable sets of assets (we call those "distros").

To understand how Cloudsmith works, you need to know that Cloudsmith is a metadata repository (or a "repository of repositories") rather than a code repo per se. Cloudsmith holds metadata describing where the components are found (typically, the URL of some repository), what versions are available, and other descriptive information, but not the source or binaries themselves. When Cloudsmith maps a new repository (a maven repo, an update site, your local CVS/SVN, etc.), it generates metadata describing what it found, but leaves the code itself in the repo where it belongs.

To create a stack using Cloudsmith, you just add components to a list, and rely on Cloudsmith to worry about all the moving, copying and other physical manipulations required to package it up into something downloadable. Later, when you download the stack (more precisely, a distro of that stack), a special installer reads instructions from the repositories involved telling it where to find the files and how to assemble them into the final product.

The Cloudsmith repository has some extra smarts. All you have to tell us is that your stack needs component A. We can figure out that A depends on component B and C, and that B and C need D thru G, etc., etc. (we calculate the full transitive closure). And we are continuously remapping all the underlying repositories, so we can keep your stack up to date as the components you've stacked move or change. (Cloudsmith stacks even come with RSS feeds that tell you when something changes.)

This makes working with components from multiple places a lot simpler. For example, you don't have to worry about where things are, once they're in our map. This means you don't need your own download site just to make sure you have stable copies of all the components - Cloudsmith solves that - or to provide a one-package download - the Cloudsmith installer provides a complete one-click download experience. And since you're not physically combining and distributing packages from different places, you may (in some cases) be able to avoid conflicts between different open source licenses.

WHAT DOESN'T CLOUDSMITH DO?

There's a lot it won't do, actually. And to see where Cloudsmith fits in the landscape, it's almost as important to understand what it doesn't do as what it does.

Cloudsmith is not a code repository, although we do provide a uniform way of assembling across different repository formats. Assets stay wherever they belong - your CVS/SVN, a Maven or Ivy repo, a file system, Google Code, etc. This means if that the underlying repository just disappears, then the components in them do as well, from Cloudsmith's perspective. (Although if Cloudsmith knows the component is available somewhere else (frequently the case for open source), Cloudsmith automatically adjusts.)

Cloudsmith is not a build system, in the sense of actually compiling your code. If binary forms of your components are in the map, you can stack them into a binary download; if not, something else has to build them. On the other hand, Cloudsmith integrates well with external build technologies. For example, you can stack up source components, and then use an external build system to compile the "source stack" into a binary.

Cloudsmith is not an installer in the conventional sense, although it does function as one in many cases. Cloudsmith's "special installer" (a "materializer") executes instructions that tell it where to find and how to assemble the components of a stack, and then it downloads, unpacks and copies them into the right places on the local machine. In some cases - Eclipse environments, a JBoss server, etc. - this is all installation requires. But where installation means writing to the registry or configuring resources, Cloudsmith needs to call a component's native installer. So, you can use Cloudsmith by itself to install the "A", "M" and "P" in a LAMP stack, but not the "L".

Cloudsmith doesn't know if a stack works the way it should, although we do make it easier to test stacks that are complex or change frequently. This makes it much easier to test (and retest) in many respects. But you still have to test stacks you create. And when you're using a stack someone else created, you're ultimately relying on them (or a user community) to tell you that it does what it's supposed to.

Cloudsmith is not a web search engine. If you think you know what you're looking for, you can search for content in our map by name or tag (keywords or user-created). We'll show you version and dependency info, who created it or where it was found, along with any other information generated by live users at Cloudsmith. But if you want to just see what's out there, or learn everything there is to know about a given component, you'll probably want to use Google.

Cloudsmith does not replace social networking tools such as Facebook. In fact, we think we make a killer combination with them, although we're not yet leveraging them as much as we intend. Currently, we let you embed RSS feeds into content you create, so that you can keep communicate news and updates. We generate special html links you use can use to embed stacks you create directly into blogs or sites. We let you create multiple publishing identities/brands and share content with groups of collaborators. But we have no intention of becoming "Facebook for developers."

WHAT DOESN'T CLOUDSMITH DO NOW THAT IT WILL DO LATER?

The thing you're most likely to notice is that Cloudsmith doesn't contain all the components you would expect it to have. In general, this is just because Cloudsmith is a really new service and we are only now investing in building up the map.

In theory, any type of asset, regardless of technology, can be added to the map. And we hope to have nearly every open source component someone cares about as soon as possible. (However, there will be some specialized domains (the Linux kernel?) where there's no problem left for us to solve.)

If you're looking for open source Java or Eclipse components or things found in public Maven/Ivy or OSGi bundle repositories, you may not have to wait long. You'll find a lot of these at Cloudsmith already, and we'll add them as fast as we find them. If you're looking for PHP, Ruby or Perl components, you may have to wait somewhat longer (weeks or months, not years) as we extend Cloudsmith to map popular repositories for those technologies.

If you're looking for older C components in the public domain, you may have to wait longer. It's easy to add these components to the map, but it's generally hard to extract useful metadata regarding dependencies, etc. without lots of manual work.

If you're thinking about C# components, so are we. It's not hard to add support for mapping them (as long as we don't worry about providing the same level of IDE integration we provide for Eclipse), and we think there are a lot of developers out there who would like to combine them with other technologies. It's just a question of prioritization for us.

If you're wondering about adding your own components to the Cloudsmith map, we don't currently expose those capabilities to users. The functionality is there, but we haven't yet figured out how to create a UI that hides the messiness of dealing with different repositories. If you just want to add something to the map, ping us and ask us to do it for you; we'll try to respond to you immediately. If you'd like to help us get the user interface right, you can participate in our beta program.

If you're wondering whether you can map proprietary components (non-open source), the answer is we support that. Components that are privately mapped will be visible only to those you allow to see them, as will stacks to the extent they depend on them. However, you'll have to contact us to do it for you (until we open up mapping directly to users, that is) and you will need to be a commercial customer to do it.

Another thing you may notice is that in most cases Cloudsmith doesn't show you much descriptive information about what you see in the map, who created it or what others think of it. The reason is that "soft" content is created by live users at Cloudsmith, whereas most of the content you find at Cloudsmith today was added by map-bots mapping components in repositories. Each time someone creates or comments on a stack, we'll have more information to present.

Finally, you may notice is that it's not as easy as it should be to look for content in the map. Currently, we let you search for things, but we don't let you navigate the underlying map directly. This is something we would find useful, and we'll be adding it soon.

HOW CAN ENTERPRISE DEVELOPERS USE CLOUDSMITH?

Here's a simple but common enterprise scenario. You're part of a small team developing applications for several different target platforms (combinations of operating system, application server and database). You're using Eclipse as a development environment, and the tooling needed (a mix of free and commercial plug-ins) varies with the target platform. You currently waste time changing your development environment as you switch from project to project, particularly during the test cycle. A different team member "owns" each development platform, but no one takes the time to documents them, so it takes a week for new team members to set up their development environments correctly.

Using Cloudsmith, you can create a stack for each tooling/platform variant. (If you're worried about privacy, publish them privately so only your invited team members will know they're there.) By clicking a link (which you can keep on your wiki) and running the Cloudsmith installer, you can install the tooling directly into your Eclipse environment and the platforms directly into separate workspaces. To switch environments, all you need to do is change workspaces. Since the stacks are self-documenting, a new developer can get set up an environment in in a few minutes.

By adding developers, development sites and tool/platform variants, you can scale this simple example up as far as you'd like.

HOW CAN OPEN SOURCE DEVELOPERS USE CLOUDSMITH?

Here's a common scenario for open source developers. You lead a widely known project that produces a single product - an important Eclipse feature, for example. You have lots of ideas for how to combine the feature into a larger product, and so do other members of your developer community. These may be out of scope for the project itself, or require components that can't easily be hosted at Eclipse. (And no one is volunteering to maintain an external download site.)

You can use Cloudsmith as the sharing mechanism for these "extramural" activities. For work that is just a prototype or example, stack up the source components and publish it as a link in your blog. Readers can install it directly into a workspace to try it out. For actual end-user products (combinations of your Eclipse features and run-time elements, for example), publish them as binary stacks and keep users up to date with changes using embedded RSS feeds. In all cases, other members of the community will be able to modify them or use them as components in new stacks they can share back into the community

IS CLOUDSMITH A FREE SERVICE?

That despends. If you are working with "public" components, then Cloudsmith is completely free. Creating stacks is free, whether you share them or keep them private. So is adding new components to the map, as long as you make them publicly available.

On the other hand, if you want to add components to the map that won't be generally available to Cloudsmith users, or work with stacks that include private components, then you may need some sort of commercial subscription. For more info, see our beta offering summary.

IS MY CLOUDSMITH ACTIVITY PRIVATE?

The short answer answer is "yes." Obviously, if you're creating a stack and sharing it with the public, then privacy isn't an issue. But stacks and components that you haven't made public will be visible only to those with whom you've shared them. For more info on these and related issues, see our terms of service.