A set of guides detailing the ins and outs of launching, managing, maintaining and contributing to open source projects has been made available. Although created and curated by GitHub, with input from outside community reviewers, they are not exclusive to GitHub products.

The guides have something for every role involved in open source software (OSS), be it a manager, a maintainer or simply a contributor. They also serve as reminder of the effort and amount of work an open source project requires in order to be kickstarted as well as maintained. As we skim through them you'll certainly be left overwhelmed by the extent to which OSS needs help and input.

Starting with Contributing the options are to: 

• Write code or documentation
• Design and take care of the project's usability
• Plan events
• Help others out by reviewing their code or offering them advice
• Write books, recipes, lists
• Write promo material
• Throw full blown classes,e-courses or webinars to educate people on the usage of the project 

But before even thinking of launching your own project, it's highly recommended to first start out by contributing to existing ones in order to familiarize yourself with the process. After that, and when about to launch your own, you'll have to take care of some relatively small but important things first:

Launching a project 

• Choosing a license
• Writing a README
• Writing your contributing guidelines
• Establishing a code of conduct
• Naming and branding your project 

You've launched, hurrah!  But being solo isn't fun. The next step is to fish for contributors.

Finding Users for Your Project

For that you need to: 

• Figure out your message:"you should be able to explain what it does, and why it matters" 
• Consider creating a website for your project to make your project friendlier and easier to navigate as well as drive people to find it and remember it by a single namespace.
• Go where your project’s audience is both online and offline
  "Take advantage of existing communities and platforms to reach your audience" 
• Build a reputation
• Keep at it! "Focus on building relationships instead of hoping that your project will spontaneously gain popularity" 

Now you and your minions are spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around?

By building welcoming communities of course! This also involves managing people and relationships.As such the guides advise not to tolerate bad actors, meet contributors where they’re at, share ownership of your project and resolve conflicts.

The community and leadership around the Perl project for example is certainly no stranger to conflict, and certainly it could find some tips useful on how to go about resolving them as well as handling bad actors. Prime examples of such rifts is the Perl5 and Perl6 split, detailed in The Perl Renaming Debate Highlights Tensions or the one revolving around the Perl Master Plan. This twitter thread has all the lowdown.

After firmly establishing your project and having people flock in, it's time to put on your Maintainer hat.But

What does it mean to be a maintainer?

"Maintaining a project requires more than code. These tasks are often unexpected, but they’re just as important to a growing project.

This involves: 

• Documenting your processes
• Writing down your project’s vision
• Communicating your expectations
• Keeping communication public
• Keeping the conversation friendly
• Being proactive
• Embracing mentorship
• Sharing the workload
• Requiring tests and other checks to improve the quality of your code.Use tools to automate basic maintenance tasks 

It's obvious that maintaining an OSS project is no different from maintaining other software projects, but even harder since you potentially have to collaborate with disparate dozens of people rather than a team of few which you have authority over.That said,the big advantage is that you'll gain the invaluable experience of the Project Manager ,which could potentially prove a career-rewarding choice.

A level above a Maintainer is the Leader, the next role that you might aspire to. The section on Leadership and Governance details how to share responsibilities with your project's volunteers whom you first have to assign the following roles to: 

• Maintainers
• Contributors
• Committers

For some projects, “maintainers” are the only people in a project with commit access. In other projects, they’re simply the people who are listed in the README as maintainers.

A “contributor” could be anyone who comments on an issue or pull request, people who add value to the project (whether it’s triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).

The term “committer” might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution. Which brings us to the troubling question: "When should I give someone commit access?"

You also have to learn learn how to manage the project as a for- profit business. Although OSS projects are run by people volunteering their time pro-bono, there are instances that some amount of money could be most welcome, such as: 

• Getting paid to contribute to open source is the only way some people can participate, either because the project requires it, or for personal reasons.
• Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
• Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. 

The guides therefore describe ways of funding your project, although securing funding is not such an easy task. An example of a failed crowdfunding Kickstarter attempt was that of a proposed book, as described in Help Kickstart First Ever PerlDancer Book back in 2015.

Alternatively, in looking for investors from sponsorships and grants you have to have some hard facts to hand.For this reason, and some others detailed below, you should be employing Metrics to measure the success of your project.That is because with more information, you can:

• "Sell" your work
• Understand how users respond to a new feature
• Figure out where new users come from
• Identify, and decide whether to support, an outlier use case or functionality
• Quantify your project’s popularity
• Understand how your project is used 

And finally, Law, another grim aspect of managing real world projects.Questions looked into in this section are : 

• What do I need to protect my project?
• Which open source license is appropriate for my project?
• What if I want to change the license of my project?
• Does my project need an additional contributor agreement?
• What does my company’s legal team need to know? 

Excellent and very useful information here, since the legal aspect of open source is really the number 1 thing that keeps people awake at night.

In the end, the Open Source Guides encapsulate the whole spectrum of maintaining an OSS project, and proving that it requires much more than being good at coding or writing documentation.

Even if you're not looking to launch your own project but just want to get involved with OSS in some way, the section on Contributing is well worth a read, although going through the whole set of guides is highly educational.

More Information

The Open Source Guides

Related Articles

EU Bug Bounty - Software Security as a Civil Right

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info