loading...

Confessions of an Open Source contributor

xet7 profile image Lauri Ojansivu ・1 min read

If you ever heard of Open Source Kanban board called Wekan, then you probably heard of me too as xet7. I am an Open Source hobbyist contributor on Wekan. And decided to share my day to day journey with this awesome community of dev.to to exchange knowledge. These below are my confessions which shows I have a different but typical life just like other open source contributors. Maybe we can find something common, who knows?

Are you in a hurry, or should we use computer to do the work ?

What I usually don’t spend my time with

Luckily I don’t usually install Windows and it’s updates. My friends at nerd club I lead are trying to install Windows 10 updates to Vista age 17″ laptops that have traditional harddisk (not SSD) and there is no budget yet to change to SSD. Updates takes many days, if they happen to work at all. Those laptops should be used at some courses to teach students. I don’t know why they can’t use Linux in that teaching.

Some months ago: Server debugging

Some months ago I had some crash/reboot problems with Wekan donated servers. After spending a lot of time debugging with support, the reason for crashing was that I did run LXDE desktop and VirtualBox on server, and they fight for some limited resources on server. I also was able to duplicate this same behaviour on my laptop. I was using x2go to connect to that desktop. The solution to that was that I would remove LXDE desktop and VirtualBox, and use libvirt-based virt-manager GUI desktop client. With it I can connect with remote desktop VNC to server though ssh connection to see VMs that are running at server.

Using virt-manager for remote desktop

I have not yet figured out how to build VirtualBox .ova files on the server yet, because I did not get VirtualBox running inside KVM/QEMU. Probably I would need to use https://packer.io or some other tool.

Building Snap packages on my laptop

Once upon time, snap build servers had bug so builds failed, and snapcraft had bug that had a fix at repo that was not yet released, so I figured out how to install snapcraft from source and build snap packages on my laptop. Those bugs have been fixed some time ago.

Answering GitHub issues

I do get email from every new GitHub issue and comment. I do like it, because my email filters organize incoming email neatly. Sometime there has been talk about making a bot that answers general questions, but there has not been so much duplicate questions yet. It’s very nice when also other Wekan contributors answer GitHub issues and send pull requests.

Day-to-day life, when there is no code related progress

  • Some days it seems that coffee does not help enough to wake up, and I find it hard to concentrate. So then I need to sleep around the clock. This happens sometimes when I have been programming whole previous day intensively, or have walked a lot around the city at previous day.
  • Shopping food etc too often take a whole day.
  • Helping relatives and friends takes many days.
  • Cleaning up often takes a whole day.
  • I do like to listen singing of birds, days when sun is shining, days when it rains. Although, some days there is sound of chainsaw as can be seen from photo taken today – yes they did finally get permission to cut the trees at city where I live. Well, a year ago someone cut a iron bar at the parking lot with a circular saw, that was also nice.

Someone used chainsaw in the yard

Customer work

All of the above did slow down customer work, so I’m late in a project. I do already see that limiting original scope of project has helped to make schedule more realistic. Customer said to me, that because I have so much experience, I will figure it out. Because customer is so friendly and encouraging, I do my best to implement everything.

Day-to-day life, when I’m very productive

I have done remote work at home for many years. At some very productive day I did 7 releases of Wekan. At some other day I got one whole feature mostly done, “No comments” permission. Someone at chat commented that it would be very hard to do QA at that speed, wondering am I more of machine than human.

For me, there are still too many manual steps in the release process.

What my life would look like if I had full time work at office

At morning, I would spend time at traffic to I would go to early to office. Work there at office the whole day, at breaks drink Queal at office, and then go home, very tired. Shared office spaces are the worst, and it’s hard to concentrate with all the extra noise. Someone would ask something about unrelated work, so I would have to start debugging from the very beginning again. After work I would spend time at traffic to travel to home, and be very tired. Most likely I would not have enough time to rest and recover before next workday. Yes, I have done this for some days, when visiting company office, and staying at hotel.

(posted originally at: https://blog.wekan.team/2018/09/confessions-of-an-open-source-contributor/index.html)

Posted on by:

xet7 profile

Lauri Ojansivu

@xet7

Maintainer of Wekan, Open Source Kanban board https://wekan.github.io

Discussion

markdown guide
 

At this moment, wekan have around 13k stars on github. It it an open source kanban. And, you are sharing your everyday life. Just awesome!

Looking forward to know more!

At some very productive day I did 7 releases of Wekan.

Wouldn't it be better to plan ahead and do one major release instead of very small minor patch?

I do like it, because my email filters organize incoming email neatly.

Definitely can be written as a tutorial to help others.

how to build VirtualBox .ova files on the server yet..

Are you trying to use the server instead of computer completely? So far I know it's called Nested Virtualization. Also, maybe it can be possible with the actual API for VBoxManage instead of the GUI.

I don’t know why they can’t use Linux in that teaching.

Because people are lazy and people love things that doesn't cost them time. Windows is like everyone uses, and easy to use, rather than the commands. Even though some distro has very impressive UI, it still cannot beat anything of windows/mac. Maybe things will change at a future time. But, if students uses windows, teachers uses windows, then we cannot say anything. After all, it's just a choice.

The reason why OSS developers don't have time to work properly on the OS projects might be all these you explained above. They are busy with chores and life. Even if they work hard, they end up, well, exhausted to properly invest time in it. Nonetheless, they try harder because they love it.

 

At some very productive day I did 7 releases of Wekan.

Wouldn't it be better to plan ahead and do one major release instead of very small minor patch?

github.com/wekan/wekan/wiki/FAQ#wh...

how to build VirtualBox .ova files on the server yet..

Are you trying to use the server instead of computer completely? So far I know it's called Nested Virtualization. Also, maybe it can be possible with the actual API for VBoxManage instead of the GUI.

I did try to do nested virtualization, but did not get it working yet, because I did run out of time. I'll try to continue sometime.

It's possible to run VBoxManage inside Docker also. I would presume it's possible to create .ova file with VBoxManage commands too, but I have not looked from VBoxManage docs yet.

 

Still, 7 release per day means customer have to download (at least something) 7 times per day. Think about it, how would it feel to download microsoft updates for whole day? ;)

If using snap, updates happen automatically, and there is only small break in Wekan usage when it reloads webpage.

If using Docker, and someone would want to test releases, I really can't expect someone spending time to deploy every release of those 7. Docker users would only deploy when they have time for it.

Microsoft updates are usually with forced reboots. There can be some delay added, but usually after that update is forced. This is the worst way.

Linux package updates can come anytime, but usually you can select when to install them. You can also disable updates. Some distros have option to do automatic updates.

Wekan Snap updates can be scheduled to happen immediately, or at specific time at night once.

Any Wekan Docker version can be installed manually, and install updates manually.

And that's why all big guys focus on major releases. And linux gives way to install only major updates too.

Maybe the developers at windows are thinking the same,

more updates = more releases = more productivity

It's not mainly about productivity. New releases often have important bug and security fixes.

I do still remember at the beginning of starting to maintain Wekan, that someone asked could I do releases, so I figured it out.

I have not yet learned how to do separately stable release.

Snap has 4 channels:

  • stable
  • candidate
  • beta
  • edge

Currently when I do releases, I:

  1. Merge develop branch to master
  2. Build snap package
  3. Release snap package first to edge
  4. Test it with sudo snap refresh wekan --edge
  5. If it works, release it to all channels
  6. Change my server to use stable channel with sudo snap refresh wekan --stable --amend

But how it would work, if I would mostly develop at edge, release to stable less often?

There could be different GitHub branches for these channels. Also with Docker it would be possible to select which Docker image and which tag to use.

Wekan does not yet have plugin system:
github.com/wekan/wekan/wiki/FAQ#is...

Maybe it could be like in git feature branch workflow:
atlassian.com/git/tutorials/compar...

So for example, I could have have this workflow:

  1. Feature would be in it's own feature branch.
  2. I merge feature to devel branch.
  3. I release devel branch to snap edge.
  4. When feature works well enough, I would merge feature to stable.

Would this work?

Or would something else work better? Anyone?

This is really popular way to deal with development features, In fact most other companies does this. They often release to development branch. The users can either use the stable version and only update when there is another major/security update. The curious users can use development version and use the latest features.

  • Ubuntu has two release channels, well, normal users know of it as LTS and non-LTS. LTS is well tested, non-LTS is not.
  • Chrome has canary and dev channel.

The list can go on. This is least stressful way to deal with releases.

 

Very great article Mr. Lauri!

I am an open source contributor, like you, 12k stars on github and it is awesome that I found so much similarities in this article about our day-to-day lifes. Great job!