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.
Community Idea
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.
Milestone
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.
Lessons Learned
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.
and also..
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.
Closing Words
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...
mike.howles4, franckblaisbeyond , manfred.schwarz ,martin.pankraz , james.rapp , mbensan , jeroenvandera , 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!
