When we were commercial software things we're, quite frankly, easier in a lot of ways. We had a few dozen clients we had active relationships with, and we worked on about half a dozen projects at a time. In those days it was pretty easy to try out a new idea with the CMS because we would simply put it on the latest clients setup and see what happened. We didn't really worry too much about keeping everyone on the latest version of the platform, and subsequently we didn't have to spend a lot of time worried about backwards compatibility.

We also didn't see a tremendous amount of intentional abuse of our systems. While we did build some large, active, and successful sites, the code behind them was only open to people who had worked with us in the past. To break one of our sites in the commercial days, you'd simply have to guess at vulnerabilities instead of being able to scour code for them first.

Now things have changed. Every feature idea we have is more and more tempered by "what will this do to existing sites or old versions." We've learned about (and quickly addressed) any number of vulnerabilities that some guy in his basement found for free – when paid consultants had found none for five years before. You quickly learn that even the most well intentioned work can cause havoc.

For example, there are two blocks in concrete5 that are commonly used to build navigations: the Auto-Nav block and the Page List block. The Auto-Nav block had been built to honor a certain variable you can set at a page level to hide that page from the navigation. The Page List did not honor the same attribute, and someone from the community pointed out that it really would make more sense if it did. We agreed and "fixed" it as part of some other version changes. Weeks later, people started complaining that their sites we're missing pages. After some frustration we realized "duh" of course people had built sites that worked around the way the blocks behaved in the past and the simple "fix" to the Page List block actually broke their sites.

We spend a lot of our time trying to manage issues that could mature like this now. I tend to take much longer to release something than I used to. I tend to be more thoughtful about the reasons and needs behind any feature changes. The temptation to "fix" something that could have been better implemented in the first place is very strong. Learning to first resist and then very delicately architect not necessarily the perfect, but rather the lowest impact solution, has been a new adventure for me. Once you go open source it is safe to assume that someone somewhere who is smarter than you and has all the time in the world, is finding the mistakes, finding the holes, and making up their own weird work-arounds which will impact you later. Be careful what you touch because no good deed goes unpunished.