Alex's Adventures on the Infobahn - floss

Comparing Forge-Based and Email-Based Workflow for Open Source Projects

2023-10-22T12:22:00+01:00

In the open source technology universe, how teams coordinate, collaborate and contribute is determined by the workflow they opt for. At a high level, workflows can fall into one of two camps: Forge-based or Email-based workflows. Forge-based workflows gained popularity with platforms such as GitHub and GitLab, while Email-based workflows have been a stalwart mechanism for open source software development with mailing list platforms like GNU Mailman and SourceHut.

In this post, we will look at the benefits and drawbacks of the various approaches, hopefully lending insight to what will work best for your project.

Forge-Based Workflow

Forge-based workflows have revolutionised open source software development. Various advantages have made it an accessible choice for many, including:

1. User-Friendly

Forge-based platforms such as GitHub or GitLab feature a friendly GUI and offer excellent documentation, making it super easy for beginners to contribute to open source projects without needing an in-depth understanding of git and email tools.

2. Centralised and Organised

These platforms provide central repositories that make project management streamlined. Access controls, issue tracking, continuous integration, and other tools all exist in one place.

3. Collaborative Environment

The pull-request model common to forge platforms encourages collaborative code review, making it an excellent tool for open-source projects where code quality is a priority.

However, there's a flip side to this coin:

Cons: Risk of Vendor Lock-in

Choosing a specific forge platform means accepting their choices of features, tools, standard practices, and policies which subtly enforce vendor lock-in. For most open source projects this also means relying on the forge supporting projects with cost free access to features and CI time.

Email-Based Workflow

Despite being considered 'old school', email-based workflows still have merit in today's software development world. They offer:

1. Decentralized and Flexible

In sharp contrast to forge-based workflows, email workflows are inherently decentralized. This approach offers more flexibility for contributors and maintainers alike, as they are not bound to tools offered by a single platform.

2. Line-by-Line Review and Inline Feedback

Email-based workflows stand out when it comes to the review process. The nature of emails allows for contributors and reviewers to break down commits line-by-line. This allows for more granular attention to detail, leading to clearer communication about specific code changes. Additionally, the threading mechanism of emails allows for inline commentary during reviews, making it easier for contributors to respond and iterate on feedback. This approach can encourage deeper understanding and discussion around code changes, leading to well-reviewed and robust code contributions.

3. Enhances git Understanding

Contributors working with email-based workflows generally have a better understanding of git because it requires more hands-on actions when sharing code.

However, they too have potential drawbacks.

Cons: Less Beginner-Friendly

Email-based workflows requires a steeper learning curve and are less friendly for collaborative code reviewing, making it challenging for new contributors to a project.

Adapting Open Source Projects: Email to Forge Workflow Transitions

Transitioning from an email-based workflow to a forge-based one should be a meticulously planned process that respects the existing community's culture and comfort. It's pivotal to keep this move as an evolution rather than an abrupt change.

Initial steps in such transitions can include moving non-code elements to the forge platform. Functions such as issue tracking, documentation, and discussions could be the first set of activities transferred to the forge platform. This strategy allows the contributors to become proficient with the platform’s tools and interfaces while keeping the code contributions intact on email lists.

Your project might encompass several sub-systems, and it could be worth considering this while transitioning. Instead of transforming the entire project at once, one could start by moving individual sub-systems to the new workflow. This incremental, phased approach can prevent chaos and reduce the chances of any significant disruption in the project's flow.

Following the sub-system shifts, the project should then introduce acceptance of pull requests or merge requests created by maintainers. These PRs should still contain code that underwent email list reviews in the previous workflow, ensuring the robustness of code quality.

The final stage of the transition is welcoming all contributors to submit merge requests through the forge platform. The key is to ensure that contributors understand the reasons behind the shift towards a complete merge request approach. They should be given clear guidelines about how and why to use merge requests, making them comfortable with the transition, and empowering them to take full advantage of the tool's capabilities.

In transition, it's necessary to alleviate concerns, clarify intents, and provide resources to learn and help the contributors adjust to the new workflow. Both email and forge-based workflows hold their place and value in open-source. So, when transiting, the project needs and the contributor adaptability should be the cornerstone of your strategy. No two projects are the same, and neither are their paths in adopting new workflow models.

(Fuller disclosure: as @epilys noticed this post was generated via chatgpt. I may have spent more time fiddling with my pelican settings to make sure the author slug was properly shown than I did iterating with GPT4 on the article. It has had some light copy-editing since to clean up some copy and paste errors between iterations and some of the more artificial phrasing it used)

On the death of Google Reader

2013-03-14T22:17:00+00:00

You can probably tell the sort of on-line company I keep from the deluge of noise on the social networks regarding Google's decision to shut down Reader. However we shouldn't be that surprised. In fact some companies that source content from Reader have anticipated the need to collect content themselves.

I of course will have to make a decision at some point. However I'll not do it today like a lot of Reader users have. The rush to try out alternatives has over-whelmed some open source based projects who were quietly growing organically. I don't envy those that have to suddenly gear up their back-end systems because an Internet behemoth gave us 2593 hours notice to sort out a replacement.

I'm mulling over the difference between self-hosting and having someone else do it. I'm not overly worried about going for convenience if I know I can get my data back if I need to. In fact the knowledge that you can theoretically self-host might be enough. To be fair to Google their Data Liberation team made exporting all my Reader data easy.

Before I make a choice I need to decide what my priorities are. Currently I subscribe to 250+ RSS feeds. Obviously I don't read every single post but I make extensive use of tags to quickly process through stuff I do need to see when I need to see it. Aside from news, blog posts, funny cat pictures I also subscribe to other data feeds like bug trackers, code repositories, and other data sources. I of course want access to all of this data at any point on one of a number of devices. This makes a web hosted solution pretty much a must. There is no point having the data on my desktop when I'm somewhere else. From my point of view I want it to be open source compatible because if the company hosting now decides it no longer wants to I'll only have to move the data and not break my work-flow.

It would also be very useful if it had a public API so others can interact with the data. I don't need the solution to be all provided by one company. It's perfectly fine to have multiple 3rd parties sorting out the Android integration. I might even look to doing something to integrate it with my favourite editor (the name of which even my non-geek readers probably know by now). So far my experiment with moving all of IRC and IM into Emacs seems to be working well and should be a subject of another post.

Are you a Reader user? What are your criteria for it's eventual replacement? Is RSS just a dying protocol or is the need to aggregate and sift through data becoming more important?

There may well be a much better way of solving this problem around the corner. I certainly am open to persuasion. But don't take away my current preferred solution until I'm convinced I'm ready to switch ;-)

Free Software legal battles version 2

2010-03-03T12:40:00+00:00

"We have always been shameless about stealing great ideas."

- Steve Jobs, Apple

With the embers of the SCO's legal shenanigans slowly dieing down we were long overdue for the next round of legal attacks on Free Software. We all knew it was coming, having failed with spurious copyright claims the next tool the enemies of free software would employ would be patents. The opening salvo came from Microsoft when they sued Tom Tom for making their devices interoperable with the worlds most used operating system. It was a short skirmish that ended in a settlement and no clear precedent set, and the usual technical workarounds. However free software advocates knew that bigger patent threats were out there and have been preparing for the next round. The biggest fear would be a patent troll would assert rights over free software that would be hard to defend against with counter suites. As it happens the next enemy of free software is not a troll but the polo-neck wearing lawyers of Cupertino.

Apple is obviously worried by the rise of Google's Android smart phone operating system and has decided to protect it's market share by suing the competition for patent infringement. While Apple haven't invented the smart phone (much like they didn't invent the MP3 player) they were the company that brought smart phones to the mainstream. It's obviously an area they wish to monopolise.

Regular readers will be aware of the many problems with patents, especially as they relate to software. Patent's are meant to be awarded for novel and innovative solutions to problems and give the inventor a limited time to monopolise those inventions in return for making the details public and growing the corpus of human knowledge. Patent's are routine in areas like biotech where companies get a number of years to sell their drugs at higher prices to recoup the cost of development before the patent expires and everyone can make them. The problem with software patents is they are rarely novel and innovative, they are usually just a codification of commonly used techniques written up in patent language and submitted to the relevant authorities.

Apple have listed 20 patents in their suit. They include such innovations as turning off the camera when power is low. Others are more technical like the concept of using objects to manage graphical elements on a display. Needless to say none of them look especially novel and hopefully most will get invalidated now the legions of free software users that were so instrumental in researching the flaws in the SCO case turn their attention to finding prior art. There is also the possibility the Open Innovation Network will step in and counter-sue with it's broad range of defencive patents. Unlike a patent troll who has nothing to loose Apple could have it's injunctions served against shipping products if they (as is likely) infringe.

It will be a few days before all the key players make clear how they are going to respond to Apple's legal attacks. It's a fight that is likely to get fairly nasty given the stakes involved. In the meantime any pretence that Apple are a company that is friendly towards free software is should have demolished by their action yesterday.