Back in September 2016, a small team (including myself and Dan) in IBM UK was formed with the mission to improve the development experience for blockchain technologies. At the time, the learning curve for blockchain developers was incredibly steep, and we felt that by improving the development experience we could kickstart the creation and growth of blockchain networks. Our initial prototype was codenamed "Concerto", and this code went on to be accepted by the TSC in March 2017 as Hyperledger Composer.
Since then, Hyperledger Composer has assisted developers and business users in learning the key technical and industry concepts of blockchain. It allows users to model an industry specific use case through a business model definition, transaction processing functions, and external integration which can all be deployed to a running network on Hyperledger Fabric. We've seen a huge uptake by you, our community, with Composer being used by many first time blockchain developers to build POCs, win hackathons, and also build a handful of live production blockchain solutions.
Speaking on behalf of my team in IBM, we're all incredibly proud of what we've contributed to Composer over the last couple of years, and we are grateful to the community for all your feedback and contributions.
However - we at IBM believe that there are some fundamental problems with the architecture and design of Composer, as it is today, that have made us reconsider our future direction and plans.
Here are three of those problems:
- Composer has been designed from the start to support multiple blockchain platforms, not just Fabric - but this design has come at a cost. This design has meant that there are two completely different programming models - the Fabric programming model (chaincode) and the Composer programming model (business networks). This has caused significant confusion to users, with them needing to make a "choice" between the two programming models, with very few similarities between the two. In this particular case choice has been a bad thing, with many users opting not to use the "optional" part past the initial exploration or POC stage.
- This design has also made it a lot harder for us to adopt and expose the latest Fabric features. For example, one of the questions we are constantly getting at the moment is "when can I use the Fabric v1.2 private data feature with Composer?". Whilst we've taken some steps (getNativeAPI) to assist with this problem, it is extremely difficult for us to keep up with and aligned with the latest features in Fabric when we are trying to maintain a design that keeps us blockchain platform independent. This has meant that users have understandably stopped using Composer and instead have reverted to developing with Fabric.
I think it's also worth pointing out at this time that we've had a lot less contributions from non-IBMers than we originally hoped for; we've tried to be as open as possible, with our designs and plans being openly discussed in GitHub, Rocket.Chat, and the community calls - but for some reason, it hasn't really worked.
As some of you in the community may have noticed, the IBM team contributing to Composer have gone a bit quiet recently, with only minor changes delivered to update Composer to support running against Fabric v1.2. Those of you with an even keener eye on work in Hyperledger in general may have noticed a few of us turning up in the Fabric community, and starting to contribute to Fabric (FABN-692, FAB-11246).
At this time, IBM has decided to reduce the investment it makes towards developing Composer, in order to focus the team on directly delivering improvements into Fabric. At present, the team is working on two big features, due to be released as part of Fabric v1.3, that will improve the underlying chaincode and application APIs in Fabric. We believe that these features will start to provide the underpinnings of an improved development experience for Fabric users, and we are looking to continue to deliver improvements in Fabric v1.4 and onwards - for example, you may see modelling, REST APIs, code generators, IDE extensions, and online playgrounds start to appear in Fabric over time.
The IBM team will continue to update Composer to maintain compatibility with the latest Fabric v1.x releases, and we will fix any high priority bugs - but certainly for the time being, we will not be looking at delivering any major new features into Composer.
We would also like to make it clear that we are still more than happy to engage with potential new contributors, and help you get up and running with delivering the features and bug fixes that you deem important into Composer yourself. If you're interested, we'd also love to have you come and take a look at what we're doing in Fabric. Our goal is as always to enhance the experience for developers who are developing blockchain solutions , and as developers - you're best placed to give us feedback on what we're doing.
Finally, Dan (now at Clause.io) has also proposed an exciting plan regarding the future of the modelling language, which involves splitting the code out so it can be more easily consumed and used by a much wider range of blockchain projects. We'll be looking to publish a sample that shows the modelling language being used in conjunction with smart contracts in Fabric v1.3, and hope to extend the code to support additional programming languages (Go, Java, etc).
SimonUnless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU