Contributing To Open Source Projects As a Learning Tool, Part 1
A few weeks ago, Amy Bucciferro wrote about different learning styles, and how the tools for learning to use, administer, and develop on Salesforce align with certain learning styles. As a largely self-taught coder, I have found the open source projects that members of the Salesforce community have made available an incredible resource. Reading the code and documentation that others have written, and then eventually submitting documentation and code for inclusion in a project, has helped me gain skills and confidence as a developer.
Since even the clicks-not-code parts of Salesforce apps can be stored and shared as text-based metadata, app builders who use these declarative development tools can also gain valuable insights from, and contribute to, open source apps.
What is open source software?
The Open Source Initiative defines the term as "software that can be freely used, changed, and shared (in modified or unmodified form) by anyone."
This means that the source code — the text files used to create a piece of software — are available for anyone, that anyone is allowed to modify that source code, and, if they like, create a new version of the software program. There are a variety of ways that an open source software project can be organized (or not), and a variety of licenses applied to their code, but the bottom line is that the code is available for you to use as you see fit.
Open source software on the Salesforce platform has a couple of attributes that most other platforms don’t. The big one is that the Salesforce platform itself, which is required to use any code written for it, is not open source, and for any real business use, requires paid (or donated) licenses. Another challenge has to do with how apps are packaged and distributed — there are practical pitfalls to taking an app, modifying the code, and installing that code into your Salesforce instance. If you do that, you can’t easily install upgrades that the original app publisher provides.
Finding and installing open source projects
Despite these limitations, just having access to the source code of a Salesforce app is incredibly empowering. This lets anyone who can read code see exactly how the app functions. As an app builder, you can install it into a developer org to see how the Lightning Processes, Flows and Workflow Rules are set up, without having to read any of the code.
There are two main ways that open source software for Salesforce is shared. The first is as an unmanaged package. To install an unmanaged package into a sandbox or developer org, you just need its install link, similar to most other apps you get from the AppExchange. The difference is that you’ll be able to see and modify everything that the unmanaged package adds to your org. However, that editability comes at a price - you can’t upgrade an unmanaged package in-place; you have to uninstall and then reinstall, and uninstalling deletes all the data in any objects or fields that are part of the package.
A great example of an unmanaged package that you can use for learning is Salesforce’s own Dreamhouse App. The Dreamhouse App was actually built to be a tool for demoing and teaching about Salesforce features, and it has lots of declarative goodness if you’re not interested in the code. Salesforce has released several other free and open source tools as unmanaged packages over the years: Action Plans and Milestones PM are particularly well-known ones, and offer great opportunities for learning some code.
The other main way that open source projects for the Salesforce platform are shared is via source code repository sites. GitHub is far and away the most popular site for this, but sites like BitBucket and GitLab can be used as well. Getting the code and other metadata into an org to see how things actually work takes some additional technical steps in many cases — “cloning” the repository onto your local hard drive, and then using one of the IDEs for Salesforce development or the Force.com Migration Tool to deploy the code and other metadata into an org. Fortunately, Andy Fawcett of Financial Force, who has made a lot of contributions to the Salesforce open source community, has provided a Heroku-based tool that helps you to deploy from a GitHub repository (or “repo”) directly into a Salesforce instance. Many Salesforce projects’ GitHub repos feature this button:
which you can click to be linked to Andy’s Deploy to SF Heroku app and install the project. For those projects that don’t offer the button, you can try this Javascript bookmarklet that I built. When you are on the main page of a GitHub repository, you can use the bookmarklet to pass the repo’s URL to the Deploy to SF app.
In the next post, I’ll dig into some of my favorite open source projects, and what specific lessons can be drawn from them.
Do you have favorite Salesforce open source projects that you’ve learned from? Want more details on how to get started with open source code? Share your stories and questions with me on the Arkus Facebook page, in the comments below, in the Success Community, or to me directly via Twitter at @tet3. You can also see my GitHub profile for repositories I’ve starred and forked for my own future learning opportunities.
Photo credit: "16th st" (CC BY-ND 2.0) by Peter McCarthy
