Share with friends and colleagues on social media

Photo by Marcus Rueckert

The following article has been contributed by Marco Strigl, Build Service Engineer, SUSE.

 

 

 

 

 

 

 

 

You might already have heard that, as of 2020, Python 2 will not be maintained anymore. This date seems to be “far, far away from an end user perspective – but is actually upcoming quite quickly if you see it through the eyes of an Enterprise customer, who needs to rely on a maintained software stack even after that date. Or think of a developer, who has to rewrite and test his code for the next Python version.

 

Photo by David Clode on Unsplash

 

The Challenge

At SUSE, a lot of teams already started to migrate their Python code to the next version. While this might be easy to do for code that you own and that is used only in an environment that you define, it becomes interesting when your tool includes code from other parties – especially if you include code from other open source projects.
    
The command line tool for the Open Build Service (osc) is such a tool: it is a free open source community project which makes heavy use of other Python modules and inherits cool features and options from those. 
    
While such inclusion normally makes code easier to maintain and extend, we expected big problems during the planned port to Python 3, as so many upstream projects need to be involved. But the open source community is not only providing free code! It also proves that working together does not need to be just super-challenging if everybody pursues the same goal: Getting the best results out of the cooperation.

 

Let’s prove that with some details:

 

Among our bigger challenges was the decision what to do with the modules not available for Python 3One of the modules in question for example was python-urlgrabber –  and we realized the problem was quite complicated. The one-million-dollar question we had to answer was: Should we port upstream urlgrabber to Python 3 or should we implement the needed functions in an extra module? After some discussions, we decided to go with the latter solution and introduce a new module for these functions

 

Cool Collaboration

But what does this all have to do with  the “collaboration with the community

 

You may have noticed that I am using the pronoun “We” instead of “I”.  The reason is: without the help of the community all the work would have taken much longer.  Why? That’s easy: because I cannot access the experience of people who may have already worked on the same issue, or even tried the same. Let’s take the urlgrabber as an example. Another developer – well, let’s  say his name is John Nice – already tried to patch urlgrabber to be Python 3 compatible. 

 

I used his patch set and asked him about his own experience with itJohn quite honestly responded: “If I were you, I’d drop it, but If you can find a solution, that would be nice”. So, based on his patch set and his opinion it took me two weeks to try to patch urlgrabber to make it Python compatible, and to come to the exact same conclusion: “We should drop it”. But imagine – how much longer would it have taken if I had to come to this conclusion all by myself? 

 

Also, the collaboration with the main developer and upstream maintainer of osc, Marcus Hüwe, is – let me say – a real treat. Marcus directly recognized that porting osc to Python 3 is a lot of work. Thus he was very happy and thankful to have some companion who not only wanted to help by filing tickets, but instead offered to do a lot of the required work himself as needed

 

We started with weekly meetings to see what still remained to be done. Among others, topics we discussed were the corner cases and the way the new code should look like. 

 

Now, after a couple of weeks, the new osc is nearly ready to run on Python 2 *and* Python 3.

 

Personal Take-Aways

What I found out for myself during this project is the following:
    
Working with an open source community might be seen a bit more time-consuming, as you have to get to know each other, and also sometimes wait for each other. It also might include some additional discussions about the Pro’s and Con’s of your decisions. And it brings in many other aspects or use cases that are not covered by your single application. 

 

But the many cool benefits and advantages clearly outweigh the very few potential disadvantanges:
  • You get in contact with many individuals you would never meet otherwise – and you might get new friends around the world.
  • You can share your experience with each other – which brings in additional ideas and features you might never ever have thought about before.
  • You can improve yourself by listening to and learning from those who have already implemented a similar solution.
  • In the end, you can even save time and energy by actively listening to “upstream” (the port of python-urlgrabber might have taken much more time than inventing and working on a new module together with the upstream maintainers).

 

To summarize this, the Pros of collaboration with the community definitely are
  • Sharing experience with others
  • Getting diverse opinions
  • Saving time and energy
  • Improving oneself

 

Collaborating on projects and solutions across the community of course takes its time, as you don’t make your decisions all alone, and you have to pay attention to others. But in the end the benefit for both sides is huge!

 

Share with friends and colleagues on social media
(Visited 1 times, 1 visits today)
Tags: , , , , , , , , , , , ,
Category: Expert Views, openSUSE, SUSE News
This entry was posted Tuesday, 6 March, 2018 at 3:57 pm
You can follow any responses to this entry via RSS.

Comments

  • Lars says:

    Nice to see how SUSE interacts with open source communities and how both benefit from the results. That shows how cool Open Source can be – if you know how to do it right.

  • Leave a Reply

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