For the last year and a half, we’ve been promising that the Eclipse plug-in for platform development would be released as open-source. We get questions at least once a month asking if we still plan to follow through with that promise.
Your long wait is over.
This week, we released a new version of the Eclipse plug-in. We are making the source code for this new version public. *crowd goes wild*
Tooling API, You Complete Me
This plug-in software embodies the vision that was originally behind the Tooling API. We built the Developer Console against this API, and have now moved (most of) the Eclipse plug-in to this API as well. We can now confidently say that we have an API that supports the development lifecycle across multiple environments, including browser-based tools (i.e. without a filesystem) and client-side applications.
You could think of the Tooling API as us open-sourcing our inner workings. In that sense, we’ve opened up our code to you already. The API allows you to build tools for yourselves that are like ours and perhaps better than ours. Many of you have tried out tools like BrainEngine and MavensMate; these are two excellent examples of how the Tooling API has allowed you, the community, to provide more alternatives for doing development on the Salesforce platform. Brian Matthews & team and Joe Ferraro have done a great job of building and sharing their work, and I can’t thank them enough for what they continue to accomplish. Now you have an opportunity to join them in adding to the developer toolkit.
Take This Joy And Share It
I get a lot of questions in the form of “Why don’t you add ____ to the Eclipse plug-in? That would make _____ so much easier and better!” My response breakdown:
- “We have that as a story on our backlog, but we haven’t gotten to it yet.” 86%
- “Sweet idea; we hadn’t thought of that.” 11%
- “I think you have the wrong Josh Kaplan.” 3%
We actually have a dashboard entitled “Opportunities for Glory”, which lists many of these ideas. We are sharing that opportunity with you.
Over the years, we have learned that building an IDE takes a lot of time. Developers are fickle, creative, and prolific. It’s hard to incorporate every single good idea and request that we get from the community, or at least to incorporate them quickly. Supporting every specific org shape and usage pattern means a multi-dimensional matrix which, if it gets any more dimensions, will become a multiverse. To top it off, developers are very opinionated, and both very vocal and very quiet. You can either be the squeaky wheel or the silent masses, and balancing across that spectrum is a tough act.
In short, we don’t want to go it alone. We want your involvement. We challenge you to answer the call that we answer every day. Together we can accomplish more than our team can accomplish without you.
So How Will This Work?
(Note: There will be a much more comprehensive governance document posted which you can read for much more comprehensive details.)
1. The code will live in a public GitHub repository
You can go download everything at https://github.com/forcedotcom/idecore.
2. Salesforce employees will be the only committers on the master branch
Make as many branches of the repository as you can, dear friends, and manipulate them to your hearts’ content. The master branch, though, is going to be protected as SFDC-only.
3. Salesforce will continue to maintain and update a supported version of the plug-in
The master branch will represent the supported version.
4. If you would like to make changes, create your own branch
Having your own branch allows you to manipulate the code and apply changes to it. You might be fixing a bug, because, as a rock star, you have a hard time being aware of a bug and allowing it to live if can fix it. You might be augmenting an existing feature. You might be creating a wicked interaction with other Eclipse features. Whatever it is, I encourage you to tinker and innovate.
5. If you make worthwhile changes, submit a pull request
This is the way you can get contributions to the master branch – a pull request. We will review all pull requests that come in, but not all will be incorporated into the master branch. Keep in mind that we are agreeing to support the master branch, so we’ll need to be certain we want to support your Rube Goldberg Mousetrap before adopting it.
6. Help foster a unified “Community” branch
Just because we don’t accept pull requests doesn’t mean the contents are not worthwhile; we just might think they’re still maturing or are too complex for us to support them. For this, I hope to see the creation of a community-supported master branch.
The idea is to have a branch which is a superset of the master branch, containing the features considered too awesome for the master branch. I would be very supportive of this! I hope that such a branch would contain enough additional functionality that it would become the version that everyone installs, rather than our officially supported base product.
7. Stop, Collaborate, and Check in
Use the GitHub to talk amongst yourselves, find people working on similar ideas, check with the community (and with us) for help or advice, and for staying up to date. Git will let you easily adopt changes made to the master branch or any other branch, which should let us collaborate nicely.
8. Add ideas to the GitHub issue tracker
Even if you aren’t going to be able to do any development, you can still participate in the process! The repository has an issue tracker to which you can contribute feature proposals, and comment on pre-existing ones. You’ll find it here: https://github.com/forcedotcom/idecore/issues?labels=feature
You can still add ideas to the idea exchange. However, since this is a collaborative development environment, having the content in GitHub allows non-Salesforce developers to modify these ideas as they’re being worked on.
Dusting Off The Cobwebs
Fun Fact about the IDE Plug-in: It’s OLD. It was written way back in 2007, when Apex was born. In recent years it had gone into a deep freeze as we have focused on the Tooling API and the Developer Console as a reference implementation for it. The team that had originally built the Eclipse plug-in had done a good job, and had moved on to other things here at Salesforce. For the last few years, we have fixed major bugs and revved the Metadata API to the latest version, but not much else.
This means that there are still lots of minor bugs in there. Now that you can see the code, you can see our bugs. You may laugh and point appropriately, but be aware that we are seeing the same code you are. We also see the humor in parts of the implementation. We have cleaned up a lot of #areYouKiddingMe code, but there is more to do.
I restate my challenge – if you see an area that could use a re-think, or code that is just clearly buggy, please make an attempt at a fix. When it comes to accepting pull requests, proper bug-fixes will have the least trouble being adopted into the supported branch.
Let’s Roll
Come join us on our journey! The internal team that has worked on this tool is far smaller than the number of people who use it, and smaller than the subset of that group who are capable and willing to work on it. I know how great our developer community is; I cannot wait to prove that to the world at Dreamforce, when I get up and talk about each person who has made a contribution to this application. I want your photo in that slide deck – make it happen!