Adopting an Internal Development Commons Approach to Software Development

[#1]

Traditionally, within large software houses, products are developed by siloed teams and released once their development cycle is complete. In an organization like EDS, where applications are developed for and on behalf of our clients, there will typically be multiple developments going on at any one time for a very wide range of clients, making it difficult to create reusable products as development is tied to a single implementation.

By adopting an internal Creative Commons approach, it would be possible to solve many of the problems that the siloed, sequential development approaches create for the sharing of information prior the deployment of the first customer instance. This would allow companies to obtain many of the long-tail benefits of Open Source while retaining corporate control of IP and applications by limiting the scope of the Commons to employees.

In a Nutshell the open development model is as follows:

• A community of developers and other interested groups,
• Sharing a code commons,
• Creating "intellectual wealth" from the commons and
• Enriching the commons in the process

Or to put it another way, the "medieval craft guilds" rediscovered. Creating an open development model which allows for the concurrent support of different agendas and approaches in requirements gathering and development; in contrast to more centralized models of development such as those typically used to create customer applications.

The basic philosophical belief behind this approach is similar to the open source model thus, for "work in progress" the idea is to develop a collaborative community of interest based development community who can all work on and add to a shared solution. When many developers can read, redistribute, and modify the specifications/source code for a solution (software or hardware), the solution evolves. People improve it, people adapt it, people fix bugs. At a greater speed than, if one is used to the slow pace of conventional development, traditionally achieved.

This approach allows staff to gain visibility to and work on application initiatives earlier in the lifecycle. Additionally this model would allow account specific derivative works to be created based on "works in progress". This type of collaborative working therefore also starts to solve the problem in the current environment of how much "tailoring" to a standard solution is accepted before it becomes a new solution or offering.

This approach, and other lessons from the open source world, can be applied to counter the effects of the dominant and increasingly restrictive permission culture pervading traditional application development methodologies; a culture pressed hard upon customers by traditionally siloed content distributors.

"The best ideas are common property"

[#2]

Mateen, since this work is done for others, doesn't the 'Creative Commons' have to be open source.

I suppose the 'Creative Commons' licensing model would work, but won't the customer want some mechanism to receive updates... Then you are either supporting a product, or diving into the open source pool? What kind of bureaucratic mechanism will this require? and is it worth the effort??

[#3]

You'll also have to be careful to make sure someone doesn't check in a change that's perfect for his/her own project, but breaks 18 other projects relying on the same source.  One project's improvement might be another project's nightmare.  This problem can be reduced by treating the shared source as a starting point only, with not just anyone making changes to it, but then, you've also reduced the benefits going forward.  Or, you could put people in charge of performing strict reviews of all changes, sending out broadcast messages asking if particular features would be beneficial to all or should be isolated to a specific project, and so on, but then the question becomes if these people are able to reduce enough duplicate effort to pay for their own overhead.

[#4]

I agree with both these comments, customers will want a method for obtaining updates and there will need to be enough control of the product to ensure it doesn't get changed beyond all recognition. Typically this means that each product has an owner who revies changes and accepts them. Is it worth the effort? I believe if you want a product that evloves and changes over time then yes it can be worthwhile to adopt this approach.