08 February 2012

Open Source, Software Development Futures, and Monki Gras 2012

Monk Gras Logo

I had the pleasure of attending Monki Gras 2012 last week in London, UK. It is a fabulous small conference and that will always be it's challenge. (More on this in a moment.) Monki Gras was probably the best small conference I've ever attended. It was ostensibly a conference about where we're going in software development, tying it back to ideas of craft over industrialization. Following along that theme, we had craft coffee for the breaks, craft beer in the reception and as a tasting at dinner, and enjoyed craft food at the breaks and lunch.

The presentation content, however, was incredible. The format was "short" talks lasting 20-30 minutes. It worked well, allowing lots of time to talk amongst the participants. There were ~150 participants and speakers and this was a perfect size. Over the two days, I walked away with something new to think about from almost every single talk.

Some highlights for me included (and I'll post slide references as I received them):

  • Excellent observations from Matt Lemay (@mattlemay) from bit.ly on "What we share is different than what we click". Best quote: "We've had social media for long enough to be embarrassed by ourselves."
  • Matt Bidulph (@mattb) talked about new ways to consider social media data analysis and presented ideas for the "Place Graph" alongside the "Social Graph" (see pictures below). In a question: What is the Holborn of Amsterdam? Or the Williamsburg of London?
  • Laura Merling (@magicmerl) walked us through a great introduction to the idea of the "craft telco" building on the history of the telco space, and comparisons to the brewing industry from pure to industrialization to craft. (Think Twilio.)
  • Kohsuke Kawguchi (@kohsukekawa) talked about developing developer communities from his experience in Jenkins and the idea of a developer pipeline (analogous to customer pipelines) and how to get developers qualified through it by making everything relentless easier. Slides here on SlideShare. This talk was a great complement to my blog post on software development discipline and developing communities. I also blogged Kohsuke's talk separately on the Outercurve Foundation blog.
  • Jason Hoffman and Bryan Cantrill gave an enormously entertaining "Doppelbock" talk on the differing roles of CTO and VP, Engineering with some wonderful anti-patterns. Slides here on SlideShare. Best quote from @bcantrill, "Process doesn't write software."
  • Zack Urlocker (@zurlocker) gave a great talk on considerations for distributed product development practices.
  • Mike Milinkovich (@mmilinkov) also gave a great talk on the relevance of foundations in an open source world. (There was a broad debate on the subject back in November 2011.)
Those were my highlights from Day One in Conway Hall in Bloomsbury. Okay, I also had the Best Espresso of My Life from the Barista-for-Hire. And the beer tasting at dinner led by Melissa Cole was also awesome.

Day Two moved us down to Rich Mix, an equally interesting and completely different venue in Shoreditch. The talks were equally brilliant. My top picks:

  • Gavin Starks gave us great insight into developers and apps driving social change at amee.com. Very cool example of Autodesk integrating with the AMEE environmental data feeds to allow designers to model carbon footprints of designs while still designing, rather than discovering the cost in manufacturing.
  • Paul Downey (@psd) talked about hardware forks and gave us a view of solderpad.com (@solderpad). (Think git for hardware developers only better — very cool.)
  • Donnie Berkholz talked about how much assholes cost projects with examples from the Gentoo world. (They lost 20% of their community from trolls and trouble makers and they NEVER CAME BACK even after the asshole problem had been solved. That's how expensive it gets.)
  • Dave Neary (@nearyd) gave a great introduction into how to develop developer communities from a different perspective to Kohsuke, but again emphasizing the need for detail and craft. He built on ideas of mentorship and apprenticeship and examples from the world of Go. (Ask him about the design of Go boards sometime if you want to be blown away by craft.)
  • Joe "Zonker" Brockmeier (@jzb) introduced people to ideas for promoting their projects with the press and some insight into the world of tech journalists being pitched by PR. A very good how-to with slides here on SlideShare.
  • Leisa Riechelt (@leisa) gave a wonderful talk on "Why most UX is Shite." Her [excellent] notes are up on her blog with a link to slides.
  • Finally, Irene Ros (@ireneros) and Alex Graul (@alexgraul) gave a great presentation on what makes good data visualization and how subjective it can be from both the presenter and observer perspectives.

There were a number of great observations flying around the twitter verse during the conference but two bear repeating:

And from Matt Lemay, one of the speakers:

And therein lies the challenge. It was the perfect size at ~150 people. It wasn't an invite only event so there was a wonderful mix of people. Smaller would have been fine, but bigger and it will lose some of the sense of intimacy and informality that makes the side conversations easy and important. (One person observed that the U.S. event last Fall was more interactive. I've heard of that difference between the U.S. and UK at similar sized events in the past.) I believe James Governor did design the agenda, asking speakers to give specific talks and I've seen this work really well before (Transfer Summit/UK) at bringing an underlying sense of coherency to a small conference. It certainly worked brilliantly well at Monki Gras. Pairing the event with craft beer and craft coffee also worked in ways I didn't imagine.

All in all, a brilliant conference. Redmonk hopes to have all the filmed talks online soon, and I'll update a link as it becomes available.

Update [15 Feb 2012]: I have also written about three perspectives on the care and feeding of development communities on Network World based on three talks given at the conference.

www.flickr.com

28 September 2010

The CodePlex Foundation is now the OuterCurve Foundation

Outer Curve Foundation Logo

The CodePlex Foundation has re-branded itself to the OuterCurve Foundation. There continued to be confusion between the Foundation originally sponsored by Microsoft and the Microsoft forge site (codeplex.com). In June the Board decided it was time to rebrand the organization to clear up the confusion. [Most recently we were given credit for some excellent sponsor work the forge did in the open source community, so we knew the rebranding work was still necessary.]

We worked with a professional agency (Protobrand) and investigated a number of names that conveyed attributes we wanted to have associated with the Foundation. We wanted the name to support our efforts to build credibility for the Foundation within the open source community, and make the Foundation an attractive investment for additional sponsors. And of course we also had to find a name where we could own the urls. In the end we chose the OuterCurve Foundation. We hope it conveys our goal of helping the expanding universe of companies using open source to contribute to the communities they care about and to create their own.

A number of press articles have positioned us as "putting some distance between Microsoft and the Foundation" as the rationale for the rebrand, and I want to emphasize that the distance we're hoping to create is between the forge and the Foundation. We have an excellent working relationship with Microsoft as our founding sponsor. The Codeplex name was originally chosen as there was thought to be more affinity between the forge and the Foundation but it proved not to be so. Not every plan is flawless in its entirety.

The rebranding also coincides with our anniversary. The Foundation is now a year old. In that year, the interim Board put an initial governance structure in place, hired core staff (Paula and I) and we have accepted the creation of two galleries and a half dozen projects. More are on their way. The mission hasn't changed. The Outercurve Foundation exists to provide a software IP management process and project development governance to enable organizations to develop software collaboratively and encourage the growth of the open source software as a development methodology. It's an exciting time.

Some of the coverage:


13 July 2010

Open Core and the Open Source Business Model Debate (on CodePlex)

The past few weeks have seen a resurgence in the debate over whether or not open core is a valid open source business model or not. There has been a lot of passionate and pragmatic discourse from lots of knowledgeable people (Phipps, Ingo, Mickos, Aker, Aslett, Proffitt, O'Grady).

I add my take on the debate on the CodePlex Foundation blog.


12 July 2010

Software Freedom and Open Source Software (on CodePlex)

I just posted my opening thoughts on the current debates over software freedom versus open source software as a foundation for a discussion about open core as a business model. They are over at the CodePlex Foundation blog. Please discuss there rather than here.

Venn diagram of separate free and open spaces


18 May 2010

I've Joined the CodePlex Foundation as it's Technical Director

CodePlex.org Logo

All: I've joined the CodePlex Foundation starting Monday, 17 May as the Technical Director reporting to the executive director. My responsibility is to set the strategic technical direction of the Foundation, and work with the gallery managers and project leaders on a day-to-day basis. I'm excited about this. I believe the CodePlex Foundation has a great role to play as we continue to see more and more commercial organizations participate in open collaborative software development.

The CodePlex Foundation exists to encourage and support the creation of more open source software, specifically working with commercial organizations. People have shared software since we started programming computers. The sharing bandwidth used to be mag tape sized packets and conference schedule delivery rates. Now we have the Internet which changed the dynamics and economics dramatically. Historically, software foundations tied to free and open source software grew to support a particular licensing scheme or project technology community. I think the CodePlex Foundation complements existing organizations quite nicely. The Foundation is an excellent opportunity to broaden the contribution base from commercial organizations and I want to ensure processes and education are in place to enable those contributions.

My first order of business will be to meet with the existing gallery managers and project leads to begin to put in place any process and services they urgently need. From that point forward it will be to help define and shape the rest of the project and IP management processes that are needed to make the Foundation's value proposition a reality for new sponsors and contributors.

A few friends and colleagues have asked what it means for Microsoft's open source initiatives. I don't know. I certainly don't speak for Microsoft. The CodePlex Foundation has a very straightforward mission and I work for the Foundation. Microsoft is the first and founding sponsor, essentially putting their money where their mouth is with respect to managing their own contributions. I expect there will be more sponsors and participants over the coming year and my goal is to enable them all.


06 May 2010

Open Source Communities and Customers in Pictures

[Update (19-Nov-2010, 15:41 GMT): Voici une traduction en Français par Philippe Scoffoni.]

[Update (11-May-2010, 10:37): Matt Aslett posted commentary on this post at the 451 Group CAOS blog.]

Debate continues on whether open core business models are a winning strategy with a capital "w" or not, and whether customers care. Matt Aslett's recent excellent posts continue the discussion. The big concern for those that criticize or express concerns is that customers are mis-lead, essentially that there's a bait-and-switch free-versus-product or a deliberate lack of clarity in the marketing around the product value.

I want to take a different approach to the discussion here. Before we had Internet-sized bandwidth on which to collaborate around software, traditional software business looked something like the first diagram. R&D delivered product. Marketing delivered messages. Sales and marketing managed and qualified leads through a pipeline and if the product solved a customer problem properly, a market was made and you could measure the profits.

Traditional Customer Pipeline

The Internet happened, dramatically removing friction from the process of collaborative software development and delivery. Developers could share the economic cost of software creation (innovation and construction) and large repositories of useful building blocks were born and made available through these project-focused communities. The Web accelerated the early Internet trend.

Companies began to form around some of the projects and for the past decade and a half there's been confusion as people debated how to make money when you give away the software, or the other side of the economic equation around variations on why people work for free. This has unfortunately led to the idea of community and customer interaction akin to the following diagram. The community is jammed into the middle of the customer pipeline. The community gives stuff to R&D which still delivers product. Marketing now messages to customers AND [worse] the community, and the company tries to "convert" the community into customers.

Incorrect Community-Customer Pipeline

This probably started around the time that MySQL AB observed they had a paying customer for every thousand downloads. This mis-set expectations in a fundamental way. People assumed causality. It created false metrics around driving downloads and improving conversion rates. (We'll come back to this ....)

Marten Mickos (while CEO at MySQL) observed that the early community has time but no money while the later community has money but no time, and that his customers are in the latter bucket. This is the start of a better model for understanding community and customer. Let's use the "time is money" line as the division between community and customers because by forcing the separation of the two groups we can add clarity to both and the things a business would need to do differently with each.

Instead lets treat the community (time but no money) as a completely separate entity from the customer pipeline (money but no time). The community members engage with R&D over the project. They engage with marketing in a conversation about project direction, and ancillary things like translations in other markets. Customers are qualified through the pipeline based upon the product.

Separate Community from the Customer Pipeline

Indeed you can start to see how to think about these different groups of people using different well understood and documented processes for community development and sales channel management.

More detail on managing communities and [separately] customer pipelines

This allows you to clearly address each groups's selfish needs.

Community Customers
They have time but NO money They have money and no time
They want a problem solved and look to the project They want a problem solved and look to the product
They can’t be converted Your Community is the litmus test of solution viability.
They can contribute time, so:
What do you want them to do?
What do you need to enable?
What do you need to let them know?
You manage leads through the qualification pipeline and conversion process like any other customer-focused sales process
They will not waste time, so the project needs to solve a problem for them before they will invest themselves in it

Product for customers is clearly differentiated from project and community. How the product is differentiated depends upon the company and the value proposition to customers. At it's simplest, the product may be a supportable and maintained collection of software, certified to run on specific supported platforms and with particular applications, and trivially installable. The product may be the support and maintenance itself. Some companies pack more "enterprise ready" marketable differentiated features or attributes into the product. Others (e.g. Red Hat, JBoss, MySQL) develop a valuable network offering that includes support, maintenance, certifications, additional warranties, monitoring, indemnifications, and the like into a single subscription model. Regardless, there is well-defined value that solves a customer's problems.

Companies like Alfresco and Hyperic and JBoss all saw conversions in the pipeline because potential customers came to the web site, learned what they needed to learn, downloaded the appropriate things to try, and used the community as a litmus test of the solution before returning (self-qualified) to buy product.

This visualization also clears up debate about "open source" and "community". Some companies publish their product source code under open source licenses and never try to develop a real community. There's nothing wrong here if indeed they're running a more traditional software business model and don't care specifically about enabling the community to directly engage with the project. Publishing the software is a sign of strength and confidence in their product and their ability as a company to satisfy customers with a valuable solution that is more than just the software.

Some companies also develop large successful communities without ever publishing their product software. This is why community building is so important for your company and why community development is an essential ingredient in your solution pitch to customers. Communities historically anchored your customers. Communities create knowledge, expertise and experience, all necessary to provide a complete solution for your technology pitch to the customer. Communities create advocates and evangelists to spread awareness about your solution. Communities create enormous inertia in the status quo around your technology. This is why companies like Microsoft invested millions in developing the Microsoft Developer Network (MSDN). It has taken more than a decade for other Internet communities around interesting open source projects to wear down the inertia inherent in MSDN. Likewise, IBM has invested enormous amounts of money in the IBM Developer Network, incorporating free and open source software to meet their solution needs and value propositions to their customers. With open source projects relating to your company, the community is anchoring your solution.

This is the real "conversion". The community enables customers. It is correlative not causative. Community members that have solved their problems using your technology base will carry their excitement, knowledge, and commitment into new places where customers exist. With well organized open source communities, the community now fronts your technology to new customers as well as later anchoring customers once they exist.


02 March 2010

Open Source Software Economics in Pictures

Updated [22-Mar-2010]: Added a little text around the Ohloh javascript widget so Google Reader sees a URL to follow.

Recently, I've encountered several technologists that still don't understand open source software economics and got suitably cranky about "people giving away software for free" and "destroying the value of innovation". I thought it time to try to reach for an easier way to demonstrate what's happening in the industry in pictures.

Everyone is familiar with the idea of a normal "bell curve" distribution representing R&D investment over time. As a technology is better understood and a product succeeds in the marketplace, R&D investment increases, and over time as new technologies advance, the R&D investment in the original technology and product wanes. The integral represents the total R&D investment over time. The function can also represent the "knowledge" gained or the increase in the intellectual asset base.

Normal Distribution Curve
Normal Distribution Curve

Good companies develop and invest in new successive waves of sustaining technologies. So, looking at Microsoft's success with PC operating systems, DOS was replaced by a greater investment in a more innovative Windows, was replaced by a larger investment in a more innovative NT.

Normal Distribution Curve

This also fits nicely with Christensen's original observations about incumbent companies being good at sustained innovations and well run companies knowing how to jump from technology to technology along a sustaining innovation path. This all makes sense when considering a single company's R&D investment. It applies equally well to Sun Microsystems when considering that the steeper slope of successive sustaining innovations was on the hardware side versus the slower (but not inconsiderable) investment from SunOS (a BSD variation) to Solaris.

Normal Distribution Curve

The investment curve for projects like Linux and Apache, with lots of individual and corporate contributors, still looks like a bell curve, but the contributions might better be viewed as a stacked bar chart. Individual contributors invest to meet their specific needs. Because there is enormous overlap in their common needs, they all share the overall investment.

Normal Distribution Curve

Individual contributors get enormous return on their investment. (One gives a few bug fixes to the Apache httpd team, and in return one gets an entire HTTP daemon.) Corporate contributors give for the same ROI. They get enormous return on their investment in technology they use in a product complement space or as a component in their overall solution to the customer. (Before someone takes issue with my Red Hat example above below, understand the "solution" in the customers mind was "UNIX-like servers on inexpensive 'PC' hardware" and not "Linux".)

Normal Distribution Curve

Christensen was careful in subsequent work to point out that the disruption wasn't about technology but about business model. The disruption often started when someone assembled standard cheaper lower performing parts into a solution that solved a completely different need with a very different cost basis. The new solution begins its own sustaining innovation curve until the new technology can compete with the incumbent compared against the criteria about which the customer/consumer cares.

Normal Distribution Curve

The disruptive business model isn't about Linux so much as the ability for corporations to do collaborative development at the component/complement level in a "frictionless" well-managed Internet-enabled community. (The original OSF/1 shared-development of a UNIX-like replacement failed: too few players, too much politics.) Linux is a much stronger disruptive business solution as a way to handle a particular sourcing problem.

It would be interesting to consider the difference between projects with enormous inbound code contribution (versus all the other strengths a well run community brings to the table) distributed across a wide group of players like we see in the Linux and Apache projects, versus projects managed more tightly by a company like MySQL was. Another interesting attribute of this collaborative business model to investigate is how contribution mutates over time. Christensen's work demonstrated that an incumbent gets in trouble when they begin to over-deliver on functionality for attributes their customers consider important. The customer can't absorb the sustaining technology innovation any faster and literally won't pay for it. The slope of the sustained innovation of the competing technology is sufficient to cross into the space covered by the incumbent's solution.

In a shared collaborative development environment, however, because the technology isn't being driven by a single corporate entity, the community of corporations collectively contributes to their own needs and the technology may (i) stabilize where it needs to stabilize, and/or (ii) be taken in new and interesting directions. There is less pressure (if any) to over-deliver with new innovation. The consumers are the developers, but it's a very broad community indeed. This is what I believe just happened with the MeeGo announcement and the combining of the Nokia Maemo and Intel Moblin projects. This is a great inflection point for Linux into the new mobile Internet device space.

One only need read the report from the Linux Foundation charting the growth statistics in the Linux kernel to understand the enormous value generation happening release-on-release, four times a year. Using the Ohloh rules-of-thumb of US$55,000 per person year one gets US$142M of value creation in the 2.6 Linux kernel. The fact that some business models have been destroyed (Sun), or threatened (Microsoft) doesn't mean there's not enormous ongoing value creation in the technology.

Ohloh value chart for Linux 2.6 kernel.

Neither is intellectual property being "destroyed". Again, this is a disruptive business model discussion. Intellectual property is a business choice made on how a company will protect certain intellectual assets as legal property. Which assets to protect, and how, and which property to defend is a business choice based on the cost model a business uses with respect to turning assets into value propositions customers will buy. When a group of companies chooses to collaboratively develop a technology complement/component, they're making a business model choice on how they will selfishly share certain intellectual assets. Nothing was destroyed along the way.


03 February 2010

Berkus's Ten Ways to Destroy Community and Bacon's Art of Community

This was a great week for reviewing "community building" resources in my world. I discovered Josh Berkus's recent Java One presentation, "Ten Ways to Destroy Your Community", and I received my reviewer's copy of Jono Bacon's "The Art of Community". [srw — I was a pre-publication reviewer for Jono.]

Berkus's presentation is absolutely brilliant. After pointing out very tongue-in-cheek why your community is such a painful group of people (e.g. "They mess up your marketing plans by doing their own marketing and PR" or "They mess up your product plans with unexpected innovation"), he proceeds to give you a perfect run down of ten ways to be rid of them with excellent examples. In order:

  1. Difficult Tools
  2. Encourage Poisonous People
  3. Don't Document Anything
  4. Closed Door Meetings
  5. Lots of Legalese
  6. Bad Liaison
  7. Governance Obfuscation
  8. Screw Around with Licences
  9. Stop Outside Committers
  10. Be Silent

The sad part of this list is how true it is. While Josh picked examples from his experiences, too often you visit a site to evaluate a company-led (or consortia-led) open source project to find too many of these counter principles in play.

Jono's book was published last Summer. His lyrical metal prose conveys his brilliant experiences over past years in community involvement, then community development, culminating in one of the best led community examples around Ubuntu. While Jono's eleven chapters don't align neatly with Josh's ten weapons of mass distraction, there is method and madness to attack each of the problems (or hopefully to avoid them altogether).

  1. Difficult Tools [Chapter 5]
  2. Encourage Poisonous People [Chapter 9]
  3. Don't Document Anything [Chapters 3-5]
  4. Closed Door Meetings [Chapter 3,4,8]
  5. Lots of Legalese[Chapter 8]
  6. Bad Liaison [Chapter 11]
  7. Governance Obfuscation [Chapter 8]
  8. Screw Around with Licences [Chapters 1,2,8]
  9. Stop Outside Committers [Chapters 4,8]
  10. Be Silent [Chapter 3]

If you need a quick litmus test to check on your community, read the presentation. Once you [honestly] suspect there may be a problem [or two], dig into book. Enjoy.

The Art of Community Book Cover Ten Ways Cover Page


16 July 2009

The Community Leadership Summit and the Art of Community

Good community leadership is desperately needed. Too often companies mistakenly think of it as some small adjunct to marketing, an extra channel over which to broadcast messages and through which to generate leads. Likewise product engineering can equally confuse community purpose and disrespect its impact, relegating it as "beta tester" or ignoring its contributions with Not-Invented-Here blinders. We've understood community since before we climbed down from the trees, and we've understood the social dynamics: despite our best intents every village has its idiot and every playground has its bully. But when community in its truest collective sense meets business, we seem to forget all our lessons and expect something to manage with the efficiency and efficacy of a time-motion study in an automobile factory.

This weekend, 18-19 July 2009, marks the first Community Leadership Summit in San Jose, California, at the San Jose Convention Centre (McEnery Conf Centre). Jono Bacon, community leader for Ubuntu at Canonical, Ltd. has done amazing work organizing the event and it promises to be a great opportunity to share experiences and learn from one another. It is a free event in front of O'Reilly's Open Source Conference, supported by a small savvy set of vendor sponsors, but the event is about community development experience and not any one vendor's take on it. While free, one should go to the registration page to register.

Jono has also been busy this past year writing "The Art of Community". He developed it over time in conjunction with the Art of Community blog. I was a reviewer, and I think it's an excellent book covering the breadth of the subject. It will be available in August, and you can pre-order it here.

I was hoping to participate in this year's inaugural summit, but unfortunately I'll not be attending it (or OSCON) for several personal reasons. I will certainly miss friends and colleagues, but trust next week will be as brilliant as always!

Pre-order logo for book


30 March 2009

The Microsoft SD Forum Open Source Event

Microsoft and the SD Forum jointly sponsored the Zero Day event this year before the Open Source Business Conference. The past two years this has been a Microsoft sponsored day for ISV partners developing businesses around open source. There was time dedicated in each event to presentations of the relevant Microsoft programs for ISVs, and Sam Ramji would kick off the day with a good Q&A session discussing Microsoft's positions, accomplishments, and announcements around open source software. This year the content was broader, with the afternoon's sessions being organized by the SD Forum. Participants that wanted to engage with Microsoft around their programs could talk with any of the program directors present.

This being the age of Twitter, people were encouraged so to do under the tag #msoss09, and there was some reasonable discussion throughout the day. I also posted a few photographs on Flickr.

www.flickr.com

Bryan Kirchner is now Director of Open Source Software at Microsoft. He acted as master of ceremonies and kicked things off in the morning with a brief discussion of his hopes to continue developing a mutual understanding and deepening relationships with the open source community at large.

Sam Ramji then took the stage. What followed was interesting. This year, with not much new or contentious before OSBC got underway, he chose to talk about the health of the Windows ecosystem in the context of the current economic crunch (reminding people that a staggering 96% of Microsoft revenue comes from partners, i.e. no direct account control). Microsoft is seeing CIO training budgets dropping to zero and many projects are deferred so there was a definite move to cost savings around virtualization and consolidation. (It's interesting that this is how the world started to move when the bubble burst seven years ago.) He also talked about the growth of Windows in the low cost server space and on netbooks. Sam was essentially conveying that the Windows platform is healthy and people should continue to consider it as a deployment platform for open source. He also discussed the new Web Application Gallery initiative at Microsoft as an attempt "to connect markets and forges" around open source so users can easily install and support PHP-based web applications. It's not that the Gallery is particularly an open source initiative, but rather that it supports the sharing of applications written in PHP.

Matt Aslett from the 451 Group took the stage next presenting his latest analysis from their report Open Source is Not a Business Model. Essentially, the 451 Group analysed 114 vendors using open source software within their businesses, against (i.) their choice of open source license, (ii.) their development model, (iii.) their own vendor licensing strategy, and (iv.) the actual revenue trigger. Matt's blog post covers a lot of the ground he presented, so I won't cover it here. I will be debating with him soon on other things to consider in the report. (An added perk for morning participants was a copy of the report.)

Next up was a panel on "Working together in an Open Source World in a New Economy" moderated by Cliff Reeves, who runs the Emerging Business Team at Microsoft which runs the BizSpark program. Panelists included:

  • Clint Oram, VP Product Management, SugarCRM
  • Erica Brescia, CEO, Bitrock
  • Aaron Fulkerson, CEO, MindTouch
  • Dan Merrits, VP Marketing, Eduify

It was a good discussion. SugarCRM and Mindtouch certainly saw the rise of downloads and leads as the economy failed and people became more interested in low cost open source based solutions. There was also interesting honest discussion from the participants on what it's like working with Microsoft as a partner, with concerns being expressed about the complexity of the programs at times, as well as praise for engineering support (FastCGI and PHP being the typical example cited).

After lunch we got to the more general open source part of the program organized by SD Forum. Larry Augustin kicked off the afternoon with his keynote on "The Future of Software: Why Open Source is the Safe Bet". [Larry has kindly allowed me to host his slides. Download SDForum-20090323-v4.pdf (493.5K).] Larry started the presentation with the idea that just like no one got fired for buying IBM in the past, at this juncture in history no one gets fired for buying open source software. He then went on to present the health of the open source based business world from the perspective of investment and adoption (with several case studies).

Next we had two brief mini-talks.

  • Andrew Aitkin (Olliance Group) talked about his views on open source adoption differences between Europe, North America, and Japan.
  • Sam Ramji returned to give a shortened version of his morning's presentation for those that just joined for the SD Forum part of the program.

The final two sessions of the day were panels. First we had "Is there still Open in Open Source" with Mike Fauscette (IDC) moderating, and Jack Repenning (CTO, CollabNet) and Adam Blum (Rhomobile). It was an interesting panel and very much a development process perspective. Discussion revolved around the idea that it's not about the source code, but about the openness of the development process, the social contract, the transparency, and building a community that wants to contribute.

Last up was the venture panel on "Where's the Money?" Mark Radcliffe (DLA Piper) moderated Robert Theis (Scale), Andrew Braccia (Accel), Tim Guleri (Sierra), and Peter Sonsini (NEA). Not surprising but the VCs want us to know they're still open for business, and they're interested in Software-as-a-Service and Cloud related technologies. Also not surprising we learned VCs will fund deals with a compelling solution to a customer problem, or a compelling way to monetize a solution. [This is why I generally don't have a lot of time for VC panels.] There was one point where Peter Sonsini (NEA) observed there needed to be a compelling way to monetize the community for an existing project (with which I violently disagree), but Andrew Braccia (Accel) supported the richer idea that rather than trying to monetize the community one should look at upstream value of a new solution based on the project.

All and all a worthwhile experience. We finished the day with the hosted reception!