What I've always found intriguing and impressive with KDE's evolution is that as a community we have managed to find a good blend between openness, decentralization, oversight, corporate involvement, entrepreneurship, community, fun and seriousness. We have a fine balance between the community and the corporate, the adventurism and the professionalism. This has been achieved by keeping a shared alignment of our incentives and goals, regardless of who we are and why we are individually here. Such a balancing act of unity is not common in communities of our size.
Of course, success is often rewarded with challenges that spring up along the way, and the growth and rise of economic interests within and around KDE has brought with it new challenges for us to deal with. I have noticed three potential rift creators becoming more common and it would probably be good to discuss them openly as a community. By paying attention to these issues we can smooth off the rough edges and keep our unity intact for many more years to come.
What are these three fault line producers? In no particular order:
- Time line mismatches
- Differentiation pressures
- Confidentiality requirements
I don't want to discuss possible solutions in this blog entry, but rather just outline what these challenges often look like.
Time Line Mismatches
When a large number of diverse interests come together, each with their own release requirements, market goals and deadlines it becomes inevitable that time lines will not match up across every single participant in the community.
While perfect cadence would be lovely, reality is that different kinds of software and different business interests will have different requirements when it comes to time lines. We have a terrific melange of upstream projects, contract software developers who are beholden to client time lines, device manufacturers tracking the cycles of their target markets, operating systems vendors and deployment specialists that all have time lines that follow unique demands. It is natural that they all want, or even need, to see features land, stabilization goals met, etc according to their time lines.
Sometimes development is rushed forward or held back due to time lines being at odds with other. The question here is how best to accommodate differing time lines as best we can.
It's either that or figure out how to magically fix the world so everyone's deadlines fall on the same day. ;)
When it comes to monetizing and commercializing a F/OSS product, there is often the desire to offer differentiation through features or behavior in the software. This can lead to forking the software to various degrees or reinventing / replacing components or entire stacks.
There is no singular root cause for this, however, which makes it a really interesting issue. Sometimes the differentiation pressure comes from operating in an overly competitive space, sometimes from being in a market that has unique pressures or requirements and other times it comes from the desire to build brand identity. This leads to a situation where sometimes the differentiation is rather frivolous and other times more substantial and the result of a hard requirement.
The worst thing that can happen in all of this is that efforts get lost. Open source as a methodology has some inefficiencies baked into it compared to other methods, but it is made up for due to many people working together (lowering costs and increasing utility) and various results that come from freedom (such as consumer confidence in longevity or availability). When efforts become divided due to unreconciled efforts motivated by differentiation, some of that advantage is lost.
Finding ways to avoid unnecessary and gracefully accommodate necessary differentiation efforts is important to keep our efforts efficient and our community bound together as a whole rather than splinters.
Right now I'm working on a couple of projects for which I've signed NDAs (non-disclosure agreements) with partner companies. In other cases, I've simply given my gentleman's word of honor to keep information under wraps. At the same time, I'm as open as possible about what I'm working on particularly when it touches projects I share with others, such as the Plasma Netbook initiative. Such confidentiality is very common, both amongst open source projects in incubation and (even more so) in corporate projects.
Privacy in projects isn't always an evil thing: sometimes a business deal isn't complete and nothing can be said until such time as it is. Sometimes confidentiality is actually not needed or not worth it given the impact on the health of the community.
The biggest risk in confidentiality is that it creates schisms between people in the same project or community and can easily lead to retrograde patterns such as different groups working at odds to each other without even knowing they are. Being able to identify when and where confidentiality is sensible or not and how to encourage and preserve an "openness first" mentality will remain a vital endeavor in keeping our communities well-formed and the process efficiency high.
Lions, Tigers and Bears!
Fortunately the three issues of time line conflicts, differentiation pressures and confidentiality requirements don't come up often in our community with negative results. However, as KDE continues towards greater scope and sophistication, an increasing incidence of these three patterns can be expected.
It is therefore a good time to discuss and determine our shared expectations openly together. So while I don't want to cause people to run around fearing the sky is falling in (it's not even close to doing so :), we may want to pause and share our thoughts on these things.
Over the next few weeks I'll be putting together some of my thoughts on possible approaches for each of the three issues, and I'm looking forward to hearing your thoughts and ideas on them as well. :)