Wednesday, August 22, 2007

Open Market for Software Development

Today, we had an interesting discussion in the RiSE group involving a draft proposal by David Weiss related to an Open Market Software Development (OMSD). David has a long experience with software development and his proposal is at least polemic. David proposes a new approach to software development called OMSD in order to be an attempt to free software developers from restrictions under which they work by allowing them to work on what they choose and with whom they choose. His approach is inspired – it is very good for us – by Ricardo Semler a Brazilian executive with innovative ideas in which our managers must read more.

In David’s approach, he discusses some rules for development in the market, roles, metrics, etc. However, during the discussion, some topics were strongly questioned [sometimes in a funny way] such as: 1. the approach is just related to software product line in which we have a well-defined architecture? If yes, it can be a problem in an open market in which not often we (developers) have all the background in that domain. 2. the guys questioned the analogy made with the Personal Computer area. 3. the relationship between the company publishing the specification and the available developers should be very defined since the developers cannot do their work or disappear, etc. So, maybe, we have to define more legal aspects in the model. Maybe, some NDAs can solve it. But, it should be well-defined. 4. Often when I discuss this model, the people – managers – asked me about the business model and the economic aspects. It is not easy to define a rigorous analysis for this approach since we do not have data about it. However, David has a strong background in the measurement area (he created the GQM) and I think that he is thinking in this direction.

In general, I think that this approach can be more discussed and maybe experimented in our environment, Digital Port, where we have a rich ecosystem composed of universities, companies, and especially, very good professionals. I believe that this approach can be a way to integrate more these parts and maybe contributes to increase our potential to enter in international markets.

Unfortunately, we cannot publish David’s paper here, however, you can see his talk during the 2nd Workshop for Reuse Introduction in Companies (WIRE).


Vinicius Garcia said...

Eduardo forgot to mention that this photo is of the "Mercado Modelo", a kind of "open market" for craftsmen and all type of souvenirs and typical foods of Bahia. Located in the Cidade Baixa, Salvador, bathed for the bay of Todos os Santos.

David said...

For OMSD to work, one must have a well-defined architecture, especially there must be a set of components with well-defined interfaces and known dependencies among the components. (Of course, I think of each component as an information hiding module with an abstract interface specification.)
Note that open source development uses the same idea, i.e., there is an architecture, which is enforced by a few good architects, and there are component developers/maintainers.
The business model is similar to the publishing world, i.e., it is in everyone's interest to produce products that will sell. Those who contribute to that goal share in the revenues of the products. No revenues, no payments. Poor quality, no payments.
The analogy with the PC world is simimlar to the way that new USB devices are developed. they all obey the same USB interface. Of course, the payment part is different - I don't think that flash memory builders or disk drive builders get royalites based on the number of drives sold.

Fred Durao said...

Hello David, I would like to know how connected components are to architecture. In case of high coupling, they may require private information that perhaps put project confidentiality in risk. What do you think about?

Camilo said...

IMO, the need of well-defined architectures shifts OMSD model to be applied only for less valuable tasks (coding, testing) of software development - as important aspects (performance, scalability, decoupling, ...) shall be resolved in architecture design phase.
Maybe OMSD itself could be used to define software architecture...

Thiago Burgos said...

I have some points about the work :)

1 - Fisrt of them, it seems that this work is based on some approaches that may not be so mature yet, like SPL and CBD. Even though these approaches are used in practice by some companies, and are starting to be known by industry, some points of its implementation are still maturing. So, the first impression is that is approach is a futuristic idea, but its (of-course) reachable (we know companies like odesk that goes towards some of the concepts that you are proposing).

2 - David, Whats the difference between this new approach you are proposing, and the sub-contraction model already know by industry for a long time? The main difference we could notice was the granurality of it (well defined components, to plug in well defined architectures), and the revenue share (that has to be very well defined and organized, so it can not be a negative factor to the work flow of a certain subcontracted).

I guess that's it.David, new ideas like yours are always valid, so we can open our minds :)


Eduardo Cruz said...

I think this model will serve to guide the market that we already have these days.

For example, ODESK ( a open market initiative, call itself (The On Demand Global Workforce). They already have more than 19.000 service providers, who are developers, managers, DBAs, designers with earnings of about 3 million dollars in the last 3 months.

To scale and achieve bigger contracts, this market will need more detailed models.

Ricardo Cavalcanti said...

Most problems that could arise from the proposed model would be basically peopleware. IMO, a successful try would come first from inside a company, as I believe that time-to-market constraints can only be achieved in a extremely mature environment.
I found interesting how David joined the Organizational Behavior methodology with SW-Engineering, especially the payment model, which I found very good, but I think the royalties and rewards should´t be based on LOC changed, but in revenue, benefits. If one can measure the expected benefits of a component, he could also know the expected revenue of a newer version. Older version´s developer could earn a declining % from each newer version...
I also missed some kind of partnership process. Something that would make me trust more in someone that has already built something for me, instead of sticking always with the cheaper. (At this point I would recall Jeffrey Liker's Toyota Way and its 11th principle: Respect your extended network of partners and suppliers...)