I have a few younger siblings that have recently entered the workforce. This blog is for them and their friends. It has nothing to do with technology. It contains a few very simple, tactical "habits" that I feel everyone needs to follow to be successful in business.
1) Never Answer Your Cell Phone in the Middle of a Conversation (if you answer it in a meeting, you could/should be shot).
This seems obvious but you'd be surprised by how many tenured people break this rule. This was taught to me by an old mentor of mine, Gautam Shah. He said, "Answering your cell phone in the middle of a conversation, even a water cooler conversation, is disrespectful and negates any goodness that could come from that conversation. At that moment in time, the person on the other end of the line is no where near as important as the person you are talking to." 15 years ago, before cell phones, this wasn't an issue, and it shouldn't be today. You should always be engaged with the person you are speaking with, it establishes report, respect and trust. And, God forbid, if you're in a meeting, and you answer your cell phone, you should be wrapped up in the projector screen and bludgeoned with whiteboard dry erasers, because you just made an ass of yourself.
2) Always Bring Something to Write With
My first day of work at Andersen Consulting, I was told by a very smart guy, "Whenever you get up from your desk, make sure you're carrying a piece of paper with you." I smiled and asked, "OK, why?" He said, "It doesn't matter if you're going to a meeting, walking across the room or going to the bathroom, if there is a piece of paper in your hand, you're busy, if you have nothing, you're wandering." I think this is an important lesson for anyone in business. Perception is reality. It's especially important if you're called into your client/bosses office. ALWAYS, bring something to write with. ALWAYS. Never go into a meeting (any meeting) empty handed. Being empty-handed totes an essence of disrespect and uncaring. Oh, and don't forget to WRITE STUFF DOWN. Taking brief notes, even trivial ones, demonstrates that you are engaged and that you care about the conversation.
3) Don't Cross Your Arms When Someone Is Talking to You
This is a funny one that I was guilty of for a number of years until I took an Improvisational Acting class a few years ago (which I recommend to anyone in business). The teacher of the class, Steve Roath, would always point people out who were crossing their arms, before making them put them down. He said, "Crossing your arms creates a barrier between your mind and the knowledge or opinions being shared by others." As subconscious as this reflex may be, I believe he's absolutely right. I've made it a point to acknowledge my arms in conversations and in meetings and I find that when I do cross them, subconsciously, it's typically (for me) a defense mechanism. By lowering them I instinctively open my mind to listen to the information being conveyed to me, and I'm much more apt to listen more fully and to either learn from that information, or craft a much more intelligent response. In summary, don't ever cross your arms. It's a terrible defense mechanism. If necessary, put your dukes up!
4) Make a Real Difference by Creating a Job for Someone Else
This was the most impactful lesson I learned, and it came from Robert Blackwell. Robert and I were at lunch a number of years ago, talking about my then-career as an independent consultant. He asked, "J, do you think doctors are successful?" I replied, "Yes, I think doctors are very successful." He responded, "I think doctors do great things, but it's the guys that build hospitals that are successful, because they create jobs for doctors." That statement always stuck with me. It should be all of our goals not just to fill a role for ourselves, but to create roles and jobs for others. You don't have to be an entrepreneur or a financier to do this, you just have to figure out ways to save your company money or increase it's revenue. So whether your helping a business operate or helping a business develop and grow, you have the opportunity to make a difference, and ultimately, if you do a kick ass job, you will create a job for someone else. That's what makes America great, and how you can be a contributor to it's continued success.
These are a few tips, there are a gabillion others, and that's what blog comments are for. So tell the Millenials, what are your "habits" that you'd like to share with our future leaders?
-J
Saturday, July 18, 2009
Wednesday, July 15, 2009
What is a Solstice Consultant?
One of the places Solstice derives great talent is through it's highly acclaimed, paid internship program, focused on giving college students the opportunity to build experience delivering projects across IT, business process optimization and marketing/change management. Each intern is required to complete projects across all of these domains, in the Solstice spirit of building cross-functional teams. The YouTube video below is a recruiting video a few of our interns have put together about what it means to be a Solstice Consultant.
Tuesday, July 14, 2009
How to Consolidate Twitter Feeds using Yahoo Pipes
Guest Writer: Kelly O'Regan - Solstice 2009 Summer Intern
We recently launched a Twitter account for Solstice. Our goal was to consolidate the twitter feeds from all of the thought leaders in our organization into a single feed for SolsticeLLC. We wanted to accomplish this utilizing purely SaaS and Cloud-Based Platforms. I was able to accomplish this in about 4 hours (including research). Here's how I did it:
In order to complete this process, you’ll need to have 2 accounts, a Yahoo! account and a Twitterfeed account
Start by logging into Yahoo! Pipes with your Yahoo! email address:
1. Click on the “Create a Pipe” link in the top toolbar.
2. To begin, we need to define the content to pull through the pipe. In our case, it will be the RSS feeds from several Twitter accounts.
3. To do this, under the “Sources” dropdown menu in the left hand toolbar, drag a “Fetch Feed” source into your workspace.
4. Here, you can add numerous Twitter RSS Feed URLs to the pipe. To find that URL, go to the Twitter page for whom you’d like to use, and click the “RSS” button in the address bar.
5. Copy the web address once the RSS feed shows up.
6. Paste as many RSS feeds into the Fetch Feed URL boxes. To add more boxes, simply click on the “+” next to the URL.
7. Connect the Fetch Feed module to the Pipe Output (See NOTE below for additions to this Pipe).
8. Click “Save” in the top toolbar.
9. Once you’ve saved your new pipe, click on the “Back to My Pipes.”
10. Click on your newly saved pipe. As you and your colleagues start tweeting, the content will show up under the “List” section of this page. To get this, click on the “Get as RSS.”
11. Copy the link in the address bar, and open a new window.
Next, log into twitterfeed.com:
1. On the Dashboard, click “Create New Feed.”
2. Twitterfeed connect to your Twitter Account- Make sure the one it’s logging into is the one you want other accounts to streamline into.
3. your Feed (Does not show up in any way on your Twitter Account)
4. in the Yahoo! pipes RSS feed.
5. Click the Advanced Settings link, and choose the update frequency and any other additions you’d like to make.
6. IMPORTANT: Be sure to uncheck the “Post Link” box so that your urls aren’t repeated.
7. Click “Create Feed.”
NOTE: Connecting this module to the Pipe Output is the basic form of funneling your tweets into one account. However, there are a few additions to the pipe that might make your Twitter page look a little more polished.
For example, the feeds come through prefaced with the username of the person who originally submitted the tweet. To delete the username associated with each Tweet:
1. Under the “Operators” drop down menu, there is a module called “Regex.” Move that module onto your workspace. The idea of this module is to take out the name of the user who makes the post (ie. “johndoe:” will be removed.)
2. The pattern should read like this: In “item.title” replace “username:” with “______________.” (Do not insert any content.)
3. One of these lines should be added for every Twitter account linked to this Pipe.
4. Connect the Fetch Feed to the Regex, and then the Regex to the Pipe Output.
To Filter out Retweets from being Retweeted:
1. Under the same dropdown menu, “Operators” drag a “Filter” module over to onto your workspace. Here, we will be blocking out anything in the Tweet that would be retweeting an already retweeted piece of information.
2. Within the Filter module, the block should read like the following:
3. “Block” items that match “any” of the following:
4. “item.title” “contains” “RT.*RT”
5. Connect the Fetch Feed module, to the Filter, and finally to the Pipe Output.
That's about it! If you have any additional suggestions or questions, please post them in the comments below. Happy Tweeting!
-Kelly O'Regan
We recently launched a Twitter account for Solstice. Our goal was to consolidate the twitter feeds from all of the thought leaders in our organization into a single feed for SolsticeLLC. We wanted to accomplish this utilizing purely SaaS and Cloud-Based Platforms. I was able to accomplish this in about 4 hours (including research). Here's how I did it:
In order to complete this process, you’ll need to have 2 accounts, a Yahoo! account and a Twitterfeed account
Start by logging into Yahoo! Pipes with your Yahoo! email address:
1. Click on the “Create a Pipe” link in the top toolbar.
2. To begin, we need to define the content to pull through the pipe. In our case, it will be the RSS feeds from several Twitter accounts.
3. To do this, under the “Sources” dropdown menu in the left hand toolbar, drag a “Fetch Feed” source into your workspace.
4. Here, you can add numerous Twitter RSS Feed URLs to the pipe. To find that URL, go to the Twitter page for whom you’d like to use, and click the “RSS” button in the address bar.
5. Copy the web address once the RSS feed shows up.
6. Paste as many RSS feeds into the Fetch Feed URL boxes. To add more boxes, simply click on the “+” next to the URL.
7. Connect the Fetch Feed module to the Pipe Output (See NOTE below for additions to this Pipe).
8. Click “Save” in the top toolbar.
9. Once you’ve saved your new pipe, click on the “Back to My Pipes.”
10. Click on your newly saved pipe. As you and your colleagues start tweeting, the content will show up under the “List” section of this page. To get this, click on the “Get as RSS.”
11. Copy the link in the address bar, and open a new window.
Next, log into twitterfeed.com:
1. On the Dashboard, click “Create New Feed.”
2. Twitterfeed connect to your Twitter Account- Make sure the one it’s logging into is the one you want other accounts to streamline into.
3. your Feed (Does not show up in any way on your Twitter Account)
4. in the Yahoo! pipes RSS feed.
5. Click the Advanced Settings link, and choose the update frequency and any other additions you’d like to make.
6. IMPORTANT: Be sure to uncheck the “Post Link” box so that your urls aren’t repeated.
7. Click “Create Feed.”
NOTE: Connecting this module to the Pipe Output is the basic form of funneling your tweets into one account. However, there are a few additions to the pipe that might make your Twitter page look a little more polished.
For example, the feeds come through prefaced with the username of the person who originally submitted the tweet. To delete the username associated with each Tweet:
1. Under the “Operators” drop down menu, there is a module called “Regex.” Move that module onto your workspace. The idea of this module is to take out the name of the user who makes the post (ie. “johndoe:” will be removed.)
2. The pattern should read like this: In “item.title” replace “username:” with “______________.” (Do not insert any content.)
3. One of these lines should be added for every Twitter account linked to this Pipe.
4. Connect the Fetch Feed to the Regex, and then the Regex to the Pipe Output.
To Filter out Retweets from being Retweeted:
1. Under the same dropdown menu, “Operators” drag a “Filter” module over to onto your workspace. Here, we will be blocking out anything in the Tweet that would be retweeting an already retweeted piece of information.
2. Within the Filter module, the block should read like the following:
3. “Block” items that match “any” of the following:
4. “item.title” “contains” “RT.*RT”
5. Connect the Fetch Feed module, to the Filter, and finally to the Pipe Output.
That's about it! If you have any additional suggestions or questions, please post them in the comments below. Happy Tweeting!
-Kelly O'Regan
Friday, July 10, 2009
Situational Applications - Build for Today be Ready for Tomorrow
Today I want to talk to you about the concept of "situational applications". The term is relatively new, but the concept is not. The concept is KISS (Keep It Simple, Stupid) or the Pareto Principle. The reality of how most software is developed however, is very different.
First let's define a Situational Application: "A Situational Application is 'good enough' software created for a small group of users with specific needs. . . as the requirements of a small team using the application change, the situational application also continues to evolve to accommodate these changes."
What's funny is the best applications (or frameworks), often start as situational. For example, SMTP, which is the standard protocol for sending email, was initially developed as a simple way to send electronic messages, after the introduction of many bloated formats (including Mail Box Protocol and FTP Mail). Many early internet providers found these original protocols, although comprehensive, too complicated to implement. SMTP, which stands for Simple Mail Transfer Protocol, was developed as a simple way to send text-based messages from point A to point B. The simplicity of the framework caught hold, ultimately became the standard, and was then enhanced to support binary file transport (among other enhancements you are already familiar with as an email user).
Web services are another great example. The original vision manifested as SOAP, which was a comprehensive, complex protocol for allowing different systems to talk to one another. Ultimately, comprehensiveness lost out to complexity and as an after-shock, REST was introduced,. REST is a simple protocol that does the same thing, without all the bells and whistles. The result is that REST has taken hold as the preferred standard. REST has continued to evolve to meet additional needs as they gain traction, but it's evolution is organic, not forced.
Moving on to 2009, let's look at Facebook. FB is a comprehensive way for individuals to stay in touch with one another. But after the initial "sign up" phase, where we research all of our old friends and flings' pictures and profiles, we settle in to reading "status updates" from our friends. So in comes Twitter, which throws the bells and whistles aside and focuses solely on the status updates. The simplicity and flexibility is appealing, and has begun to get great traction in business as well as personal use for that reason. Twitter will continue to evolve to encompass some of FB's features, but in time, and as really needed (i.e. "quizzes" will probably be far on the horizon, thank God).
I've gotten the opportunity to build a lot of new software products for great companies. And the more apps we build, the more I realize that most (if not all) of them are in fact, situational, and should be treated as such. Instead of trying to build the end-all-be-all in release 1, I've found we're more successful understanding the core business problem, building it, and getting it out into the user community quickly. Ultimately, the user community will drive the direction of the application. If a core need is met quickly, the app will be used; and if the app is friendly and appealing enough, users will want to give ideas on how it can continue to make their lives/jobs easier. In all of my years building applications, the most time-tested and well received, have inevitably started by simply solving a "situational" problem. Over time, they have become much more than that, but they all started with a laser focus.
37Signals does a great job at doing this with their products. Google, in most cases (Gmail is a great example), does as well. The key is bringing this discipline into the enterprise.
If you are a product manager (or if you work for one) remember to KISS your application. Get it out early and request feedback from users often. Use Agile Software Product Development to get that first release out quickly. The methodology lends itself to this approach. Stay focused on business value and work to achieve it as quickly as possible. Do not try to solve every problem for everyone right away, instead solve the BIG problem for everyone first. Everyone will line up behind you and your product after that to take care of the small stuff.
Please use the comments below to share ways that you Keep It Simple in your software product development, or share your experiences of how your 'situational applications' have become THE application because of laser focus on solving real business problems.
As always, thanks for reading.
-J
First let's define a Situational Application: "A Situational Application is 'good enough' software created for a small group of users with specific needs. . . as the requirements of a small team using the application change, the situational application also continues to evolve to accommodate these changes."
What's funny is the best applications (or frameworks), often start as situational. For example, SMTP, which is the standard protocol for sending email, was initially developed as a simple way to send electronic messages, after the introduction of many bloated formats (including Mail Box Protocol and FTP Mail). Many early internet providers found these original protocols, although comprehensive, too complicated to implement. SMTP, which stands for Simple Mail Transfer Protocol, was developed as a simple way to send text-based messages from point A to point B. The simplicity of the framework caught hold, ultimately became the standard, and was then enhanced to support binary file transport (among other enhancements you are already familiar with as an email user).
Web services are another great example. The original vision manifested as SOAP, which was a comprehensive, complex protocol for allowing different systems to talk to one another. Ultimately, comprehensiveness lost out to complexity and as an after-shock, REST was introduced,. REST is a simple protocol that does the same thing, without all the bells and whistles. The result is that REST has taken hold as the preferred standard. REST has continued to evolve to meet additional needs as they gain traction, but it's evolution is organic, not forced.
Moving on to 2009, let's look at Facebook. FB is a comprehensive way for individuals to stay in touch with one another. But after the initial "sign up" phase, where we research all of our old friends and flings' pictures and profiles, we settle in to reading "status updates" from our friends. So in comes Twitter, which throws the bells and whistles aside and focuses solely on the status updates. The simplicity and flexibility is appealing, and has begun to get great traction in business as well as personal use for that reason. Twitter will continue to evolve to encompass some of FB's features, but in time, and as really needed (i.e. "quizzes" will probably be far on the horizon, thank God).
I've gotten the opportunity to build a lot of new software products for great companies. And the more apps we build, the more I realize that most (if not all) of them are in fact, situational, and should be treated as such. Instead of trying to build the end-all-be-all in release 1, I've found we're more successful understanding the core business problem, building it, and getting it out into the user community quickly. Ultimately, the user community will drive the direction of the application. If a core need is met quickly, the app will be used; and if the app is friendly and appealing enough, users will want to give ideas on how it can continue to make their lives/jobs easier. In all of my years building applications, the most time-tested and well received, have inevitably started by simply solving a "situational" problem. Over time, they have become much more than that, but they all started with a laser focus.
37Signals does a great job at doing this with their products. Google, in most cases (Gmail is a great example), does as well. The key is bringing this discipline into the enterprise.
If you are a product manager (or if you work for one) remember to KISS your application. Get it out early and request feedback from users often. Use Agile Software Product Development to get that first release out quickly. The methodology lends itself to this approach. Stay focused on business value and work to achieve it as quickly as possible. Do not try to solve every problem for everyone right away, instead solve the BIG problem for everyone first. Everyone will line up behind you and your product after that to take care of the small stuff.
Please use the comments below to share ways that you Keep It Simple in your software product development, or share your experiences of how your 'situational applications' have become THE application because of laser focus on solving real business problems.
As always, thanks for reading.
-J
Tuesday, June 9, 2009
Friday, May 29, 2009
How to Network Effectively
A couple years ago I attended a seminar on effective networking given by Lillian Bjorseth of DuoForce Enterprises. It was a great talk and I took the following notes. I stumbled across them recently and they were great rules to refocus my networking efforts. The notes are broken out as rules to follow before, during and after the event.
________________________________________________________
Networking is more about giving than getting. Sales is harvesting, networking is planting seeds. Do not go to networking events to sell, go to plant seeds
Before The Event
CREATE A PLAN OF ATTACK
I. WHO YOU ARE
Navy blue – authority, trust, knowledgeable
Black – powerful (sometimes too powerful)
Sky blue – tranquilizing
Jacket makes you 1/3 more powerful
Stand up out of respect when someone approaches you to say hello/introduce themselves,
Don’t stand over people that are sitting, sit down with them
Handshake – hand on top – controlling, hand on bottom – submissive, sandwich too personal, limp fingers = wussbag. Go web to web, keep hand firm.
Name tag – always where on right side so people can see your name when they shake your hand
IV. VERBAL BUSINESS CARD (front end of your elevator pitch)
During The Event
After The Event
________________________________________________________
Networking is more about giving than getting. Sales is harvesting, networking is planting seeds. Do not go to networking events to sell, go to plant seeds
Before The Event
CREATE A PLAN OF ATTACK
I. WHO YOU ARE
- Know what you do
- Know what you do differently
- How to be memorable
- They will not refer you if they do not understand what you do
- How to people benefit from what you do?
- Where is your target market what are their organizations and events?
- Get ROI out of your organizations, don't join everything, time is money
- Go to places where people can introduce you to your target market
- Dress
Navy blue – authority, trust, knowledgeable
Black – powerful (sometimes too powerful)
Sky blue – tranquilizing
Jacket makes you 1/3 more powerful
- Posture – confidence
Stand up out of respect when someone approaches you to say hello/introduce themselves,
Don’t stand over people that are sitting, sit down with them
Handshake – hand on top – controlling, hand on bottom – submissive, sandwich too personal, limp fingers = wussbag. Go web to web, keep hand firm.
Name tag – always where on right side so people can see your name when they shake your hand
IV. VERBAL BUSINESS CARD (front end of your elevator pitch)
- 1 or 2 sentence laden with benefits, memorable, contains your name, what you do, active verbs (help, share, work with).
- Do not include company name, geographic location, adjectives, adverbs or the HOW.
- You want the verbal business card to elicit the question of “How”.
During The Event
- 10 minute rule to work a room (you can determine if you want a relationship with someone in no longer than 10 minutes) Ask “Why” questions “ Why did you join this organization, why did you choose this event, .
- Always ask for a business card before giving them yours (polite)
- Look at the business card when they give it to you.
- Ask four questions to determine if they are worth a relationship (have these prepared in advance). Listen for the answers!!! Prepare your ask-for questions in advance to focus your interactions. Listens for the answers because you know best what you want to hear back.
- Try to find commonality (sometimes business card will give you this)
- How to end the conversation: Don’t look around for others.
- If you want a follow up: “I really enjoyed talking, can I email you that report I was telling you about”
- If you don’t want a follow up: “I invited a guest and I want to see if they’ve arrived”
After The Event
- Do what you say (i.e. send them what you promised),
- Set the standard for the relationship!
Tuesday, May 26, 2009
Saas and Open Source alternatives to Commercial Solutions
Solstice and our clients have had success with the following alternatives to Commercial Off the Shelf Solutions. Let me know if you need any guidance on how to transition to these lower cost solutions.
| Category | Proprietary Market Leader | OSS | SaaS |
| Office Productivity | MS Office | OpenOffice | Google Docs |
| Customer Relationship Management | Siebel | SugarCRM | 37Signals HighRise |
| Human Resources Management | PeopleSoft CRM | OrangeHRM | Zoho People |
| Content Management | Interwoven Teamsite | Drupal, Joomla | TBD. . . |
| Portal | IBM Websphere Portal, MS Sharepoint, | Liferay, .NETNuke | Google Apps |
| Collaboration | MS Exchange, Lotus Notes Domino | Zimbra | Google Apps |
| Social Networking | TBD (MS, IBM, Oracle) | Elgg | Ning.com (free), KickApps (sub), |
Thursday, May 21, 2009
Pros and Cons of Open Source vs. SaaS vs. Commercial Software
The following table outlines some pros and cons of open source vs. Saas and COTS solutions. Leave a comment on anything I might be leaving out or not considering.
| | Commercial Off the Shelf Products | OSS Products | SaaS Products | |
| Speed to market | New features are packaged and released based on corporate release schedules | Feature Driven Development – new features are often made available as soon as they are built and certified | Immediate. No initial installation. Features are often slipstreamed in as they are developed | |
| Customization | Typically limited and due to proprietary nature of systems, makes upgrades difficult. | Best option for customization with products embracing open standards. OSS was founded on customization. | Worst option for customization, although depending on the platform, may offer some options. | |
| Interoperability | May or may not embrace open standards | Typically based on open standards, easier to share info between systems | It depends, but most successful SaaS projects are open enough to allow for plugin development (i.e. GreaseMonkey) | |
| Support | Depends on vendor and support plan | Community driven, the more active the community, the better the support. Many established OSS projects also have paid support options | Typically the best, since if one person is having the problem, everyone is having the problem. | |
| Vendor Lock In | Vendors are financially encouraged to promote platform lock in | Flexibility eliminates lock in | SaaS vendors are also financially encouraged to promote platform lock in, although exports are more standard. | |
| Security | Vulnerabilities typically take longer to assess, fix and deploy. | Studies show OSS tends to be more secure than proprietary. Patches often delivered in hours vs. days or months | Security tends to be the best for viable services providers. | |
| Total Cost of Ownership | TCO often involves software licensing, upgrade, support and larger hardware costs | Studies show 90% lower TCO for open source solutions | For SMM’s, TCO tends to be lowest for SaaS since you only pay for what you use (i.e. per user licensing) with no support or hardware required. | |
| Staff Retention | Skillsets are often constrained by the products you have purchased | Open source attracts innovative people and builds “street cred”. They feel part of something bigger. | End users love it, developers/administrators dislike due to black-box/outsourcing nature |
Wednesday, May 13, 2009
Private vs. Public Cloud
Google came out with a blog post recently touting their public cloud vision. VMware responded with a blog touting why the private cloud concept was better. Who's right? Both of them. VMWare's private cloud vision will help companies maximize their existing infrastructure investment, while Google (and Amazon) is focused on building a platform for the future. The comment I left on the VMWare blog is an attempt to marry these two visions into a near term and long term strategy. Here's what I wrote:
Whether you choose to invest in a private, public or hybrid cloud infrastructure depends on your company's infrastructure capital investment to date, SLA and privacy needs.
1) My suggestion for large enterprises with an internally hosted data center, is to build your private cloud, but look for opportunities to start porting non-mission critical VMs (i.e. test environments, departmental apps) to the public cloud. Over time, as the public cloud matures, more and more of your private cloud's assets can be moved, so you can stop investing capital dollars in soon-to-be-outdated hardware.
2) For those who are outsourcing their data center to a 3rd party, you have incredible leverage to challenge their current pricing models, and if they don't play ball, you have motivation to start moving items to the public cloud more quickly.
3) For SMBs, startups and companies experiencing rapid growth, the public cloud is where you should focus your investment/move your assets. Get on the platform of the future now, so you don't have to pay to move to it later.
If you have any questions on how to do any of these things, drop me an email and lets talk.
-J
1) My suggestion for large enterprises with an internally hosted data center, is to build your private cloud, but look for opportunities to start porting non-mission critical VMs (i.e. test environments, departmental apps) to the public cloud. Over time, as the public cloud matures, more and more of your private cloud's assets can be moved, so you can stop investing capital dollars in soon-to-be-outdated hardware.
2) For those who are outsourcing their data center to a 3rd party, you have incredible leverage to challenge their current pricing models, and if they don't play ball, you have motivation to start moving items to the public cloud more quickly.
3) For SMBs, startups and companies experiencing rapid growth, the public cloud is where you should focus your investment/move your assets. Get on the platform of the future now, so you don't have to pay to move to it later.
If you have any questions on how to do any of these things, drop me an email and lets talk.
-J
Tuesday, May 5, 2009
How To Evaluate Open Source Solutions
I've been evangelizing a lot about Open Source software recently. But is all open source software good? No!
The pros of OSS are plentiful, but the cons are just as numerous. With often a myriad of competing OSS projects, many not professionally supported, little certainty around future releases, rapid updates requiring constant upkeep and buggy early versions, how can one justifiably take the risk? How do we mitigate these cons and filter the wheat from the chaff?
The following assessment criteria should start the evaluation of any open source product/platform:
- Investigate the licensing/legal situation of the software.
- Evaluate whether the software is standards compliant.
- Contact references to confirm product viability.
- Find products with a supporting or stable developer.
- Find products that use an open/industry standard implementation language.
- Reference third-party reviews of the software.
- Reference books published about the software (the more the better)
- Reference industry analysts, such as Gartner, Forrester or IDC.
- Project extensions are available.
- The project has reached a 1 year maturity mark.
- Security patches, bug fixes, and new features/enhancements are delivered separately.
- The core development team has rigid criteria for participation.
- The software has reasonable automated unit and functional tests with code coverage in the 30-80% range.
- The software easily integrates with external services
- The component’s bug database is kept up-to-date with revision numbers for each product enhancement.
- The solution has been ported across multiple platforms (Linux, Windows, Solaris, and Mac).
- The community is organized into groups, each responsible for separate tasks (the maintainer, the documentation group, the development group, the evangelism group).
- The project’s license is acknowledged by the Open Source Initiative (http://opensource.org).
- Large-scale adoption, including both public and well-known large-scale organizational deployments
- Separation of documentation: User documentation, Installation documentation, Admin documentation, and Development documentation
And remember to always weigh target usage of the application (mission-critical, departmental or beta) against the OSS product's readiness.
Many of these points were reiterated by our recent discovery of http://www.openbrr.org. Now that's an example of an open source project that lost it's legs, but what was was left behind was some great info. Thanks to that community!
Please let me know some other criteria we should be considering in the comments below. I'll consolidate feedback and send it on to openbrr.org.
-J
Subscribe to:
Posts (Atom)
Posts
