Friday, August 16, 2013

The Economics of Open Source Software




Picture this:
You walk into a restaurant, take your pick from the menu, and enjoy a nice meal. When it comes to paying the bill, you are billed less than 30% than usual and what’s more you are provided all the secret recipes & instructions for preparing the cuisine back home. While your head is reeling wondering if this were a dream, you are told that the food you just ate was prepared by chefs’ free-of-charge :-)

It has baffled me as to how the very premise of ‘software product’ business vis-à-vis ‘source code’ is made available ‘for all’ and how there is an ever increasing number of individuals & corporations ready to devote time & energy to build and share ‘source code’ ‘free of cost’. This article is an attempt to understand how the ‘Open Source’ software philosophy has evolved and what motivates individuals & corporations to embrace ‘Open Source’ in various forms (read as different licensing  models).

Today almost all large & medium software corporations have a ’play’ in the ‘Open Source’ community in some form. It is interesting note how even Microsoft (predominantly ‘EULA’-based product business model) have been compelled to go ‘Open’.

In a nut-shell how do ‘Open Source’ products/companies generate revenue?
·       Providing integration, hosting & support services (Acquia)
·       Selling subscriptions to updates and support (Red Hat)
·       Embed the software in hardware/products (Android)
·       Offer free software & services online, earn thru advertising (Google)
·       Selling proprietary components to segments of the user base (Funambol)
·       Selling premium plug-ins, applications, services and themes (WordPress)
·       Selling the software under a commercial license and releasing the code under an open source license simultaneously, aka Dual licensing (MySQL).

How Open Source Communities have evolved to become the source of new ‘game changing’ technologies & products?
It is no secret that some of the greatest ‘foundational’ technologies were conceived in academic & research institutions (MIT, Berkley, AT&T Bell Labs …). Environments such as these with low or no presence of revenue & time pressures have often known to bring out the best new & radical ideas key for innovation. With no concerns towards ‘ownership/credit’, ‘appraisal ratings’ is known to naturally foster true ‘team’/’community’ spirit resulting in better collaboration.
Extending this theory to the World of today with a developer community of several thousands and the power to share & interact over the internet, it is only natural that ‘Open Source’ model has evolved allowing individuals to collaborate (without inhibitions) and not surprisingly being the source of most new disruptive technologies & concepts.


The motivation for embracing ‘Open Source’: 
For individuals:
  • The excitement of being part of something new & cool.

  • Opportunity to contribute to popularly known Open Source products and build an ‘internet identity’ for oneself.

  • Possibility of gaining new skills & knowledge for better career options.

For Corporations:
  • A ‘time tested’ platform to build further upon and create differentiators in the space.
Eg: Hadoop is increasingly becoming the platform of choice for corporations to develop BigData solutions, while building the same from scratch would be lot more expensive & risky (what if it fails?).

  • A pool of skilled resources (Open Source Community) who are ready to help in the development process and offer technical advice/inputs at no extra charge/cost.


  • Influencing key ‘Open Source’ platform design decisions with the possibility of long term benefits for the company.

With the increasing ‘commoditization’ of software, it is a reality today that Open Source Model offers an entire Eco-system critical for individuals & corporations to contribute, build upon and offer ‘differentiators’ for their customers.

Note: If you liked this article, please do spare a few minutes to share your feedback/thoughts. Thank-you!

Sunday, August 4, 2013

Understanding OData (and its potential in the fast changing technology World)




This article primarily is an effort to understand the ‘problem’ and the technology that is making an effort to address this – OData aka 'Open Data Protocol'. The sole purpose of this article is to provide an overview on ‘OData’ offers links for further reading.

The Problem:
As one might imagine, in today’s world we have an increasing amount of data, different sources of data on the one hand and an increasing demand to be able to view the data through various means(browser, application, mobile devices) on the other. Increasingly businesses are also looking for easier means to combine data from various sources for analytics and market research.

The problem is not new, it is just that with businesses fast adopting to the ‘social’ model of influencing, marketing and doing business, this is becoming an important use case for most data driven application/product. The need is for a ‘standard’/’mechanism’ that is well accepted to ‘expose’ your data in a way that it can be easily be consumed by various data consumers, devices & tools.

One might ponder on the ‘classic’ web services model that provides a industry accepted model to expose data allowing consumers to consume/process/view the data. However, this does have some obvious drawbacks:
1)    Each source of data might expose data in its own custom format or web services.
2)    Also, often the data ‘sources’/’publishers’ may not have visibility/foresight on the slice & dice of data that the data ‘consumers’/’viewers’ may want. This could result in additional challenges of multiple calls to get the desired data.

All that’s needed is an agreement on a way to model data and a protocol for accessing that data. This is exactly what is defined by OData.

What is OData?
  • The OData protocol is based on REST; at bottom, it's just HTTP.
  • OData defines an abstract data model (EDM – same concept as defined by the ‘Microsoft Entity Framework’) and a protocol that lets any client access information exposed by any data source.
  • The fundamental idea is that any OData client can access any OData data source. Rather than creating unique ways to expose and access data, data sources and their clients can instead rely on the single solution that OData provides.

The below figure shows how ‘client’ (data consumers) can use ‘OData libraries’ to access data exposed from various ‘data sources’ (that expose data in the form of OData services). The ‘common’ rules for exposing & accessing of data now makes it possible to combine data to an extent that would otherwise be lot more challenging to achieve.

OData is part of an ‘Open’ specification primarily driven by Microsoft and others. Ref: OData


Figure1: (Taken from MSDN)


Potential (for rapid adoption):
1)    The OData protocol provides a means to define the data format for serialization (data on the wire) as either Atom/AtomPub or JSON. The latter (JSON) has greater industry acceptance  due to:
a.     Data interchange format for JavaScript
b.     JSON becoming the language of the web
c.     Becoming predominant technology leveraged by NoSQL document stores
2)    OData defines powerful easy-to-understand URI constructs allowing access to various dimensions of the data exposed through an OData Services.
3)    On the Microsoft technology side, you can quickly build an OData service and client applications using WCF service & client application. A quick reference can be found here.

References:

Tuesday, July 30, 2013

Agile – Impediments to successful execution




For the last several years I have had the privilege to be part of several projects executed in ‘Agile’ during which I have held various roles including, as a team member, technical  lead/architect and overall responsible manager. While there are plenty of articles already on the web that openly praise or abhor the methodology, this article intends to highlight my individual experiences and provides a quick primer to understand the key factors which could be detrimental to the success of ‘Agile’ in any particular project.

Top impediments for ‘Agile’:

  1. Lack of separate internal team organization for new-development: 
This is the #1 ‘real’ problem in any enterprise organization with work being either around ‘new’ feature/enhancements versus addressing ‘production issues’ or customer escalations. For ‘Agile’ to succeed you first need to have a well defined team that purely focuses on ‘new’ development and never mix the two.



  1. All teams need to go ‘Agile’ or none at all: 
All impacted teams need to be part of the ‘Scrum’, typically Development, FVT (QA), Documentation. Any deviation would mean it effectively would result in plain ‘Iterative’ development and that is NOT Agile.



  1. Not-so-‘Agile’ change-management/approval processes: 
Any fairly large enterprise product is bound to have ‘traditional/time consuming’ approval processes for any ‘change’ in the ‘product backlog’/‘committed feature set’. When the expectation with ‘Agile’ is to have a ‘consumable product’ in short  time-bound iterations (~4 weeks), it is critical for change-management to go the ‘Agile’ route too! Going 'agile' also requires an entire organization to change their business processes.



  1. Purely ‘go-by-the-book’ for ‘Agile’: 
Agile only defines a bare-bone framework but leaves enough room to customize the ‘rules from the book’ to suite your specific project needs. While the book might recommend sprints of 3-4 weeks, you might have a need for slightly longer sprints (~6 weeks) especially towards the beginning of the project. It is understood that ‘daily stand-ups’ need to be short face-to-face daily meeting, you might be pressed to have it over phone (as teams are very rarely co-located) and have it may be 3 times in a week.



  1. Not breaking tasks to small enough sub-tasks: 
Features should not be built in a single sprint or iteration. Instead, features should be evolved and grow over time. A feature should start out small and develop and evolve over time as feedback is received and customers or the product owner tries it out.



  1. Product Owner is Consistently Unavailable: 
Product owners not passionately engaged in the agile adoption hold the software development team hostage until the expected benefits have been delivered. An unavailable product owner perpetuates the wait time and creates waste, which is a problem that more traditional approaches are known for.



  1. Reduced focus on ‘overall’ architecture: 
‘Agile’ is often mis-construed to mean ‘start coding’. As stated in point (4), scrum allows for enough scope to customize as per specific project needs. One recommendation is to have a sprint zero to focus on overall architecture and create user-stories for such non-functional requirements.



  1. Insufficient focus on retrospective and customer feedback: 
Gaining periodic customer feedback of working software is an important aspect of agile development, because it ensures that you are constructing a valuable solution for the customer. Without customer validation, you are not really applying agile; you are just doing a form of iterative development without aligning your work with the customer’s need.

Predictive Analytics ....... what next?

I have often pondered on this question, wondering what could possibly be the next big quantum leap in the real of data and data centric de...