As some in the Sitecore community know, Jamie Stump and I put together a module for Sitecore, Integrated Dynamic Placeholders, during the last Sitecore Hackathon. In 24 hours, we developed the ability in Sitecore to use a single placeholder setting in Sitecore to instances of a particularly named placeholder that is intended to be on your page in multiple instances. Like any 24 software development cycle, we rushed our design and development, hurried our documentation, and minimized our testing approach in order to meet the deadline.
Of course like all developers, we thought we tested enough. In early April later I had a former colleague reach out to me via LinkedIn to show me an issue he was having with nested placeholders not propagating. He provided me with some concrete examples of the failure and the condition to recreate. Unfortunately, Jamie and I were a bit occupied with work and family life tasks. Fortunately for us, my former colleague understood and was patient until we could free up.
Later that month I got a tweet about the same problem – however this was a member of the Sitecore community and not a former colleague. The issue here sounded the same, but again Jamie and I were underwater and had little to no time. There was more push to get this fixed as this person needed it for a big project they had been stuck on, and by the sounds of it needed it by the following start of the week. Jamie miraculously with his schedule, found some time to correct the issue the following week. It didn’t take him long to correct, the module just isn’t that big, but he finally got some time on the last day of the month to get it out the door.
Fast forward to June, and people have begun to use the corrected version of the module. Another Sitecore community member reached out, about release notes from the fix and code availability on GitHub as they had to abandon their use of the module during that initial bug duration. Honestly after the fix, Jamie and I never reopened the conversation about posting source. Early this month, we finally got together to quickly discuss the future of the source for the module. We decided not to share the source code, let me explain why we quickly came to this decision in a world that almost entirely demands that developers do so.
1. Simplicity of the module doesn’t warrant it. Actually it is so simple I would hope Sitecore grabs it and just implements it in a future release. It took longer for us to talk about approach and potential execution than it took to actually code the thing. We wanted to make it seem Sitecore already had it in place when installed. Typically I wouldn’t care about sharing a small amount of source code except for reason #2.
2. Managing the demands for pull request changes with limited time. I think in this case if the codebase was larger this might be time well spent, however because the code base was so small, it came down to the scale of efficiency for us to manage this module in our own time, versus managing our time around submissions.
3. Time is limited. I think it is safe to assume everyone is busy – Jamie and I aren’t an exception to that state of being. In fact I don’t think I’ve been busier in all aspects of my life than the past year. One thing I’ve had to do with my interactions (both my technical life and non-technical life) is literally drop things that just don’t have substance for the immediate time. I know while I would want to dedicate time to manage requests, much like the commitment I have in other aspects, the reality is I don’t gain much managing change requests with tight turnarounds as I do planning releases and allocating the appropriate time to accomplish those goals. If this wasn’t a pet project and more of an official offering from a company that we were running – that of course would be much different. However, it isn’t and the act of collecting feedback and determining if fixes or enhancements are needed for a future release works best for us and ultimately the majority of the community.
4. No matter how many contributors to the source, we eventually would have to manage it. For me, again it is easier to manage ideas and suggestions, than to manage source submissions and quality checks around them.
Not a popular decision that we made, but we think it works best for us in this case. So what do we lose by doing this, some really good stuff.
1. That bug those two guys had found, had this been open source, might have been caught quicker and a fix proposed before we even had the chance to review it ourselves. In fact this could have been corrected in early April versus late April when the second report came in.
2. Could there be a better way to do the same thing? I’m sure there is and everyone would have an opinion. Open forum overall I believe is good, and if we had something under our care such as Synthesis or Sitecore.FakeDB I would argue that sharing the source would be critical to the success of the module.
3. The potential to work with folks on something we normally wouldn’t get to work with. I love to collaborate with other Sitecore people. Mainly that is why I do the podcast – it gives me that brief forum to discuss topics with other people that normally might be frowned upon from past employers – especially those previous to my days working with Sitecore.
4. Recognition of work done. Don’t get me wrong, I like a pat on the back as much as the next person – but it isn’t why I do what I do by any stretch of the imagination. This one doesn’t hold weight with me so much. I can live without it. There are some guys in the community (Mike Edwards/Glass, Adam Najmanowicz-Michael West-Mike Reynolds/Sitecore PowerShell, and so many more) that have this recognition and do what they do because they care, can support the effort they are putting in, and can capitalize on the efficiency gained by social coding. I don’t think they do it for the recognition either.
So again, at this time we have decided not to release the source code. I truly do hope this does make sense to everyone whom has shared concern about it.