Strange Loop 2009 – Day 2

My notes and thoughts about day two of strange loop 2009.

Also be sure to check out my Day one notes.

jQuery – Matt Taylor

Mobile Development 101

Entrepreneur Talk – Panel Discussion

Polyglot Grails – Jeff Brown

Minimalism – Alex Payne

List of slides on strangeloop.com
Day two sessions

  • Share/Bookmark
October 25, 2009 | Filed Under java, open source | 2 Comments 

Strange Loop 2009 – Day 1

A new developer conference has started in St Louis this year named Strange Loop. Normally I don’t go to developer conferences because they are either in a different country or on the coasts. This one was close by in St Louis, MO. And from the quality of speakers and diverse sessions I predict next years conference will sell out very quickly unless they increase the capacity. Below are my overall topics/themes I took away from the conference and some interesting points from each talk I witnessed along with links to the speaker’s site and slide show if available.


Day two

Strange Loop Thoughts Overall

Functional Ruby – Dean Wampler

Polyglot Programming – Dean Wampler

Griffon (Swing just got fun again) – James Williams

Future of Java – Bob Lee



Day two


Day One Sessions

  • Share/Bookmark
October 24, 2009 | Filed Under java, open source | 2 Comments 

Greatest Barriers to Open-Source Adoption

In May of 2008 CIO.com asked 328 information technology business executives and managers if they use open source applications in their organizations. The good news is that 53% answered that they are already using open source tools. The survey also uncovered why the other 47% are not using open source tools.

Greatest Barriers to Open-Source Software Adoption at Your Company?
Concern Percent
Product support concerns 45%
Awareness/knowledge of available solutions 29%
Security concerns 26%
Lack of support by management 22%
Licensing or legal concerns 21%
Investment in architecture from other vendor(s) 20%
Software quality issues 20%
Customization concerns 15%
Not relevant to our product or service 7%
Pressure on open-source providers by commercial vendors 5%
Software cost allocation policies 2%
Other 9%

What can we learn from the results of this survey?

Corporate Software Developers

Support

For corporate software developers, the number one reason that your organizations do not allow open source products is because your bosses are afraid that there is no support for the tool. They are unaware of the support options that are available to your organization. You need to show management that a particular tool is backed by a company who offers support.  Show him or her the web page that explains the various support options that they provide.

If there is indeed no support for a given tool, then you are the support. Explain how you have the source code, and how well it is documented. Discuss the benefits of an open product and how you can get help from user groups via forums, IRC, and mailing lists. Put management at ease by showing them these mailing lists, and how active they are, or point out how many questions in the forum get answered on a daily basis.

Awareness

The number two reason was awareness. This is easy to fix. Just show them the projects. Show the alternatives.  Some projects even do the work of listing the alternatives for you. In some cases, you can show how the alternatives are interchangeable. Take for example Hibernate and an open source database. You could describe how a project using Hibernate backed by MySQL, two popular open source projects, can be migrated to Hibernate and Postgres in seconds, with no SQL changes, no new stored procedures and almost no risk.

The point is, your managers are not surfing the internet researching open source projects and their alternatives. You probably are and you probably have more to gain in switching to these open source solutions, so the weight is on your shoulders to make your managers aware.  You have to bring the projects to your managers and present them in a way to showcase the size of their communities, the available support, and the commitment of the project’s developers.

Open Source Project Leaders

For project leaders of open source projects, this survey should scream out to you.  If we review what these managers are telling us, and we can alleviate their concerns, then we can get our tools into the corporate domain. Again, if we look at the top two reasons we see that corporate managers are telling us what they want and what they need.

Support

First is support. If you can provide support, then you can mitigate their number one concern. Support can come in many forms. The support that they were referring to in the survey was probably paid support. This is harder for smaller open source projects to setup but that doesn’t mean you can’t offer many lower tiers of support. Mailing lists, IRC channels, forums, and issue lists are certainly valid types of support. If you don’t offer paid support but do offer the other types of support you are really leaving it on the corporate developer to sell those forms of support to their managers. If you can’t offer paid support maybe you know someone who can. Identify these people on your project’s site.

Try to stay active in your forums and mailing lists, don’t leave any questions unanswered, acknowledge every issue that is submitted, and hopefully this will show managers that while they can not pay for premium support, the project is indeed supported by and active and responsive development team.

Awareness

And again, the number two reason that some organizations have not adopted your product is because the big wigs don’t even know that you exist. You have to promote your project and you have to stay committed to promoting your project. Most of us get into open source projects to write code, but project promotion is as important as the code and is often an overlooked or under appreciated aspect of open source projects.

There are many ways to promote your project. Pushing Pixel’s Kirill Grouchnikov point out a few ways in Party of One: Promote. You can promote your project by simply spending some time writing documentation, or write up some tutorials or design decision explanations in a simple blog post. For my project, Architecture Rules, we recently posted Architecture Rules 101 and Architecture Rules 102 which provided simple tutorials for creating easy configurations. These two tutorials have landed us dozens of new users.  We also use a wiki platform to document our project and provide code examples. These are simple things that we have done to promote our project and to increase awareness.

Conclusion

So weather you’re a software developer looking to introduce open source tools to your environment, or a project leader wanting to find more users, look to product support and project promotion.  These two project areas will alleviate up to 80% of a manager’s concerns and increase both the end user developer and the project leader’s chances of the open source project finding its way into the corporate and mainstream domains.

  • Share/Bookmark
July 23, 2009 | Filed Under open source | Leave a Comment