How To Start an Open Source Project

Personal experience on the open source project; doing it effectively without mistakes
26 January 2018   1762

My name is Dmitriy Strukov and I’m Ruby developer. Today I want to share my experience creating an open source solution. I will talk about what steps the project should take, how to choose the right functionality for the first release, and what mistakes I faced personally when creating my open source project.

Half a year ago, I got the idea that it would be good to create an open source project. Instead of test tasks for the interview, it would be enough for me to send a link to the repository. The prospect of helping colleagues with the solution to their everyday problems inspired me.

I’ve always disliked gems for creating administration panels. Any extra movement needs to redefine the class, and for change fields you need to make changes to the files. After thinking and conversing with colleagues, I decided to create a new library which would be flexible and would not require dashboards or configuration files.

SimpleAdmin

Initially, the project was focused on the Ruby ecosystem, but this would limit the target audience of such a solution. SimpleAdmin is a cross-platform solution for administrative panels, working as a third party service. Obtaining data from the database from the main application works with the help of a plugin. In the Ruby on Rail it engine, in which the necessary endpoints are created. In the near future, the launch of a prototype is planned.

Determine the goals

Every open source project solves a specific problem. Talk with colleagues, chats, forums, and share your idea. It all helps you on the first steps to understand important things, like which solutions already exist, and to hear criticism. Talk with people who already have open source projects. They can give you very valuable advice, so don’t be afraid to ask and take the initiative.

One important bit of advice which I got at that stage is to pay attention in the first place on the documentation of the project. You can have a very good project, but no one will spend the time to understand how it works.

The most important aspect, without which further steps are impossible, is motivation. The idea of the project should inspire you primarily. Most often people get used to the tools with which they work and fall into a comfort zone, so external opinions may be ambiguous.

Planning

The choice of a certain task manager is a matter of taste. It should have a clear picture of the tasks and stages of your project.

Divide tasks into sub-tasks. Ideally, if one task does not take more than 3–4 hours, it is important to enjoy the implementation of small tasks. This will help to avoid burnout and loss of motivation.

I use pivotal tracker . The main advantage is a free version for open source projects where you can sort tasks by type (feature, bug, chore, release), and group them into releases and determined deadlines.

Documentation

Every open source project should contain these things:

  • README
  • Open Source license
  • Contributing guidelines
  • Changelog

The README file not only explains how to use your project, but also the purpose of your project. If you do not know how to properly write a README file, you can look at other known open source projects or use a template .

The license guarantees that others can use, copy and modify the source code of the project. You need to add this file to each repository with your open source project. MIT and Apache 2.0 GPLv3 are the most popular licenses for open source projects. If you are not sure what to choose, you can use this convenient service .

The CONTRIBUTING file will help other developers contribute to the project. At the first steps of the project, it is not necessary to pay close attention to this file. You can use the already prepared template from another project.

Changelog contains a supported, chronologically-ordered list of significant changes for each version. As with the CONTRIBUTING file, I do not advise paying special attention to this at an early stage.

Versioning

To track important changes for users and contributors, there is a semantic version . The version number contains numbers and adheres to the following pattern X.Y.Z.

  • X major release
  • Y minor release
  • Z patch release

Continuous integration / Continuous delivery

To automatically run tests and build, I use Travis CI. It’s also a good idea to add badges to display the successful assembly of the build in the wizard, the test coverage (Codecov), and the documentation (Inch CI).

After each new commit or merge in the master, I automatically have a deploy on Heroku (very convenient integration with GitHub). All tools are absolutely free for an open source project.

My mistakes

To analyze the initial stage, I had an idea, but there was no clear plan. I decided that I wanted to do this without having a clear idea of how much time it would take or a specific representation of the functions that would be in the first version of the library. I had just a lot of desire and lack of a clear plan.

Also, after reading the history of other projects (not only open source), I noticed that at an early stage, some plans are too optimistic. They need a reassessment of their strengths and capabilities. But it’s not easy to find time each day to write a new feature in the project. Most of the tasks eventually had to be weeded out, leaving the necessary minimum for MVP.

Ruby Meditation #22 in Dnipro

Meditation will be held on May 19, at Parle, Troitska St, 21 g, Dnipro
27 April 2018   296

On Ruby Meditation #22 you will hear about helpful tools and gems for building Slack apps, examples how to build functional architecture with ruby, which place takes Ruby on Rails among alternatives in 2018 and much more.

Come and get your portion of good mood, knowledge, professional communication and tasty lunch :)

Share your positive experience and best practices on this Ruby Meditation #22. If you have any work issues you cannot solve, our community will gladly help you to find the best way out in live discussion at Lightning talks session. You may also try yourself as a speaker with a short 5-10 mins talk. Fill in this form.

Programme

Anna Shcherbinina

Topic: "Docker + GPU. Not about mining."

Anna Shcherbinina
Anna Shcherbinina

Just before Christmas we launched a new body-measurement feature for our shapify.me project. A person goes into the 3D booth, gets scanned, and the body-measurements are calculated with the 3D scan data. We couldn't avoid using a GPU with these calculations.

How to install this branch of processing into our elegant scaling pipeline? When you're dealing with 3D scans you should remember two things: it's expensive and time-consuming. By the way, its workload fluctuates throughout the days. The easiest solution for us was to use Docker.

This speech is not about mining, but the most helpful articles for us were ones such as "Building your own mining farm". That's because we use quite a similar infrastructure.

GPU, Docker, scaling. What we achieved, where we failed, and what it became of it in the end is all included in my speech.
 

Anna Shcherbinina

Head of Web, Artec3D, Luxembourg

Kirill Shevchenko

Topic: "Building Slack apps with Ruby."

Kirill Shevchenko
Kirill Shevchenko

Overview of Slack APIs. Their features, restrictions, and bottlenecks. Which API is right for you? Helpful tools and gems for building Slack apps.
 

Kirill Shevchenko

Ruby/JS Developer

Valentine Ostakh

Topic: "Functional objects in Ruby: new horizons "

Valentine Ostakh
Valentine Ostakh

Overview of functional programming concepts.  What is functional objects. Examples how to build functional architecture with ruby.
 

Valentine Ostakh

Ruby/JS Developer

Leonid Shevtsov

Topic: "A polyglot's view of Ruby on Rails"

Leonid Shevtsov
Leonid Shevtsov

Nowadays, it's hip to switch from Rails to other languages and frameworks. Leonid, too, has abandoned Rails, played the field a bit, and has come around to occasionally but consistently picking Rails for some projects. What's the modern reason to use Rails? What are the strengths of Ruby and Rails and how to build upon them? When you should really jump to some other platform? Let's answer these questions in a true Ruby meditation.
 

Leonid Shevtsov

Systems Architect

Oleksii Dashkevych

Topic: "Project development - preparing hell dish together"

Oleksii Dashkevych
Oleksii Dashkevych

The recipe is averaged, because of many variations. We take some Ruby code and add Rails magic, Postgresql on top. Add Docker for viscosity. Then put this on AWS EBS pan and start frying. It's all roasted until burning deadlines and generously watered with bugs, serves to the customer. They start eating. Eat and whisper: “This is an awesome product!”. At the same time, he forehead is sweating. Kindly offer to fix bugs, but we refuse and put them in JIRA. Do I need to talk about what kind of feedback comes then? Tasks with such recipes, that double estimated.
 

Oleksii Dashkevych

Ruby/JS Developer

Thanks to the sponsors: Ruby Garage, Railsware, Aejis.

Students, who interested in ruby and have a willingness to visit Ruby Meditation, will get a discount 50% with promocode ‘student’. Please send your student ID’s scan to make your registration on the event faster.

If you are a parent of a small baby (0-3 years) on maternity leave and you want to learn more about ruby development you can get a special discount for a ticket with promo code ‘GrowWithYourKid’. Please send your document's scan or take it with you to approve your status and make your registration in the event faster.

If you have any questions or suggestions, don't hesitate to contact us via cell phone: 099 202 6308 or by email: rubymeditation@gmail.com

More details on website.

Buy a ticket