Lessons learned on more than 1 year SCN SDK community
This will be non-technical blog.
I want to write on my lessons learned of more than one year working together with many members of the SCN SDK community in great collaboration and bringing value for other users / partners and customers. The reason I want to write it is to show and convince others that also in small scope collaboration is helping to speed up, learn, know each other and increase the value from common efforts.
I have used some time in last month to review what we have done, how it came and what outputs have been produced. I have looked at the old times, old components we created separately and together. Here my personal view on the procedure.
My initial work.
A short overview on the historical data, I have been more active on SCN around August 2014 – this was the time when Design Studio 1.3 SP1 has been released. With this release SDK development has got some important method (for me) – afterDesignStudioUpdate() – which has allowed creation of UI5 components with easy synchronization of updating properties. This was a point for me when I started to look at any options to create show cases for SDK components. My focus was always to fill-in areas where at that time some components were missing.
The first component – Design Studio SDK: NotificationBar Component – was a tryout. And this worked! I could get it done – simply covering already existing component from the UI5 library and making it work in DEsign Studio. Then, with Design Studio SDK: Simple Date Object Component I have learned how to use the capabilities of ZTL language and provide some functions in the scripting language. Some more components have followed up, until around September 2014. All those components were in the GIHUB repository GitHub – KarolKalisz/DesignStudioSdkPack: Design Studio SDK.
My view on MIke’s initial work.
I must say that at the time Mike has provided already a repository with many components – Design Studio 1.2/1.3 SDK – Design Studio Utility Pack. Those were collecting many components written already since November 2013, bounded in the utility pack (May 2014, after RTC of 1.3 release). Mike has started the “open source” idea, which was quite new at this point of time – especially for SAP software.
I have followed similar procedure in the beginning – as in the beginning it looked like every component is “self-contained”, so it does not matter how it will be downloaded and installed. But this has changed as I have seen that my components are quite primitive, basically I could not write any APS at this time – I tried once, but it was very basic.
In many discussions over SCN (great platform to exchange ideas on SAP content) at some point of of time we got together and started to cooperate on ideas, code content and other functions, MIke’s blog on Design Studio SDK – BIAL for…next loop (and my first GitHub co-author attempt). For me, the start was actually 2 versions for Accordion component, one from Mike – one from me.
We started to discuss also an option to make a github repository which is really public, this is how the community work started – the goal was to be ready for New Year 2014/2015 (which matches the release of Design Studio 1.4). On the way, we could “deprecate” the old repositories, make a structure which is helping us to work together (avoiding too many rebases and merges) and offer semi-automatic production capabilities for release of the content.
The community has been created – SCN Design Studio SDK Development Community. The next steps are quite public in the scn blogs, so now it is time to collect lessons learned.
At some point of time we managed to get the technical help content at Component List 3.0 – SCN Design Studio Community where all components are listed with its functions. Those content is also generated, so it gets updated when we change the components.
1. It is good to have a good technical infrastructure
We have found the infrastructure in GITHUB – this is how we started and this is how it currently works. It offers easy collaboration on code, we have increased the collaboration by some “procedures” how to avoid conflicts in merges – my blog SDK Development Community Git Repository (list & documentation). There is one more point, the infrastructure needs to be in “common sense” and “as primitive as possible” to not get into lengthy discussions. We managed to find it quite quickly, but there is always a risk.
2. Work on same content can be a nightmare (merge conflicts)
This learning is my personal – especially as I was not experienced in GIT procedures at all, and even now I can say – I can use it until I get into troubles. Then I make a copy, reset and overwrite ;-). But in my searches on fixing issues, I found a lot of blogs suggesting the same in troubles… This is the reason why we splitted technically the content into more repositories, one for code, one for binary files, one for help files…
3. You do not need to understand everything
When working together, I often had to say “WOW”.. when something new got pulled from the repository. Especially when I remember the Mike’s work on APS code to process parameters – this was and is Mike’s area of expertise. I have tried to get the idea and understand how I can use it in my components. First after few weeks or even months I have debugged into the code as I wanted to change some places. But in general, the understanding is required first when you need to make something with the code – important is to get the “external API” first.
4. Community has to define very flexible rules
One of my findings is, common rules help and a baseline must be common. In other case the scripts which have to be used would not work in our repository. But the ways how to get to the common rules and structures is open – this can be seen in the repository on the example how we create components. I have my way, Mike has own way. But we are happy as both are leading to the same output and structure.
5. Everyone is welcome (you do not need to code)
It is good to have more than 2 members, and this is something we achieved. Not everyone is coding, but there is a big value also when someone is using the components, providing feedback, reporting issues. My hope is that more people will join in the future.
6. Common reused code is helping to make bigger value from effort
For me, there were 2 big “steps forward”
– the generic APS, which allows also component generation and ZTL script generation used in my components and
– common methods for flattening of data, which allows to convert the multidimensional data model (hard to understand) into something which is easy to use.
The reuse of such code in many components was really reducing the effort of component creation. Honestly, small idea – and new component can be created in 2-3 hours as only the rendering part counts. The other parts are generated based on specification. This is allowing us to contribute with very small time effort.
7. Everyone is bringing his knowledge area
In a community it is important to find and use the expertise from every member. This is how the work gets shared better. As Mike was bringing a lot of big components, I have concentrated myself on covering the SAPUI5 components. I have looked again on many of the components blogs – and such as the Design Studio SDK (1.3/1.4) – Opensource SCN Maps (Part 1) or Design Studio SDK – Hexagonal Binning are requiring a lot of time to be coded (at least in my view), and this is the point – do what is cheap for you (as you know how to make it) and leave those parts you have troubles in.
8. Using published code from someone else (or yourself) is a nice experience
Not the technical part counts. What counts is the outcome. This means, it is not necessary to invent the same code again and again. I have used some code from Mike and also from other components I have written. In addition, at some point you will know where is the solution to your current issue – and then go, copy and use. very nice.
9. Freedom of expressions and development directions is a personal value
We have very less synchronization on any direction. Everyone has freedom to contribute what he want – and this is how the repository grows. There were some synchronized actions like the 3.0 conversion due to changes in design studio 1.6 SDK api (or extensions actually), but this was a technical change which had to be made. On use cases and ideas, it is just nice to see others commits and direction of work when it is available.
10. Building modular software with common functions helps
Again the point with collaboration and merge issues. the repository is quite modular. It means the code is existing only once and in case the function needs to be changed it can be changed only once.
11. It is really hard to get feedback
A bit challenging topic is – why we do it? Is someone getting value out of the work? This is really hard to answer. But after the year I can say – yes. Some are just influenced and perhaps build own components based on the ideas, some are really using the content. Perhaps this topic is so difficult as the content is open sourced and free accessible. But on other hand, if something will break there is quick feedback. And looking at the Issues page there are already more and more reported topics for issues or extensions. Also here I hope this channel will increase.
12. You have to risk when changing (and avoid changing to reduce risk)
I still remember the last conversion to 3.0 repository version. We changed a lot.. and we tried to make everything working again. It is so good that we have a lot of common code, many components are generated. But at the end, it is open source content and not a full time paid job, so the time is restricted. It means also some activities must be made manually when changing parts of the code. This means, we now do not touch too much – if the component is working as expected, every change can break it. Something like big refactoring is not planned (good that there is no reason currently for it..)
13. community is growing not too fast
Finding others for participation and setting some procedures (like creation of issues on Issues instead asking in SCN which is quite easy to miss) takes time. You have to accept that there is much time required to establish such communities. Also some effort in the preparation and setup and documentation. This pays out at some point of time.
and my last one..
14. Community work never ends
The special point is – the work does not end. In my journey over old documents, blogs – especially from Mike and myself – shows that some nice components which were available in the old repository are not available in the new one. It is hard to say what does it mean (point 11) and we do not know if someone would like to have it, but as it is not available is using also the old packages? Second topic is, the components we have created were our own idea – “what do I miss in my project?”, “what could be made better?”. But I think that also others can bring ideas what could be build – as extensions in the Issues list.
I hope that not only the contributors, but also other developers could learn in the time since the community has been started. I hope also that those of you who use the components in the installable version will have fun with it for long time. All code is open and in any case which will require it changed, corrected by anyone (not necessary the initial author).
As of today, you can also find all existing components in the great summary by Mike SCN Design Studio 1.6 SDK Components (ver 3.0). or the community story SCN Design Studio SDK Development Community.
Any feedback including issues, enhancements or some others feel free to place on the Issues area in github.
Many thanks to…
Michael Howles, Franck Blais , Manfred Schwarz ,Martin Pankraz , James Rapp , Mustafa Bensan , Jeroen van der A , Donnie Burhan
for the awesome collaboration, learning from you and bringing value by work in one direction!
I hope you have enjoyed the time as well and we can still stay together helping others with the community content. For me it was a great time with a lot of learning! Every component I have created was a small step in the learning curve!
You guys are doing amazing work 🙂 . I really appreciate the efforts you put into this scn developement community.
Great work, must say! Your contributions are really a great asset to the Design studio community and its SDK community.
I really would like to thank Mike Howles for having put a SDK blog for a SDK issue of mine, which had the close solution to the same.
Its really is helping the developers a lot and also it being a free source, it is cutting off the firms which are trying to make good profit outta a tiny gap in the SAP versions.
Appreciate your valuable time and effort, which is a great addition to the Design Studio Space.
Glad that SAP is including many standard components in the upcoming versions. Looking forward to contributing my made SDK components to this community in future.
I'm glad you've found the Design Studio SDK Community to be helpful.
Further to your comment about "cutting off the firms which are trying to make good profit out of a tiny gap in SAP versions", I think I can safely state my opinion that this is not the fundamental aim of the SDK Community but rather to provide customers with more choice and to share knowledge to assist in development.
Keep in mind that SAP encourages partners to develop commercial components to fill gaps in functionality and it is only to be expected that partners should make a profit to cover their investment in product development and sustain innovation.
In the end, customers always have the freedom to evaluate both free open source and paid commercial options to determine which ones best suit their needs. In the case of commercial components an important influencing factor will certainly be the perceived value-add and as such, presumably components that merely address a "tiny gap" would not be considered anyway.
I want to confirm the statement from Mustafa - there is no intension to compete or "cut" any partner solution which has similar functionality as the open source components.
The goal of the scn community components is
- on one hand broader in sense of knowledge share – community offers the code, bring new ideas, help in learning "how" it works
- on second hand smaller in sense of all processes around – community offers the components and “open source support model” – if something is not working as you wish, there is no commitment this will be changed. Of course, we try to fix issues – but there is no paid support.
The business model of partner solutions is actually opposite.
- you will not necessary know “how” it works, but
- you pay for the working components, you have contract on maintenance and you can request specific changes which are not yet implemented.
On customer side, as Mustafa also writes, it is a business decision – open source vs paid service. Not everyone can afford payments for the service, but also not everyone is allowed to use open sourced components, see Do you use SDK Extensions in your applications? poll.
Our community goal is also that partners can get insides on “how” it works and improve their components with the ideas, this is why we share the code as well.
Thanks for your contribution to the SCN Community !!!
Also, thanks for your quick turnaround and support when we post questions / feedback comments about the component enhancement / bugs.
Appreciate your time and effort.