Going Open Source, The 20 Most Important Things to Do
Jul 23, 2008 / By Sheeri Cabral
Liveblogging from OSCon 2008: Going Open Source, The 20 Most Important Things to Do – by Martin Aschoff of AGNITAS AS.
Firstly I have to extend a heartfelt “thank you” to Sun Microsystems and Monty Widenius, as I would not have been able to attend OSCon without their assistance.
AGNITAS AS makes e-marketing software, 25 employees, no venture capital, from Munich, Germany. The municipality of Munich runs entirely on Linux desktops and on infrastructures with open source software.
This session is about the nuts and bolts of an open source company. Aschoff kept a journal of the key learnings of the company when it went open source, and has become a board member of the Open Source Business Association in Europe.
Before deciding on going open source:
1) Analyze the open source competition in your space — look at SourceForge [and ohloh and launchpad]. Are you the first in your segment? Do you want to reinvent the wheel?
Ask yourself: How do you differ from your competitors?
2) Collect information on successful open source projects — SourceForge rankings, download numbers, bug tracker activity. http://www.eosdirectory.com — Enterprise Open Source Directory. Look at the project websites, visit community sites.
Ask yourself: Can you match that or at least come close?
3) Identify your business model(s) — “Open Source” is NOT a business model. Open source is a development, distribution and marketing model. In Aschoff’s experience, at least 50% of ideas do not work. “If your user base is big enough, $$ will follow automatically” — this is a MYTH, a WRONG assumption. Users will be very creative in their ways to avoid paying you.
You will likely have to tweak your business model several times (after a year, see what works, what doesn’t work, etc). Do not fall in love with your business model, be flexible enough to adapt to reality.
4) Calculate how going open source will lower your revenue from existing clients (if you have existing clients; not for new software). Clients will demand a better price since you give your software away for free. Clients will want to switch to your open source product.
Ask yourself: How quickly will your open source revenues make up the loss of revenues from existing clients? At first you will lose money.
5) Talk to your investors/shareholders about your idea of going open source. How familiar is the board with the term “open source”? How short/long term oriented is their investment? Are they ready and do they think big enough?
6) Develop a set of arguments why going open source is good for your existing clients, to minimize loss of revenues. The real argument is “The software you use will continue to exist even if our company fails or gets bought.” Admittedly, this is difficult to communicate. Other arguments: free code contributions from community (non-employees), better interoperability with third party software, improved security.
7) Define the initial feature set and capabilities of the open source version (especially if a closed source version will continue to exist). Your open source version must be a working product, attractive enough for users to download, test, install and configure. Some attractive premium features should be reserved for your commercial product.
8) Develop a business and a financial plan for your investors/shareholders to get their approval. You can only convince them if you have convinced yourself first of your plan. Plan carefully and for the worst case — if you make only a real case scenario, you might not be prepared for the worst case. Like software development, everything takes twice as long as you think — # of downloads, community growth, revenue ramp-up, code refactoring, etc).
After deciding on going open source:
9) Choose the project name and logo carefully — if you have to invent a new name, choose a name that people can pronounce “Massachusetts” is difficult for Germans to pronounce. Don’t choose a name that has a bad meaning in another language — Pajero, Mist (German = “crap”). Check whether your project’s name is available as a product name, domain name and a SourceForge project name. Design a logo that looks good even if it’s printed in black and white or a small size.
10) Define the granularity of developer documentation, admin documentation and user documentation. The quality and quantity of documentation defines the initial acceptance of your project. This can be a critical factor for the timing of the initial release of your project. Make sure you choose a good language — if you don’t have a manual in English you very much limit your user base.
11) Choose a suitable open source license. Most users don’t care about the license….BUT it is important for use in commercial environments. Select an OSI-approved license (= “real open source”, otherwise you can’t be hosted on SourceForge). If possible, select a well-known license (Apache, BSD, CPAL, Eclipse, GPL, LGPL, MPL).
12) If the software stack below your project contains closed source components or components incompatible with your open source license, replace them. This is one of the reasons delays happen!
13) Refactor your source code — close security holes, update frameworks and libraries, restructure and comment the source code, use English words only and add license headers. Your code will be public, and you don’t want to be ashamed of it! If the community does not understand your code, nobody will contribute to it. If documentation isn’t the deciding factor for the timing of your releases, the code refactoring will be.
14) Write the documentation: developers — build guide, list of files and their purpose, db schema, signature and description of web service methods…. admins — install guide, configuration files and parameters, tuning….. users — manual, online help….note that developers should NOT write the user documentation.
15) Launch a project website (*.org) with community modules. Recommended components: new, FAQ, forums, bug tracking, public roadmap, wiki, license text, contact information. Have a developer at least acknowledge (if not actually answer) all bugs and questions on forums, it makes folks aware that there’s a good community out there. It took about a year for Aschoff’s forums to be self-sufficient (ie, users helping other users).
16) Don’t push commercial offers on your project website. For those services just have a link to your company website (.com).
17) Write public announcements (more than one) to communicate the launch of your open source project. Each target is different — trade press (technical), business press (less technical), local press, publish on your project and company websites, SourceForge, freshmeat.net, social networks, blogs. If there is $$ for PR, publish a press release, write a whitepaper, talk to the press, call editors….
18) Publish the binary and the source code on SourceForge or an alternative platform with comparable publicity and reach (Google Code, Microsoft’s Codeplex).
19) Set up a demo server for public testing (if your project is web-based).
20) Put all unfinished features and capabilities on the public roadmap for your next release.
Now the real work starts! Keep the product alive¦
Keep track of the SourceForge activity index and influence it to stay near the top of the lists. The formula is published. (things like logging into sourceforge daily, responding to bug reports, etc)
Check and moderate forum and wiki posts.
Continue to write FAQ entries for the most popular questions (this is the job of a community manager).
Respond to e-mails that ask for free support (you need a strategy for this).
Collect and analyze statistical data such as website visits, download numbers, forum entries, e-mail requests, etc. Do not confuse # of downloads with # of users, and # of users with # of customers.
Book tip: Producing open source software by Karl Fogel (of Subversion)
Aschoff feels Going open source is not a short-lived adventure holiday, but more of a permanent relocation to a different country.
Leave a Reply