.

In these modern times for the web, the appearance and use of open source software is becoming more and more commonplace. To some, the process of working on an OS project will sound like the ideal job. No managers or clients, the ability to choose an area of personal interest for your work, the potential for intellectual fulfillment and creative freedom… As with any vocation, however, there are aspects to it that are less than ideal. To guide any would-be seekers of open coding success, Rob Bateman from Away3D takes you through some of the troubles to avoid, and offers advice on how to retain your sanity and enthusiasm over the first few months (and years).

1.     Try to come up with an original idea

This will only make things easier in the long run, as it is difficult to promote any new library that does something similar to an existing open source project. In particular, don’t pick something that has a well established OS library already out there, as you will end up spending a large amount of your time being forced to explain to people why yours is better, while they stare at you with a vague look of incomprehension. If competition is impossible to avoid, get off on the right foot by getting to know the authors of the other library(ies). Try to resist the urge to take pot shots at their inadequacies on their mailing lists and forums, as these are frequently populated by people who are possibly even more single-minded than you.

2.     Decide how much time you are willing to spend on the library before you start writing.

An open source project can become an obsession, so make an agreement with yourself at the start about how much time you are willing to spend on it. Remember that while quitting your day job to free up development hours may seem like a good idea at the time, a typical OS project produces no income at all, and the attraction of actually enjoying your work may blinker your perspective about how sustainable such a decision ends up being. You must plan at least enough residual income to pay for an internet connection and a reliable pizza supplier, for example.

3.     Set up a mailing list so that others can contact you about the library

Maintaining an OS project is definitely not a one-man job, and as you start to attract interest from other developers a mailing list is the best way for everyone to stay in touch. Keeping contact such as this is now essential, as by this point you will have most likely severed all other work and social ties in order to concentrate on your new ‘baby’ and the friendly encouragement from mailing list posts may be just enough human contact to stop you losing your mind. Who knows, they might even end up helping you write a bit of the library.

4.     Always take note of criticism, especially when it concerns bugs

The trusty developer brush-off  “it works for me” should only ever be used on bored designers and ignorant account managers. As an OS author your only audience is now other code obsessives like yourself, so using this line on them is only going to cause pain. In the open source world, a software library that works will automatically be considered a good software library because there are so many out there that ignore this basic tenet.

5.     Set up a website to increase user awareness

Now that you have something others can use and benefit from, make sure you set it loose in the wild. You may feel that you have done enough by logging 5,000 man hours of svn edits, but only you and your nocturnal email friends will know about this. Choose a licensing option (MIT is the most open, GPL the least) and setup a website to post some info about what your library does and why it is awesome at it. Try not to sound too pretentious. If anyone uses your library for even a mildly successful venture, make sure you write about it on your site, as you’ll be the only person who can be bothered to do so.

6.     Distribute some responsibilities to loyal mailing list members

By now you’ll have most likely increased the amount of time you spend on the library in order to deal with all the extra work generated by mailing list queries, bug fixes, website updates and library re-factors. To avoid an inevitable amphetamine addition, try asking some of your mailing list buddies to join you on a more official basis so that work can be shared. As your team builds, you will start getting better at spotting those members who will be a help to the development of the library, something that will be invaluable when dealing with the people you asked initially who turned out to be a hindrance.

7.     Do everything you can to assist newcomers to your library

Unless you favour the elitism and isolation that comes with an incomprehensible codebase, write some documentation and tutorials for your library. This will not only increase the number of potential community members by lowering the bar for developers interested in using your code, but will also save you answering the same questions several thousand times on your mailing list. Writing documentation is a thankless chore, and a good doc writer is someone who is at ease with the sound of whinging coders as they are continually asked what the code does and why it does it. If you are lucky enough to have someone like this in your team, make sure you are very, very nice to them as they will most likely turn out to be one of your most valuable members.

8.     Maintain neutrality in your community

This advice could be applied to any type of online social interaction but holds particular significance in an open source community. Users coming to your mailing list for information are not there to hear angry opinions, and taking sides on any issue not related to your library will only prolong the agony – a deferential air and measured response is, as always, the best way to handle a flaming mail. A lot of  communities are self-policing if members can follow a lead, so establishing a balanced atmosphere early on will save you getting caught up in the debate, and any intruder not keeping the peace will eventually get bored shouting at themselves and decide to vent their frustrations elsewhere.

9.     Set up a company to deal with commercial requests

Combining work and fun into one enjoyable pastime is a goal shared by many, and as your library’s user base continues to grow, so does the opportunity for this eventuality. Of course, if you have already thrown caution to the wind and quit your day job in the pursuit of OS bliss, then making money from the project becomes essential. This is tricky, as by their very nature, open source projects are free to their users and make no money themselves. There are a number of ways you can deal with this, but possibly one of the least fallacious approaches is to set up an independent company that offers production and consultancy services in your chosen field. This appeals to production houses that see your library as a timesaver while at the same time worrying that open source software comes with no guarantees. Your company can fix that by offering guarantees for a price, as well as anything else they fancy.

10. Keep at it!

The absolute worst thing that can befall an OS project is inactivity. Once the rot sets in, fear and doubt spread in equal measures, devouring any credibility you once had. Maintaining a codebase is trouble enough, but constantly upgrading can be a never-ending treadmill unless you prioritise tasks. As there are still only so many hours in a day (damn Einstein), get help choosing what to concentrate on by asking your user base as they will not only feel included by this, but be happier in the knowledge that even if stuff isn’t being built at that precise moment, it is at least being planned.

It is worth noting that for some of the above, the advice is only based on what I wished I’d done at the time, rather than what actually happened. I guess some things have to be experienced before they are learnt. Either way, I hope that this article proves useful and encouraging to anyone pondering an open source career path, or even just a bit of a dabble. To see the results of our own endeavors, visit http://www.away3d.com.

About the author

Rob Bateman is an international renowned web developer and community leader who specializes in content for the Flash Platform, and has always held a particular interest in 3D on the web. In 2007 he co-founded the Away3D engine with Alexander Zadorozhny, and has been leading development for the last two years. He lives and works in London UK where his production and consultancy company Away Media provides expert services in the field of browser based 3D content. He is also the co-author of the recent Away3D handbook: The Essential Guide to 3D in Flash, published by Friends of Ed.


Links

hr





All rights reserved © 2000 - 2014 Favourite Website Awards (FWA) -  Terms & Conditions -  Privacy statement -  Cookie Policy -  Advertise -  About FWA -  Contact