There has been a lot of drum beating of late on the topic of the increasing irrelevance of Open Source licensing, & the loudest drummers seem to be Tim O'Reilly & Matt Asay. Matt's recent blog post touches on some great points in this discussion, not the least of which is:
"The real value in open-source software is no longer the software, but rather the resultant services that are delivered over the Web"
This is spot on, and we (the industry) need to move beyond the 'licensing hiccup' that seems to permeate every conversation we have around Open Source (especially in government & enterprise). While I'll preface my statements with the standard disclaimer of 'IANAL', for 'community source', or 'innersourcing' discussions, I think that everyone gets way too wound around the axle on what the license is, and the relative merits of each possible alternative.
I completely agree with Matt's point about the licenses being irrelevant because of the delivery mechanism, however, I'd also add another area where they are less critical is in internal projects behind corporate firewalls. You might be saying, 'Wow, that's a pretty strong statement'. Yes it is, but I think it gets us down to what I hope the really important discussion is - using the collaborative practices of Open Source (the 'Open Community Approach') regardless of whether the license is BSD, GPL, LGPL, or even a custom internal distribution rights clause.
When your application is going to be used for internal purposes (such as what my team at CollabNet is enabling in Forge.mil within the DoD), you should be focusing on how to take advantage of the unique capabilities enabled by the community approach. Before anyone objects too strongly, of course you need to pass all of this by your legal team, but we all need to be advocates for harnessing the key aspects of Open Source, and quite frankly, licensing is not a key differentiator anymore, especially for internally developed & fielded code.
If your system will only ever be delivered within your own firewall, I say, relax, and focus on using the approaches of Open Source (transparent development, open collaboration, meritocratic contribution model) in your projects. The value of innersourcing lies in the ability for project teams to tap into the same kinds of best practices that made projects such as Linux and Apache successful. Increasing the transparency of what is being developed internally also helps break down silos (or at least identifies them so that senior leaders can make informed decisions).
At the end of the day, using Open Source effectively within your organization should be your primary motivator, and if your focus is strictly on risk management or licensing, you are missing the larger, richer part of the Open Source ecosystem.
Monday, July 6, 2009
Monday, May 25, 2009
Memorial Day Musings
Like many Americans, I tried to keep today, Memorial Day 2009, focused on those who have served (and continue to serve) in our armed forces. Whatever your political leanings, I think we can all agree that we owe a huge debt of gratitude to those brave men and women to put their lives (and their family's livelihoods) on the line everyday.
So, what does this have to do with technology, Open Source, and social media? Given that I'm helping create a new initiative (Forge.mil) to enable those building technology for our troops do so in a more efficient manner, I think there is a strong connection. It should go without saying that our armed forces deserve the absolute best technology to help accomplish their mission and keep them safe.
I'm heartened by the fact that technologies and methodologies that we in the consumer space take for granted are now starting to be accepted in the Department of Defense as the most expedient way to help build out the tech that our warfighters need. The whole concept of cross-department collaboration (especially using Open Source development models) enabled by Forge.mil is a pretty large departure from the traditional 'silo-ed' approach of doing things. I can attest to the fact that while progress has been made, we need to continue to push those with leadership roles to really embrace this effort to give those who serve us the best capabilities, in the shortest amount of time, and at the most efficient price point.
I struggle most days with figuring out how to bring things like Social Media and Open Source methodologies into the DoD and the community I'm helping to build in the development space. Thankfully, there are several initiatives being worked on within the department today, including A-Space ('Facebook for Intel Analysts'), and other social site experiments like Synchronicity @ DISA (for use by folks inside of the Defense Information Systems Agency). I believe there is good momentum in this space that will hopefully continue forward.
While all of these efforts are currently 'internal public' within the department, at least they are starting down the path of opening up the lines of communication and collaboration within a very traditional organization. At some point, we are going to have to get to a critical mass or tipping point where these tools are the accepted norm, and aren't feared. I also believe we are going to need a bit of a 'renaissance' from government contractors who need to start thinking not just in terms of money/contracts, but also about truly serving those who work hard every day to serve and protect us. Learning to successfully adapt to the new ways of building software and systems would be a great first step!
Personally, I'm honored and humbled every single day that I get to help (albeit in a very small way) give our service members the technology they need to accomplish their mission. Words cannot truly express how grateful I am for all that they do!
So, what does this have to do with technology, Open Source, and social media? Given that I'm helping create a new initiative (Forge.mil) to enable those building technology for our troops do so in a more efficient manner, I think there is a strong connection. It should go without saying that our armed forces deserve the absolute best technology to help accomplish their mission and keep them safe.
I'm heartened by the fact that technologies and methodologies that we in the consumer space take for granted are now starting to be accepted in the Department of Defense as the most expedient way to help build out the tech that our warfighters need. The whole concept of cross-department collaboration (especially using Open Source development models) enabled by Forge.mil is a pretty large departure from the traditional 'silo-ed' approach of doing things. I can attest to the fact that while progress has been made, we need to continue to push those with leadership roles to really embrace this effort to give those who serve us the best capabilities, in the shortest amount of time, and at the most efficient price point.
I struggle most days with figuring out how to bring things like Social Media and Open Source methodologies into the DoD and the community I'm helping to build in the development space. Thankfully, there are several initiatives being worked on within the department today, including A-Space ('Facebook for Intel Analysts'), and other social site experiments like Synchronicity @ DISA (for use by folks inside of the Defense Information Systems Agency). I believe there is good momentum in this space that will hopefully continue forward.
While all of these efforts are currently 'internal public' within the department, at least they are starting down the path of opening up the lines of communication and collaboration within a very traditional organization. At some point, we are going to have to get to a critical mass or tipping point where these tools are the accepted norm, and aren't feared. I also believe we are going to need a bit of a 'renaissance' from government contractors who need to start thinking not just in terms of money/contracts, but also about truly serving those who work hard every day to serve and protect us. Learning to successfully adapt to the new ways of building software and systems would be a great first step!
Personally, I'm honored and humbled every single day that I get to help (albeit in a very small way) give our service members the technology they need to accomplish their mission. Words cannot truly express how grateful I am for all that they do!
Wednesday, April 15, 2009
The Day The Phones Went Down in Cali...
There is nothing quite like the sound of a very insistent police officer knocking on your door/ringing your doorbell at 5 am on a Thursday. No, for those of your wondering, they weren't there to serve a warrant or arrest me. :) As it turns out, we had a MAJOR outage of communications service in the South County area of the California Bay Area. Specifically, the towns of Morgan Hill (where I live), Gilroy, and part of South San Jose were all completely isolated from a communications perspective. No E911 services, no long distance (calls within the local telephone central office would go through sporadically), and no cell phones. Basically, back to the 'good old days' (or at least the simpler times). The friendly police officer was at my door to fetch me as one of the leaders of our volunteer emergency response team since there was literally no other way to activate our team. I serve on both the Amateur Radio Emergency Services team (ARES) and the Community Emergency Response Team (CERT).
I was in the field for the better part of the day, took a short break, then was back out again in the evening. I'd like to take a look at the technology aspects of this incident, what worked well (Amateur Radio), and what did not (all of the modern infrastructure that we rely on).
The Good:
Amateur Radio Response - I have a sticker on my car from the Amateur Radio Relay League that reads 'When all else fails, Amateur Radio'. There was never a truer statement spoken on 4/9/09. Other than the public safety radios of the police and fire departments, the ARES team I help lead provided the only reliable communications link that citizens had to contact emergency services, and that the Office of Emergency services had to contact neighboring Emergency Operations Centers. As a matter of fact, at one point, Gilroy Fire and Santa Clara County fire personnel were using our radio equipment to coordinate their response from within the respective EOC rooms in Morgan Hill and Gilroy.
However, the most awesome thing I saw during the entire incident was the response from the MAC (Mutual Aid Communicator) system that the Santa Clara County ARES/RACES organization has worked hard to put into place. All told, we had 42 extremely capable amateur radio operators from many unaffected cities in the county descending upon the incident to help us staff key positions. We had communicators in the field at schools, fire stations, community centers, and major intersections to provide a 'safety net' for citizens to report problems and get updated information. We also served as extra 'eyes and ears', freeing up police personnel to focus on more critical tasks. I've never been prouder to be associated with a group of volunteers as I was that day.
Remember, the 'amateur' in amateur radio simply refers to the fact that we can't take money for our services. This group has consistently shown an outstanding level of professionalism and dedication in providing communications support to the South Bay in times of crisis. The city management of both Morgan Hill and Gilroy, and the associated professional responders were very pleased with the efforts of the volunteer groups, and we were glad to be able to put all of our training to good use in support of the stellar job they did. This isn't the 'Ham Radio' that sometimes gets unjustly made fun of ('crazy people with tube radios in their garage talking to China') - this was a professional response by dedicated individuals who were ready and able to be used as a 'force multiplier' to augment the regular first responders.
The Bad:
This incident highlighted all too well how dependent as a society we have become on technology. Now, I'm as much of a technology guy as the next geek, but this incident clearly showed a need to keep 'alternate tech' like ham radio alive and vibrant. Also, this was probably a wakeup call to citizens who spent the day with no ATMs, no POS machines (gas pumps, credit/debit cards, etc.), no Internet, and no E911 services.
Besides the obvious steps that need to be taken to harden and protect the infrastructure we rely on, it's incumbent upon citizens to be prepared for these kinds of incidents. Know your 7-digit police/fire dispatch numbers, have extra cash on hand, make sure your gas tanks are always filled when you hit half empty, & keep enough food, water, etc. on hand to last 72 hours.
The major point to take away from this incident is that it really isn't about the tech, it is about how it's applied. There is a reason that 'old-tech' like two-way radios are still used by police and fire agencies, however, the professionalism of that community, coupled with a dedicated and prepared group of volunteer communicators who know how to work in concert with them is what made the difference in this crisis.
So, go out and make sure you are prepared if the technological underpinnings of our society go haywire again... and, remember to thank a ham radio operator the next time you see them responding to a crisis in your community... :)
I was in the field for the better part of the day, took a short break, then was back out again in the evening. I'd like to take a look at the technology aspects of this incident, what worked well (Amateur Radio), and what did not (all of the modern infrastructure that we rely on).
The Good:
Amateur Radio Response - I have a sticker on my car from the Amateur Radio Relay League that reads 'When all else fails, Amateur Radio'. There was never a truer statement spoken on 4/9/09. Other than the public safety radios of the police and fire departments, the ARES team I help lead provided the only reliable communications link that citizens had to contact emergency services, and that the Office of Emergency services had to contact neighboring Emergency Operations Centers. As a matter of fact, at one point, Gilroy Fire and Santa Clara County fire personnel were using our radio equipment to coordinate their response from within the respective EOC rooms in Morgan Hill and Gilroy.
However, the most awesome thing I saw during the entire incident was the response from the MAC (Mutual Aid Communicator) system that the Santa Clara County ARES/RACES organization has worked hard to put into place. All told, we had 42 extremely capable amateur radio operators from many unaffected cities in the county descending upon the incident to help us staff key positions. We had communicators in the field at schools, fire stations, community centers, and major intersections to provide a 'safety net' for citizens to report problems and get updated information. We also served as extra 'eyes and ears', freeing up police personnel to focus on more critical tasks. I've never been prouder to be associated with a group of volunteers as I was that day.
Remember, the 'amateur' in amateur radio simply refers to the fact that we can't take money for our services. This group has consistently shown an outstanding level of professionalism and dedication in providing communications support to the South Bay in times of crisis. The city management of both Morgan Hill and Gilroy, and the associated professional responders were very pleased with the efforts of the volunteer groups, and we were glad to be able to put all of our training to good use in support of the stellar job they did. This isn't the 'Ham Radio' that sometimes gets unjustly made fun of ('crazy people with tube radios in their garage talking to China') - this was a professional response by dedicated individuals who were ready and able to be used as a 'force multiplier' to augment the regular first responders.
The Bad:
This incident highlighted all too well how dependent as a society we have become on technology. Now, I'm as much of a technology guy as the next geek, but this incident clearly showed a need to keep 'alternate tech' like ham radio alive and vibrant. Also, this was probably a wakeup call to citizens who spent the day with no ATMs, no POS machines (gas pumps, credit/debit cards, etc.), no Internet, and no E911 services.
Besides the obvious steps that need to be taken to harden and protect the infrastructure we rely on, it's incumbent upon citizens to be prepared for these kinds of incidents. Know your 7-digit police/fire dispatch numbers, have extra cash on hand, make sure your gas tanks are always filled when you hit half empty, & keep enough food, water, etc. on hand to last 72 hours.
The major point to take away from this incident is that it really isn't about the tech, it is about how it's applied. There is a reason that 'old-tech' like two-way radios are still used by police and fire agencies, however, the professionalism of that community, coupled with a dedicated and prepared group of volunteer communicators who know how to work in concert with them is what made the difference in this crisis.
So, go out and make sure you are prepared if the technological underpinnings of our society go haywire again... and, remember to thank a ham radio operator the next time you see them responding to a crisis in your community... :)
Monday, March 2, 2009
Don't Ignore The 'Back-Channel'
The concept of a 'back-channel' during presentations, meetings, classes and similar events has been around for a while (the analog version was called 'passing notes', and who knows, maybe even the cavemen did that during boring recitations on hunting/gathering strategy :)).
The modern equivalents started with email, but now even that quaint old service is derided as 'too slow' in the world of instant messaging, and more recently, Twitter. There are two types of back-channel - private (usually in instant messaging), and public (Twitter). I know very few people who don't utilize the former during long conference calls (especially if they are with clients, and you need to address something that came up during the call privately with a colleague). This can be a huge advantage if someone can go off and get an answer/research an issue while the call continues. I can easily see a role for junior-level associates to perform this function, as I think it makes good business sense, and shows a commitment to your customers to serve them in the most efficient manner. It also lets the 'creative juices' flow between members of your team and gives them all a sense of engagement in helping to quickly find the answer for your customer. Of course, you do need to guard against everyone abandoning the actual call, so it's good to have one or two folks whose job it is to do this.
The public back-channel, as implemented in Twitter, is starting to gain more prevalence in conferences and other public presentations/events. Olivia Mitchell recently penned a great guest blog post at the Pistachio Consulting site on this very topic, with great information from the perspective of both the audience and the presenter. You should definitely read the post, but the key takeaways for me were:
What's interesting to me (as a community manager) in this recent usage of the back-channel is how short-lived communities are formed during this time, take on a life of their own, and are then disbanded immediately afterward. I am heartened by the fact, though, that, unlike private IM sessions, the content is automatically archived and easily searchable (especially if using Twitter 'hashtags'), allowing people who didn't attend the presentation to benefit from the community long after it has gone away, and also make potential contacts that can help them with the ideas presented.
I've long used the private back-channel for my own benefit, but I'll be interested to see how my next public presentation goes with all of the Twitterati tapping away - or, at least I *hope* I'll have something interesting enough to say for them to tweet. :)
The modern equivalents started with email, but now even that quaint old service is derided as 'too slow' in the world of instant messaging, and more recently, Twitter. There are two types of back-channel - private (usually in instant messaging), and public (Twitter). I know very few people who don't utilize the former during long conference calls (especially if they are with clients, and you need to address something that came up during the call privately with a colleague). This can be a huge advantage if someone can go off and get an answer/research an issue while the call continues. I can easily see a role for junior-level associates to perform this function, as I think it makes good business sense, and shows a commitment to your customers to serve them in the most efficient manner. It also lets the 'creative juices' flow between members of your team and gives them all a sense of engagement in helping to quickly find the answer for your customer. Of course, you do need to guard against everyone abandoning the actual call, so it's good to have one or two folks whose job it is to do this.
The public back-channel, as implemented in Twitter, is starting to gain more prevalence in conferences and other public presentations/events. Olivia Mitchell recently penned a great guest blog post at the Pistachio Consulting site on this very topic, with great information from the perspective of both the audience and the presenter. You should definitely read the post, but the key takeaways for me were:
- Audience gets more out of presentation & is more engaged when participating in Twitter back-channel
- Smart presenters learn to harness this back-channel, and tailor their content accordingly
What's interesting to me (as a community manager) in this recent usage of the back-channel is how short-lived communities are formed during this time, take on a life of their own, and are then disbanded immediately afterward. I am heartened by the fact, though, that, unlike private IM sessions, the content is automatically archived and easily searchable (especially if using Twitter 'hashtags'), allowing people who didn't attend the presentation to benefit from the community long after it has gone away, and also make potential contacts that can help them with the ideas presented.
I've long used the private back-channel for my own benefit, but I'll be interested to see how my next public presentation goes with all of the Twitterati tapping away - or, at least I *hope* I'll have something interesting enough to say for them to tweet. :)
Tuesday, January 20, 2009
It's Not About The Tech...
Lance Armstrong, one of the people I admire most in this world, wrote a book called It's Not About The Bike. It is a good read, and I enjoyed the main point he made in it - namely, his life and his fight against cancer are about so much more than how fast he can ride his bike, or how much he enjoys the 'tech' of cycling (or tech in general - check out his Twitter Feed).
I was thinking of Lance and that book when I read Fred Wilson's latest blog post, entitled It's About People, Not Technology. He makes his point by pointing out Twitter, and how it has grown to be more than the sum of its technology - I'm an avid user, and I would tend to agree its importance in the social media landscape is directly derived from the users of the tool that post interesting things. The definition of 'interesting' is different for everyone, but the fact that people are forming ad-hoc 'communities' by who they follow, and their use of Twitter 'hash tags', reminds me social media is about the people (feel free to insert 'Duh, really?' comments here).
This notion of people driving the value of tech, not the other way around, has been a long time coming in my brain's 'world view'. I started out as a hardcore techy, and I considered users a necessary means to an end. As I started to mature and learn about the tech industry, and watched my wife, her mom, and my folks struggle with stupidly designed software, I slowly shifted the kinds of things that I wanted to work on. I have no idea if the metamorphosis is complete, but I know I'm much happier now working to help people use technology to collaborate more effectively.
Besides my wife (a public relations professional and outstanding writer), the other driving forces pushing me towards more of a community management/collaboration consultant role were my experiences (starting in college) working in small teams that needed to go outside of their inner circle for help. From building a compiler for my computer science languages class with my lab partner, to working in Sun Lab's equivalent of the Lockheed Martin Skunkworks, to helping found a small 'skunky' team inside of Motorola, I quickly realized that the working relationships of the people in your team, and in your immediate circle of influence are far more important than the tech you are building or using.
My experience as a community manager is far from complete, and I rely on a 'team' of folks that I follow for their knowledge on Twitter or in RSS feeds - people like Stormy Peters, Jono Bacon, Martin Reed, Richard Millington, and Chris Brogan. While tools like Twitter let me 'collaborate' with these individuals (most of whom I've never met in person), the coolness doesn't come from the tech itself, but from the ideas bandied back and forth. The parallels with the 'team' that Lance assembled to help him win the Tour de France and beat cancer are clearly evident to me in this context, and it is awesome to think of how technology can help build these groups. However, I'm also thankful for the perspective I have now which reminds me that social tech without people is like peas without carrots - nutritious, but not as fulfilling as combining the two together.
I was thinking of Lance and that book when I read Fred Wilson's latest blog post, entitled It's About People, Not Technology. He makes his point by pointing out Twitter, and how it has grown to be more than the sum of its technology - I'm an avid user, and I would tend to agree its importance in the social media landscape is directly derived from the users of the tool that post interesting things. The definition of 'interesting' is different for everyone, but the fact that people are forming ad-hoc 'communities' by who they follow, and their use of Twitter 'hash tags', reminds me social media is about the people (feel free to insert 'Duh, really?' comments here).
This notion of people driving the value of tech, not the other way around, has been a long time coming in my brain's 'world view'. I started out as a hardcore techy, and I considered users a necessary means to an end. As I started to mature and learn about the tech industry, and watched my wife, her mom, and my folks struggle with stupidly designed software, I slowly shifted the kinds of things that I wanted to work on. I have no idea if the metamorphosis is complete, but I know I'm much happier now working to help people use technology to collaborate more effectively.
Besides my wife (a public relations professional and outstanding writer), the other driving forces pushing me towards more of a community management/collaboration consultant role were my experiences (starting in college) working in small teams that needed to go outside of their inner circle for help. From building a compiler for my computer science languages class with my lab partner, to working in Sun Lab's equivalent of the Lockheed Martin Skunkworks, to helping found a small 'skunky' team inside of Motorola, I quickly realized that the working relationships of the people in your team, and in your immediate circle of influence are far more important than the tech you are building or using.
My experience as a community manager is far from complete, and I rely on a 'team' of folks that I follow for their knowledge on Twitter or in RSS feeds - people like Stormy Peters, Jono Bacon, Martin Reed, Richard Millington, and Chris Brogan. While tools like Twitter let me 'collaborate' with these individuals (most of whom I've never met in person), the coolness doesn't come from the tech itself, but from the ideas bandied back and forth. The parallels with the 'team' that Lance assembled to help him win the Tour de France and beat cancer are clearly evident to me in this context, and it is awesome to think of how technology can help build these groups. However, I'm also thankful for the perspective I have now which reminds me that social tech without people is like peas without carrots - nutritious, but not as fulfilling as combining the two together.
Sunday, November 16, 2008
Great Panel Discussion!
Thanks to Gwyn Firth Murray, Larry Augustin, and Jeff Luczcz for a very entertaining panel discussion around Open Source at the recent eBig meeting.
I was a bit nervous about how this panel would come together since I was the 'rookie,' whereas Gwyn had worked with Larry and Jeff separately before. However, the commonality of the passion for Open Source brought this panel together nicely and there was an excellent exchange of ideas between and amongst the panel (as well as our audience). I think we had someone in the audience comment on the fact that it seemed like we had all known each other a long time! :)
The areas we covered during the talk were: licensing, community development, and reasons for using Open Source. I think the panel all agreed on good reasons for using Open Source, with all of us giving cogent examples of what the value proposition for using Open Source is (taking advantage of the huge amount of R&D and work that goes into good Open Source projects, like the Linux kernel), and the fact that you are most likely using it right now, without even knowing it (server side, or possibly even in a mobile/handheld device).
The discussion of Open Source's value proposition dovetailed into a talk about making money with the proper business model around its utilization, and especially due diligence in code/compliance reviews prior to shipping a product or being acquired as a company. Due to the large percentage of audience members who were startup-focused, a lot of discussion was around exit strategy as it applied to Open Source compliance.
However, my focus was definitely on the community aspects, and utilizing the exponential power of what the community builds to give you a head start in your business. I shared some anecdotes about my experience at Motorola, when I worked with various teams to shepherd their code changes back to the community. While I tried to share both positive and not so positive experiences, I wanted the audience to understand how to properly work with the community, as well as which pitfalls to avoid. There wasn't as much talk about open sourcing of your own code, but more on how to utilize existing Open Source code out there.
There was a fair amount of discussion of whether Open Source was entering a 'quiet' period, since we don't hear as much about it now. The panel generally agreed that it is a GOOD thing when we factor into it that things like the Amazon Kindle, Android phones, etc. are being sold based not on their Open Source content, but on their lower cost, and better features for end users, which are enabled by the use of Open Source. The eco-systems in these products from a developer and manufacturer standpoint are happening 'behind the scenes,' but the fact is that it is almost impossible to use any sort of technology these days without there being some Open Source component to it, whether on the front end, or with the LAMP stack on the back end.
I made sure to point out that community goodwill should not be the sole reason that you get into utilizing Open Source, and that my favorite expression (WIIFM) holds true here as well. There was also a reminder by me that sometimes as a company, if you need something the community is unwilling or unable to provide, you should consider whether putting that in your protected IP versus back into the community really is the best approach from a business standpoint.
There was definitely discussion around the work I'm doing at CollabNet with DISA to help build a sourceforge.net equivalent inside of the .mil network. I think that crystalized it for a lot of folks that if DoD is realizing the power of not only Open Source itself, but of the community model used to produce it, that small businesses should be thinking of it as well.
All in all, it was a very enjoyable evening, and I learned a lot from all of my colleagues on the panel. I'd like to thank Jack Repenning (CollabNet's CTO) for suggesting me to Gwyn to fill in for him while he was traveling, and also Gwyn herself for being a gracious panel moderator, and taking a chance on the panel 'rookie.' :)
I was a bit nervous about how this panel would come together since I was the 'rookie,' whereas Gwyn had worked with Larry and Jeff separately before. However, the commonality of the passion for Open Source brought this panel together nicely and there was an excellent exchange of ideas between and amongst the panel (as well as our audience). I think we had someone in the audience comment on the fact that it seemed like we had all known each other a long time! :)
The areas we covered during the talk were: licensing, community development, and reasons for using Open Source. I think the panel all agreed on good reasons for using Open Source, with all of us giving cogent examples of what the value proposition for using Open Source is (taking advantage of the huge amount of R&D and work that goes into good Open Source projects, like the Linux kernel), and the fact that you are most likely using it right now, without even knowing it (server side, or possibly even in a mobile/handheld device).
The discussion of Open Source's value proposition dovetailed into a talk about making money with the proper business model around its utilization, and especially due diligence in code/compliance reviews prior to shipping a product or being acquired as a company. Due to the large percentage of audience members who were startup-focused, a lot of discussion was around exit strategy as it applied to Open Source compliance.
However, my focus was definitely on the community aspects, and utilizing the exponential power of what the community builds to give you a head start in your business. I shared some anecdotes about my experience at Motorola, when I worked with various teams to shepherd their code changes back to the community. While I tried to share both positive and not so positive experiences, I wanted the audience to understand how to properly work with the community, as well as which pitfalls to avoid. There wasn't as much talk about open sourcing of your own code, but more on how to utilize existing Open Source code out there.
There was a fair amount of discussion of whether Open Source was entering a 'quiet' period, since we don't hear as much about it now. The panel generally agreed that it is a GOOD thing when we factor into it that things like the Amazon Kindle, Android phones, etc. are being sold based not on their Open Source content, but on their lower cost, and better features for end users, which are enabled by the use of Open Source. The eco-systems in these products from a developer and manufacturer standpoint are happening 'behind the scenes,' but the fact is that it is almost impossible to use any sort of technology these days without there being some Open Source component to it, whether on the front end, or with the LAMP stack on the back end.
I made sure to point out that community goodwill should not be the sole reason that you get into utilizing Open Source, and that my favorite expression (WIIFM) holds true here as well. There was also a reminder by me that sometimes as a company, if you need something the community is unwilling or unable to provide, you should consider whether putting that in your protected IP versus back into the community really is the best approach from a business standpoint.
There was definitely discussion around the work I'm doing at CollabNet with DISA to help build a sourceforge.net equivalent inside of the .mil network. I think that crystalized it for a lot of folks that if DoD is realizing the power of not only Open Source itself, but of the community model used to produce it, that small businesses should be thinking of it as well.
All in all, it was a very enjoyable evening, and I learned a lot from all of my colleagues on the panel. I'd like to thank Jack Repenning (CollabNet's CTO) for suggesting me to Gwyn to fill in for him while he was traveling, and also Gwyn herself for being a gracious panel moderator, and taking a chance on the panel 'rookie.' :)
Saturday, November 8, 2008
Live, from Pleasanton, CA....
For anyone interested in hearing about Open Source as it applies to companies, I'm going to be part of a panel discussion at eBig (East Bay Innovation Group) in Pleasanton, CA on Monday 11/10/08 titled 'Open Source: How to Make Money and Get Money?'. Given my previous post on the pragmatic aspects of using Open Source, I think this should be an interesting discussion.
It's been a while since I've spoken/participated in a panel, but this one should be a lot of fun. I'll be joined by Open Source luminaries Larry Augustin and Jeff Luszcz, with Gwyn Firth Murray moderating. So, yes, for those following, I'm the least well known of the panelists. :) Hopefully my colleagues on the panel will handle most of the questions around legal/IP, since those that follow my blog will remember that while I recognize the value of understanding licenses around Open Source, I tend to be more focused on the community building/collaboration aspects (not surprisingly, given that I do community management for a living).
I'm hoping to bring a more 'rubber meets the road'/developer perspective to what it means to participate in communities and use Open Source. However, I do have opinions on how companies can do a better job of utilizing Open Source in their products, and working proactively with the community is a big part of that. Given the economic times we are in, I believe it is more important than ever for companies to fully leverage the value that Open Source brings, and not just follow a 'fork and forget' mentality when it comes to Open Source in their products. The audience is supposed to be mostly startup and VC-types, so it will be interesting to see how the react to the perspectives of the panel.
If you are going to be in the Bay Area on Monday and want to come out, I'd love to see you there!
It's been a while since I've spoken/participated in a panel, but this one should be a lot of fun. I'll be joined by Open Source luminaries Larry Augustin and Jeff Luszcz, with Gwyn Firth Murray moderating. So, yes, for those following, I'm the least well known of the panelists. :) Hopefully my colleagues on the panel will handle most of the questions around legal/IP, since those that follow my blog will remember that while I recognize the value of understanding licenses around Open Source, I tend to be more focused on the community building/collaboration aspects (not surprisingly, given that I do community management for a living).
I'm hoping to bring a more 'rubber meets the road'/developer perspective to what it means to participate in communities and use Open Source. However, I do have opinions on how companies can do a better job of utilizing Open Source in their products, and working proactively with the community is a big part of that. Given the economic times we are in, I believe it is more important than ever for companies to fully leverage the value that Open Source brings, and not just follow a 'fork and forget' mentality when it comes to Open Source in their products. The audience is supposed to be mostly startup and VC-types, so it will be interesting to see how the react to the perspectives of the panel.
If you are going to be in the Bay Area on Monday and want to come out, I'd love to see you there!
Subscribe to:
Posts (Atom)
