Surviving open source: How to shepherd your development dreams

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

This feature first appeared in the Winter 2019 issue of Certification Magazine. Click here to get your own print or digital copy.

Most open source projects fail. But they shouldn't fail because the lead developer is coming apart at the seams.Some of our most reliable technology in 2019 is directly rooted in open source software projects. Sometimes a single creator sows those seeds and sometimes a handful of collaborators nurture an open source idea from its conceptual tendrils into fully blossomed software.

Whatever the means by which open source projects begin, there is a stage at which they pass from one set of hands, or a few sets of hand, into the supportive grasp of hundreds, even thousands of developers and programmers. All successful open source projects, to some extent, eventually take on a life of their own.

So where does that leave the initial creator? What happens to the ground zero innovator, and what made that person invest so much time into a “free” project anyway? There’s no surefire formula for open source success, but there are things that open source creators and maintainers can do to keep the dream alive, as well as to ensure their own health and wellness.

Open source defined

In order to form a well-rounded perspective on the rigors of open source development, it’s important to know what “open source” means. If a program is called “open source,” then its source code is freely available to its users. This means users can manipulate that code, and even derive profit from their innovations. (Open source does not always mean “free.”)

As witnessed by the hundreds of variations spun off from Linus Torvald’s original Linux operating system kernel, people can and do modify the original idea and distribute their own versions and revisions. Such piggyback innovators also have the ability to distribute as many copies of their creation as they want. Anyone can use an open source program for any purpose; there are no licensing fees or other restrictions on development.

To use Linux as an example (again), Ubuntu is a Linux-variant open-source operating system. You can download Ubuntu, create as many copies as you want, and give them to your friends. You can install Ubuntu on an unlimited amount of your computers. You can create new versions of Ubuntu and distribute them. Open source licenses permit all of this.

You can’t sell Ubuntu, but even Ubuntu itself, or rather, the corporation that shepherds it, Canonical, can’t do that. What Canonical can (and does) sell is various premium services, such as Ubuntu technical support. Red Hat, which based its own Red Hat Enterprise Linux (RHEL) OS on the original Linux, uses a similar model to generate profits.

Such profits can be plentiful: Ubuntu godfather Mark Shuttleworth is a multibillionaire who traverses the globe in a private jet. Shuttleworth is the first space tourist from the African continent and owns resort properties on the African island of Principe. (This author wishes that he could be so troubled.) Not every open source project, however, returns wealth and fame to its creator.

Most open source projects fail. But they shouldn't fail because the lead developer is coming apart at the seams.Imagine, for example, a standard GitHub project that has around 15,000 followers. Whoever created it needs to really focus on the internal benefits of the project. This is to say “internal” to themselves: You have to feel good about the work you are doing. You have to deliver it more or less for no other reason than out of the goodness of your heart.

If it takes off, then you may be able to license a new version or, you might gain fame and migrate to a cushy job at a big company. You may even start your own company. If things don’t immediately turn to profit, well, what’s next? Let’s talk about things you can do to keep your head on straight.

Nurture your passion

First, remember why you’re doing this. As things progress, you will most likely find yourself coding less and answering other people’s questions more. You made something cool, you grew and developed it, and now, metaphorically, it is starting to walk. People are going to ask how you did things, or why you did them. Others will ask for tips on how they can interface and grow your project faster.

If this happens, keep things simple. Answer questions directly and publicly. Take a break when you need one. You do not have to answer everyone’s questions all the time. Your sanity and long-term health are more important. Above all, keep your focus on the project itself. Try not to lose sight of what spurred your creative juices in the first place.

Write stuff down

The second key item when it comes to keeping your cool is documentation. Don’t be the person who created the recipe that everyone loves, and no one can replicate. It can be difficult and time-consuming to document how you did something, to show what you intended, or to make notes about how you wanted something to be tied in — but it’s the most important thing you can do.

No one is so smart that they can remember all of this. After some customization and some collaboration with others, what began simply can grow to the point where you just don’t remember how something was done. Be smart, write it down. It gets harder to tell where you intended to go, or even what point you’ve reached along the way, if you have no idea where you started.

Be open
Somewhat paradoxically, another saving grace is to make your intentions public, and keep a line of communication open to everyone following your effort. Remember that there is a positive aspect to increasing attention: Others want to contribute to the project and help it grow. Those collaborative instincts will bear most fruit when your purpose and expectations are clear.

A healthy base of followers will always want to move you faster than you can go. In addition to learning how — and when — to say “no,” how – ever, your original goals will benefit if you take the time to provide a degree of mentorship.

Stay involved

It’s relatively simple to predict what happens when someone walks away from a leadership position at a company. The company retools and reloads, and maybe they redirect their efforts. In a business environment, this sort of thing happens all the time, and no one is indispensable. With regard to open source efforts, it never happens this way.

If you abruptly stop watering those tomato plants you’ve been growing in the backyard garden, they wither and die. The same is true of any open source project your initiate. Projects with absentee leadership don’t flourish. They must survive, in order to thrive, and survival requires leader – ship. It’s as simple as that.

Embrace failure

To be clear, failure is not true failure in open source. If something doesn’t work as planned, well, that kind of “failure” is the norm — it happens regularly. That is one of the best things about open source, in fact. In open source, we celebrate the principle that “Given enough eyeballs, all bugs are shallow,” as well as the spirit of iteration.

Open source isn’t about creating one closed software project, but an open community. It’s about experimentation and collaboration. It’s about understanding that everyone involved is pulling in the same direction, working toward a common goal. A culture that sees past failure encourages experimentation, even when experiments seem unlikely to prosper.

Failure, Take Two

The reality is that most open source projects never get any outside code contributions. Most fail. This has always been the case. And that’s OK. In fact, that’s exactly why open source, as a whole, succeeds. The viable ideas thrive and development stalls out on the rest.

The last major study done on open source projects showed that among the 174,333 projects reviewed, researchers could only determine success or abandonment for 145,475. Of that total, only one in six (17 percent) were successful.

Almost half the projects (46 percent) were abandoned in the initiation stage — before the first software release. More than a third (37 percent) were abandoned after the initial release. If things aren’t working, in other words, it’s OK to move on.

Share successes

Remember to strive for a clearly defined vision early in the project’s life, and to build up a good set of users who have clearly defined roles. Also, if you have a well-articulated set of goals, and good project communication, then you need to celebrate your wins! Communicate with everyone and show them that you care, and they will care back.

Begin with a plan in mind

Most open source projects fail. But they shouldn't fail because the lead developer is coming apart at the seams.The amount of data coming into an open source project is what overwhelms individuals. Such information overload can lead to anxiety, hostility, physical illness, apathy, and depression, all of which will contribute to debilitating stress levels.

If you’re about to venture into open source, create a plan that incorporates the suggestions made above. Maybe you’ll receive funding for your project, or one of its ideas will spark the creation of a new company. Maybe it will only be a hobby that keeps you fresh for a while before yielding to other pursuits.

Either way, it’s not worth ruining your health or tearing apart relationships with other people. Whatever you do to maintain perspective and wellness, remember to have fun, and let go before you burn out.

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
Nathan Kimpel

ABOUT THE AUTHOR

Nathan Kimpel is a seasoned information technology and operations executive with a diverse background in all areas of company functionality, and a keen focus on all aspects of IT operations and security. Over his 20 years in the industry, he has held every job in IT and currently serves as a Project Manager in the St. Louis (Missouri) area, overseeing 50-plus projects. He has years of success driving multi-million dollar improvements in technology, products and teams. His wide range of skills include finance, ERP and CRM systems. Certifications include PMP, CISSP, CEH, ITIL and Microsoft.

Posted in Tech Know|

Comment:

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>