From email to wikis, to group collaboration, to customer relationship management, to email marketing to ad placement, to event registration, the future of software is hosted. The most promising business model for the the internet is to build software as a service, where users/companies pay a subscription fee (or watch ads) for access to unique functionality through a website. The winners in hosted software have also been providing access to user's data and functionality through Application programming interfaces (APIs). Why?
- Because APIs allow programmers/users to aggregate the pieces of their digital lifestyle. (DLA). In other words, because APIs will allow the creation of the Peopleweb or the WebOS (II) or Web 2.0.
- Because APIs allow programmers to build cool things on top of other cool things.
APIs obviate the need for programmers to re-architect the data layer (or even functionality layer) to make incremental improvements and relaunch clones. - Because APIs allow users to have control of their data and move it to another service at will.
For these very reasons, the software as a service business is also hyper-competitive. It requires a constant need for innovation and differentiation, an accelerated cycle of development of new features that address the needs of new markets and new users.
So, if software as a service is the future, and startups are beginning to embrace it and even cash out because of it...
Then, how does a startup launch a company that successfully embraces it? What are the challenges? How can a small company compete with a small amount of resources against large established players?
Can leveraging a form of open source development be the way for startups to compete? Can startups play the roles of:
- Architecting, commissioning, funding (or fund-raising) and managing open source developement projects.
- Leverage pieces of open source development and integrate these applications into software packages that address a customer need?
- Charging subscription or consulting fees to companies that want to leverage the platform for their own branded environment.
If this is a viable path, how can a startup make it happen?
For a start, there's a great thread on Mitch Kapor's weblog about how startups are leveraging and contributing to open source initiatives to build socially-minded for-profit businesses.
The whole topic of open source development by for-profit companies is very intriuging to me, right now, as we determine how to best develop enhancements for our hosted software service for event planners.
There are two themes going on in the conversation on Mitch's weblog.
1. How for-profit companies are leveraging open-source projects.
2. How [some of] these companies give back to the world-community in many different ways, besides re-releasing their proprietary code.
Here are a bunch of examples of companies that are leveraging open-source development. (Note: I added the links in the blockquotes below.)
Mitch Kapor cites:
Better examples of companies building business models around open source include mySQL, Sleepycat (Berkeley DB), and Sendmail. And then there are new companies like divmod (web mail and calendar), whose server code is open.
Socialtext is a hybrid open source business model, similar to MySQL. We adopted and make significant contributions to Kwiki. We re-architected our hosted service and appliance offerings on top of the Kwiki core and they share the same plugin architecture. We foster choice and often turn customers towards the open source option when its a better fit. This model simply makes better strategic sense and will prove itself out in the long run.
You don't have to be a software developer to "embrac[e] the open source model." Google, Yahoo and Amazon have all built proprietary advantages.
Marc Canter has also been talking about the strengths and weaknesses of open source development, as he was building up the launch of ourmedia.org, here:
This is the great fallacy of open source code. That it's done ONLY by free, contributory work. From what I see - it's a balance between free and paid work that produces open source code. Which means that the owners are not just the 'people' and that each project has it's own unique balance and definition of open source code.
I also see that Ash Maurya of WiredReach is weighing the value of open-sourcing proprietary products vs the risk:
From the outside, re-releasing existing commercial products (like Sun and Lazlo are doing) under an open source license seems like the ultimate plunge.
I also know a handful of other entrepreneurs that are weighing the release of some code that they have under development, hoping that it'll stir innovation in the UI and integration with other systems.
So, how does a company go about leveraging open-source development? I am asking and I don't necessarily have an answer. So, I'd appreciate a bit more history behind how these companies leverage open source. Or anyone's take on the subject.
Chicken or Egg? What comes first: Open Source Project or For-Profit Company?
From Ross's statement, it sounds like kwiki came before SocialText. If I was a guessing guy, I'd assume that most open source projects came before the for-profit companies in many cases. Are there any examples where a for-profit company was able to initiate an open source project? If so, how did they initiate it?
Creating APIs is Good. Build it and They Will come. Delicious, flickr, Amazon, Ebay, yahoo, google, etc, etc..
It seems the newest way to embrace Open-Source development is by developing an API. Even businessweek is covering it. The idea is to expose methods to let programmers see how your programs work. Then, if the data and functionality provided through the API is cool (or profitable) enough, programmers will use their creative energy and coding sweat to develop cool new applications on top of data or find creative ways to combine data and functionality with other systems.
Obviously, Amazon's API which integrates into its affiliate program has put its buy now button all over the web. Many developers have built awesome applications and websites on top of their catalog of products and prices. Google has API's for search and now for adwords. The whole business idea of Flickr is based on APIs. Feedster and technorati have cool contests to see who can build cool applications on top of their API.
We've developed some APIs because people requested to be able to add subscribers to their mailing lists from their website, and be able to do it when the person registers for a forum or for some other reason. We'd like to develop more web services so that people could access and contribute-to our database of event information through API calls. (Something upcoming.org recently announced they'd be doing.) I get giggly when I think about the cool things that people could build off of that.
Using APIs is Better.
We are also building a more advanced email marketing application on top of another company's API. It has helped us develop a very robust application in a significantly shorter amount of time than if we developed it ourselves. And we've been talking to Gregory Narain about integrating some fancy group-forming and community-building functionality that he has developed into our application through his API. As well as to a ticketing company about integrating their ticketing capabilities through their API. If these things pan out, they could add significant capabilities to our offerings with significantly reduced development muscle.
Why does this reduce a lot of time and effort for us? There are reasons beyond the fact that the code has been written. In all three of these cases, use cases have been established and technical specifications developed. A lot of the work in identifying a need and architecting a solution has already been done. In other words, the product management has been done already. And with any software project, that is harder than writing code.
In the case of the newsletter and ticketing APIs, they have systems built on top of them already that are already servicing customers. In these cases, we are adding functionality to our suite of tools that has been developed and commercially proven. So, this has to be the fastest way to develop a new service.
Components Rock
We have also integrated a bunch of components into our application. RichTextBoxControl, DatePicker. I absolutely am in love with Telerik's Rad Designer, which is a .NET component that allows users to drag and drop content and functionality blocks into a layout through a browser. Unfortunately, there aren't components developed that solve all of our programming needs.
So how do we recruit programmers to develop new ideas that we have where we've identified a need or an opportunity and know we can commercialize it?
Or more concisely..
How do we really leverage open source development to grow our for-profit business?
We obviously have in-house development capabilities. But, we have also started outsourcing some development to a firm in India. Yes, even startups outsource. Going forward, this is obviously a cost effective way to do development. Our main strength is identifying event planners needs and problems, dreaming up how to solve those problems and meet those needs, as well as dreaming up solutions that improve the efficiency of the whole process of event planning and marketing. So, whenever we decide to develop a new feature, we document it, ask our customers whether it will be useful, develop a technical specification and determine who will be developing it. The first questions we ask ourselves are:
Is there an open source component we could use?
Is there a component that we could purchase already built that we can plug in?
Is there another company with an API that we could leverage?
Or do we have to develop it from scratch?
When we have to develop it from scratch, then we have to weigh our priorities and determine what resources (cash and time) we will use to get it done. I'd like to have another method at our disposal that leverages open source development to get the things that don't get to the top of our priority list - done in a quicker fashion. Although APIs and components are a step in the direction of leveraging what other people have already developed, there are other things that we'd like to develop that have no APIs. And releasing our data through an API wouldn't necessarily spawn them. We could hold competitions and contests like feedster and technorati. But, those contests develop what other programmers think could be useful. Not the things that we've identified that we need to develop to meet our customers needs or grow our business in the direction we want to grow it.
Additionally, many of the projects spawned off of other's API's are launched by developers as other sites or projects. Take for example, the seemingly hundreds of tools that have been built on top of delicious. This doesn't necessarily work for us because we want to integrate new functionality into the site to address our core customer: event planners. (Sidenote: Have any of these companies with open APIs actually bought the source code from a developer that developed something on top of their API?)
For certain things that we want to develop, we'd be interested in leaving it out there as open source code. Meanwhile, we will integrate it into our application and focus on bundling all of these services, selling them, and servicing the customer. The average event planner doesn't think to call a programmer to solve their problems. Writing code is not our strategic advantage. Bundling the code to address the needs of our customers is.
Before Marc Canter launched ourmedia.org. he blogged about the problems with relying on open-source code development and volunteers to create a product.
Marc and I are attacking similar issues from different
approaches: He is running a consulting company that consults to for-profit companies regarding tapping open source development and APIs. We are building a hosted solution, that until now has relied mostly on components, our own development and other people's APIs. If I had the money, I would hire Marc to help us. Marc says:
This is the great falacy of open source code. That it's done ONLY by free, contributry work. From what I see - it's a balance between free and paid work that produces open source code. Which means that the owners are not just the 'people' and that each project has it's own unique balance and definition of open source code.
Certainly MySQL is different than Flickr or WebJay. Are they different because you can't get the SOURCE of Flickr or even Amazon - or are they're NOT open source - even though their APIs are?
I believe that Tim O'Reilly defines Amazon or Flickr as open source - even though they don't share their source. Brewster Kahle and the Internet Archove provide free hosting and bandwidth - though their open source code is something else - entirely.
I was hoping to get this debate out into the open at Etech, but instead we'll be hearing from the usual on suspects on the latest shell scripts. Hopefullt some sort of BoD will happen.
ourmedia.org WILL share it's source - which is based upon a GPL license - based upon Drupal. So ANYBODY can build their own unique version of ourmedia.org. They can fork the code, but god forbid if they fork the APIs.
JD and I are debating the difference between sponsors and partners of ourmedia.org right now, but what more interests me is "what is open source?" Are accesible APIs and open schemas enough to call something open source?
Are open discussions and the free marketplace enough to call something open, 'cause there's one thing I CAN tell yah - "code don't get written by consensus or democracy."
Agreed, Marc.
So, how can for profit companies or consultants that are consulting to for-profit companies better manage this development process?
I've been writing this post for about two months now. I planned to release it with the launch of a new project to tap open source. But, I am not sure when that will be. And yesterday, I ran accross this project, which is basically what I was going to try.
Basically, what I wanted to try was to pool resources together to fund development. As Marc says, open source development doesn't just happen. To direct it, it needs to be managed. It needs quality developers. It needs people to test it. etc, etc.
So, what I'd like to experiment with, is pooling the resources of startups, for-profit companies and individuals in order to develop specific software projects. There are issues and opportunities that we are not addressing because of resource constraints in my company. And these are some of the same issues that other companies and startups are facing. So, why not each contribute a few hundred or thousand dollars to a project to get it done. And then share the code. Here's how I propose that this works:
- One company drafts a software concept.
- This company also determines the budget required to develop the concept, the number of partners that they'd like to be involved, the open-source license that they'd like to use (or how they'd like to share the code with parties involved).
- They invite other companies to view the concept and the terms. If said company is willing to participate, they identify how.
- A full specification is developed and agreed upon. Final agreement from all commissioning parties is achieved.
- A company/group of developers is assigned to write the software.
- All test the software.
- Software is distributed how it was agreed upon.
Some of the things that are on our short list to be developed that we'd consider using this process to develop are:
- Doing web design through a browser. An asp.net tool that enables a user to select layouts, color schemes, formatting and then drag and drop content/functionality blocks onto a page and design a web page's layout.
- A javascript based calendar similar to yahoo calendar or trumba, which consumes an rss feed of events, so it can be launched on a third party (ie your) website.
- An asp.net tool that consumes flickr photos and assembles them into a fancy photo album.
- An asp.net aggregator that leverages technorati's API and aggregates blog posts pointing to a specific link. (We'd use it to aggregate what people are saying about specific events.)
The End.
it's a very informative post, well here is lots of guidance also some resources for breast enhancement, well i also observed that this blog is quite active, people are keep doing discussion for their problems.
Posted by: Breast Enhancement | June 09, 2009 at 07:14 AM
wow! thanks for sharing this informative post! i don't really trust an Open source because there a lot of disadvantages for using an Open Source but we'll see.
Posted by: Nursing tops | April 26, 2010 at 02:29 AM
I am looking to model in the high fashion industry. I am planning on going on America's Next Top Model but I am wondering if it would be possible to go to college before I begin my career. I know that the career doesn't last forever and that is why I would like to go to college so that way I could get another job once I am too old to model. If you could tell me how long a modeling career lasts in the high fashion industry. Any additional information would be appreciated. Thank you.
Posted by: cheap kamagra | April 26, 2010 at 12:43 PM
Take for example, the seemingly hundreds of tools that have been built on top of delicious
Posted by: fertileaid views | May 10, 2010 at 02:28 AM
Hey ... I had to stop at this site to say that this incredibly informed about one of the sweetest instruments and subtlety of the music as the guitar, just amazing, thanks for improving my life with this information, because as they say around ... . never stop learning to play guitar.
Posted by: guanacaste costa rica | July 14, 2010 at 11:04 PM
wow! thanks for sharing this informative post! i don't really trust an Open source because there a lot of disadvantages for using an Open Source but we'll see.
Posted by: cna classes michigan | July 15, 2010 at 08:59 AM
You can read more about our overland journey through Africa and Europe on my new blog, huku na huko. If you understand Danish, you might also want to check out Omveje I Afrika, my blog on Politiken online.
Thank you to all who visited, read, commented, asked, suggested, criticized, ridiculed and encouraged. It was all appreciated. Hopefully we’ll meet again on my new blog.
Tutaonana,
Jesp
Posted by: cna classes michigan | July 15, 2010 at 09:02 AM
Lovely stuff, and I agree about 'you just can't stop' as the one to have, although I have never been able to cope with this name nonsense, so far as I'm concerned they'll always just be 'The Beat'.
Posted by: viagra online | August 13, 2010 at 05:09 PM
Success covers a multitude of blunders.
Posted by: new balance | October 15, 2010 at 02:43 AM
DEKARONデカロン-RMTRMT rmt とはis currently constructing the Kahuku Wind facility located on the island of Oahu in Hawaii. リネージュ2 rmtThe 30-MW facility will feature 12 wind turbines and will generate enough clean energy to power about 7,700 homes each year. アトランティカ RMT RMT is providing engineering, procurement,Atlantica RMT and construction of the civil and electrical infrastructure, rmt ff14including roads, crane walks and pads, turbine foundations, tower erection,aion rmt a 23-kV underground collector system, a 23/46-kV step-up substation, and a 7,000-square-foot operations and maintenance buildingrmt リネージュ2.
Posted by: DEKARONデカロン-RMT | January 17, 2011 at 09:26 PM
Thank you for sharing. Very happy to see your article, I very much to like and agree with your point of view. Have a good time.
Posted by: Auto Parts & Electronics | May 05, 2011 at 03:24 AM
This is my first time i visit here. I found interesting things to many in his blog, mostly to the debate. Of the tons of comments on your articles, I’m not the only one who has all the fun here! Keep up the good work.
Posted by: keylogger for Mac | July 14, 2011 at 04:06 AM
I love movies and one thing this offers for me is the new things movie companies can do with technology.
Posted by: chemistry nursing | July 23, 2011 at 03:03 AM
they were thrifted, from a local value village, on separate occasions... id love to find more too!
Posted by: duties certified nursing assistant | July 23, 2011 at 03:06 AM