Many startups today open source their products. But it’s not just startups: Microsoft open-sourced VSCode and GitHub Copilot; Meta gave us React and LLaMA; Google opened up Android and the Chrome browser. All of them rely heavily on Linux – itself an open-source operating system.

So for many – especially startups building infrastructure or developer tools – building on open source, or open-sourcing their own product, might seem like the obvious, default choice.

But it’s not. Far from it.

How not to use other people’s open source projects

A year ago, PearAI (a YC-backed startup) forked VSCode and the Continue.dev extension, repackaged them, and presented the result as their own. The move sparked public backlash and led Y Combinator to issue an apology for mishandling the situation.

While PearAI’s intentions may have been good, their actions revealed a lack of understanding (or concern) about intellectual property. This was exemplified by their defense: “Dude, I ChatGPT’d the license. We’re busy building- can’t be bothered with legal.

Recently, another YC startup, Glass, made a similar misstep: they took an open-source project, changed the license, removed attribution, and claimed to have built it in just four days. Public backlash was swift once again.

The issue here wasn’t that they copied or reused the code – the license does allow that. The issue is that they changed the license to something else, didn’t acknowledge they weren’t the original authors, and again demonstrated a profound lack of understanding or care about it.

This “it’s open source, so it’s not stealing – who cares?” mindset from move-fast-and-break-things startups reflects poorly not just on the founders, but also on their investors. Both of these startups are part of YC, which now risks appearing as if it either doesn’t know – or doesn’t care – about intellectual property when it comes to open source.

How not to open source your own stuff

On the other side of the table are founders who open source their product without fully understanding the consequences.

Earlier this year, the author of ColorMagic complained that someone had ripped them off. And yes – if you open source your product, someone can take it, tweak a few things, and host it themselves (as long as they follow the license). Someone did exactly that, and the author was upset.

To make matters worse, the author didn’t even choose a specific open source license that could have protected them while still being open.

I get it – developers, designers, and founders aren’t lawyers. As a developer and founder myself, I can relate. But ignorance of the law isn’t an excuse for breaking it. Open source, in particular, works best when we all try to be good citizens of the community. And that means having at least a basic understanding of open source licensing.

Public humiliation for a two-month-old startup is a minor issue compared to what can happen later in your product’s life, especially if it gets popular or if you’re being acquired.

When licensing missteps come back to bite you

One of the things that prospective buyers will do is make a thorough technical and legal due diligence. This involves tracing the origin and ownership of all intellectual property in your startup.

If this kind of error is detected at that stage, it’s much harder to fix: there may now be years of work and thousands of lines of code done under an incorrect license, which must be retroactively applied. In the end, you might be forced to publish all of your own source code, potentially lowering your acquirer’s interest.

Another high profile example is ElasticSearch, which initially used a very permissive license, with the business model of selling a managed version of the database.

When they got popular, Amazon hosted a version on AWS, allowing it to get revenue without investing in the service development. ElasticSearch overreacted, switched to a non-open-source license, to the ire of many genuine open source users, which flocked to Amazon’s open source fork. ElasticSearch backtracked later, switching to a more strict open source license which does prevent Amazon from doing what they’ve done.

MongoDB and RedisLabs had the same model as ElasticSearch, ending in the exact same situation, with similar results.

Be a good open-source citizen!

When thinking about open sourcing your code, consider these questions:

• Why do you want to open source? What it is that you hope to achieve? You must have a good reason, not “everyone else is doing it”
• What if your competition just takes your code and uses/improves/hosts it? Does it matter? What’s your moat?
• Based on the above, how “open” do you want to be? (open source everything under a very permissive license (MIT, BSD, Apache) OR open source non-core or commodity parts of the code; keep secret source secre OR open source everything under a strict license, so that anyone using it must contribute code back to you (GPL, AGPL))
• Open source “eventually”, but not right now – constrain competition while being “almost” open source  (FSL, BSDL, SSPL)

When using 3rd party open source, especially for a core of your product, consider:

• What does their license require you to do? Are you required to open source your own code? Can you freely host and redistribute it?
• You’ll have many dependencies – how do their licenses mesh together? Some are known to be legally incompatible.
• Keep some kind of log – know which 3rd party code you forked or depend on, what are the licenses, so you can always trace the IP ownership
• Don’t “chatgpt” a legal document. Ask a lawyer, or at least find a template from a reputable source.
• Don’t invent your own license (“enterprise” or otherwise). Use a well known license that your customers will have easier time to evaluate as well.

The post How to Use Open Source Without Losing Your Code, Users – or Sanity appeared first on ShiftMag.

The Omnichannel Messaging for WooCommerce is a powerful plugin that directly integrates Infobip’s communication tools into WooCommerce. This enables you to deliver personalized SMS notifications, transactional emails, and targeted marketing campaigns – all from one platform.

The plugin was developed as a joint-venture between Infobip, a global leader in omnichannel engagement, and Neuralab, an agency with more than a decade of experience in building web / eCommerce projects (and a global WooCommerce Open Source Champion).


The goal is simple – to enable online merchants and WordPress/WooCommerce developers to automate marketing and omnichannel communication, which they truly need and deserve. The end result is combining the best of AI and human interaction – ensuring WooCommerce end users receive superior customer service.

Neuralab’s Kresimir Koncic stressed that this is especially important if you take into account that more and more omnichannel communication will go through “Gen AI” workflows:

All currently available platforms prioritize message sending, while data processing is secondary. Over the past decade, we’ve noticed a need for a more robust and functional platform, which led us to pivot towards Infobip’s enterprise solution.

Infobip has “data” at its core through the CDP (Customer Data Platform) module, and we believe this is an excellent foundation for building any subsequent functionality and interactivity that merchants should have. 

WooCommerce merchants will be able to send all their eCommerce data to the Infobip People platform, which can then power various Gen AI chatbots that communicate with users through Live Chat, WhatsApp, Viber, or any of the dozen channels.

Routing from AI to human

Merchants have always struggled with human agent costs, which is the main reason you don’t see 24/7 live chat widgets in average eCommerce stores. While financially challenging, this represents a missed opportunity because customer support shouldn’t be viewed as a cost center but rather as a revenue generator and experience enhancer.

Naturally, merchants or developers will want to deploy an army of robotic agents magically serving users – something akin to Star Trek’s ship computer. Reality is much “messier,” and we face complex technical and legal hurdles in integrating AI into automated omnichannel experiences. Kresimir points out that LLM models hallucinate and that that’s a feature, not a bug, and will not disappear:

Hallucinations are, in fact, inherent features of all implicit systems like artificial neural networks. Additionally, data source integrity is often questionable, which brings me to my main point. Merchants should leverage GenAI in areas where it’s most efficient – in open conversations and creative ideation.

Infobip’s “cautious” approach to GenAI tools enables switching specific chat functions on and off. For example, when a customer asks: “Which socks go with these brown shoes?” – AI can shine in cross-selling and user engagement. But when it comes to specific questions about refunds, discount policies, or shipping – traditional IF/ELSE bots or, better yet, human operators should remain the norm. The Infobip platform enables “routing” in both scenarios.

The robot can redirect the conversation to a human agent within Infobip’s product or to an external third-party contact center or CRM.
 
Our vision for the Infobip-WooCommerce integration is to combine the best of AI and human interaction, ensuring WooCommerce end users receive superior customer service. The latest partnership between Infobip and SplxAI, which enables automated “Red Team” checks, is a perfect operating example of how to guardrail Gen AI conversations.

What do developers and agencies get with Omnichannel Messaging for WooCommerce plugin?

The first version of the integration covers basic functions that WooCommerce merchants and developers can utilize through four main modules:

• Communicate with customers via SMS channels in automatic (e.g., order status changes) or manual mode (if there are product or order issues)
• Utilize Infobip’s vast network of email servers to increase message deliverability, crucial for UX, spam prevention, and legal obligations toward end users
• Integrate Infobip Live Chat solution into their store and connect with GenAI Infobip systems (currently a manual process through WP theme, but we’re working on automation integration for future versions)
• Most importantly, export customer data from WooCommerce to Infobip “People” CDP and use that data for various marketing automation

What’s next?

The 2025 Roadmap for the Omnichannel Messaging for WooCommerce plugin will be announced soon, but it’s been mentioned that it will include improved and automatic sync between Infobip and WooCommerce, new channels such as RCS, Telegram, and WhatsApp for a truly omnichannel experience, and more marketing automation options.

The post Meet the Omnichannel WooCommerce Plugin Developers Need and Deserve appeared first on ShiftMag.

If you’re a tech enthusiast or an open-source advocate, you’ve likely encountered the term #wpdrama. But what exactly is it, and why has it caused such a stir in the WordPress community?

In short, Matt Mullenweg, co-founder of WordPress, criticized companies like WP Engine for benefiting from open-source software without contributing back.

It’s not the first time a company has been accused of exploiting open-source contributions, but the way Matt addressed it sparked significant controversy. Open-source contributors face these issues day in and day out. Articles have already been written on this topic (to name a few).

What is dramatic is the way this was addressed. The argument was framed as he went against one specific company, and his actions called all the good things he has been doing for the WordPress community into question.

In the end, as the song says, It’s all about the money.

The Contributor Effect

At the beginning of this #wpdrama, I was just reading the news, checking the Twitter threads (yes, I’m still calling it Twitter), and watching it all unfold in real-time. It was scary to see one man going against every sound advice people were giving him. This resonated deeply with me because I, too, am a long-term contributor to WordPress.

Even though I’m not as active in the WordPress community as I was a few years ago, I still hold the community in my heart. It is what drew me in. WordPress was my ‘gateway drug’ to programming.

I started working with WordPress in 2014 at my first job. Soon enough, I realized that the software is more than it seems. I found out there are thousands of people writing the code and trying to make it better. Not only that but there are people organizing meetups and conferences, bringing people together who feel passionately about the project. A lot of popular open-source software have similar communities, but I don’t think that any has the scale of the WordPress community.

And it is that community that makes you go back to contributing. There is a sense of accomplishment when you see your name in the credits of a major release. I went from reviewing WordPress themes to being a representative of the themes team to a member of the WordPress Coding Standards group. I’ve organized local meetups after a long time of hiatus. During my time as a contributor, I met dozens of amazing people from all over the world and I call them friends now.

Seeing all this happening was a bit disheartening, partly because it confirmed why I slowly stopped actively contributing.

The price of the contribution

In 2019, I met Matt at WordCamp Berlin to discuss issues related to theme reviews and their role in the community. The meeting left me feeling like I was talking to a politician – vague answers and no concrete solutions.

In a sense, Matt is like a politician—never giving straight answers. And I can understand him. He cannot promise to solve everybody’s problems with WordPress.

Not because he cannot or doesn’t want to. The reason is quite simple—besides being a co-founder of WordPress software, he is the founder of Automattic, a parent company of WordPress.com, a hosting platform for blogs and websites powered by WordPress software (I can feel the confusion setting in). As a CEO, his mission is to have a profitable company. 

This was the gripe most people had when wanting to contribute to WordPress. It’s no secret that the direction WordPress software makes is the direction that is most beneficial to Automattic.

The introduction of the Gutenberg editor was seen as a response to competitors like Wix and Squarespace, which had already simplified page building for users. Despite its potential, Gutenberg received the most 1-star reviews on wordpress.org, highlighting the community’s dissatisfaction.

The alienation of contributors started a long time ago and culminated with the latest drama.

Giving your time and money with nothing in return is demotivating. This is what made me slowly stop making contributions.

The drama unveiled

At his State of the Word address at WordCamp US in Portland, Oregon, Matt Mullenweg decided to ‘go nuclear’ (his own words). He attacked all the companies taking advantage of WordPress software without contributing back, specifying WP Engine as the big bad guy funded by private equity firms. He went so far as calling them a ‘cancer to WordPress’.

You could say the pot is calling the kettle black, as several private equity firms fund his own company, Automattic.

We can agree that his company spends much more money on contributions than any other. Then again, they do have the most to gain or lose by supporting it.

However, the point of contributing is that it’s not all about how much money you bring to the table. WP Engine contributed by sponsoring numerous events and paying its developers to maintain free and paid versions of very popular plugins such as Advanced Custom Fields. We could play tit for tat on this one and end up being none the wiser. Ultimately, what about thousands of contributors who took their time and contributed but got nothing in return?

In the aftermath of his speech, it became public that he contacted them before the speech and requested that they give 8% of their revenue to Automattic due to a ‘trademark violation.’ His issue wasn’t just about contributing.

Aftermath

Soon enough, cease-and-desist letters started flowing, followed by Matt banning all members of the WP Engine engineering teams that maintained their plugins. This resulted in lawsuits and a hostile takeover of one of the most popular WordPress plugins, Advanced Custom Fields, under the guise of security.

It was an unprecedented move that proved that Matt has ultimate control over wordpress.org. In an interview with The Verge, he said that he owns wordpress.org (the site that hosts all the WordPress themes, plugins, and related services that power the WordPress community).

This one revelation, coupled with his responses on social networks, caused quite a stir among long-time contributors and enterprises that used WordPress as the basis for their web presence.

To be honest, it’s hard to say which part of this #wpdrama is worst. This could impact regular users, enterprise owners, or contributors.

In my opinion, one of the worst things that happened was the exodus of core committers—trusted and regular WordPress committers to the core software. Many prominent WordPress users stopped their contributions until this mess was resolved. 

The effects of this can be detrimental to the overall stability of the software. When you lose quality contributors to your software, you risk adding code that will do more harm than good. When you lose people who have worked on it for years and know its ins and outs, more and more subtle bugs creep in.

The #wpdrama saga underscores the tension between commercial interests and community contributions in open-source projects. As WordPress navigates these challenges, the community’s response will be crucial in shaping its future.

The way forward

We don’t know how these lawsuits will end. This is the first time we are seeing two massive players with lawyers who charge serious amounts of money engage in legal battles. 

This creates uncertainty for end users and, for regular contributors, fear of losing jobs and means of survival.

One thing is clear: the benevolent dictator-for-life model isn’t working. In an open-source community with such an impact on the web, we must have clear governance in place—a board consisting of trusted community members pushing the agenda that will benefit the contributors and the end users, not corporate interests.

The governance idea isn’t new. An initiative called wpgovernance.com aimed to implement guardrails against precisely what happened.

It may sound ungrateful toward Mullenweg, seeing as he was the person spending his company’s money to run WordPress.org. But with such a big impact, something like a PHP foundation could have been set up for WordPress instead. The infrastructure wouldn’t be dependent on one person but on the goodwill of the individual contributors and companies profiting the most from the project.

WordPress will have a great future only if we figure out how to change this at a structural level and take back the community.

Only time will tell.

The post How to Scare your Contributors Away: A Veteran’s View on the Platform’s Turmoil appeared first on ShiftMag.

Instead of being replaced by AI coding tools, developers are increasingly integrating AI into applications and engaging with AI projects on GitHub.

According to GitHub’s latest report, Python surpassed JavaScript as the most popular language on GitHub, reflecting a rise in data science and machine learning. Developers are rapidly building AI models and engaging with AI projects on GitHub. They’ve also noticed an Increased interest in AI agents and smaller models that require less computational power.

1.4 million new developers globally joined open-source projects on GitHub, with a majority of them contributing to commercially backed and generative AI projects. 

In 2024, there was a 59% surge in the number of contributions to generative AI projects on GitHub and a 98% increase in the number of projects overall.

There are more developers than ever

The data also shows the rise in the number of developers suggesting AI helping more people learn to code and build software. The number of people actively contributing to GitHub projects is particularly expanding, especially in regions like Africa, Latin America, and Asia, with significant growth in first-time open-source contributors. Brazil’s developer community is growing fast, and India is expected to become the world’s largest developer population on GitHub by 2028.

Python on the throne

Python is now the most used language on GitHub. The rise in Python usage correlates with large communities of people joining the open-source community and with the rise in machine learning and data science projects.

Systems programming languages, like Rust, are also on the rise, even as Python, JavaScript, TypeScript, and Java remain the most widely used languages on GitHub, the report says.

The post Python overtakes JavaScript as the most popular programming language appeared first on ShiftMag.

A US District Court judge in San Francisco has dismissed most of a class-action lawsuit that challenged the legality of GitHub’s use of code samples to train its AI-driven coding assistant, Github Copilot.

The suit was filed by Matthew Butterick, a lawyer and open-source programmer, and Joseph Saveri Law Firm, InfoWorld reports. It claimed that GitHub’s training of the Copilot AI on public GitHub code repositories violated the rights of creators who posted code under open-source licenses on GitHub.

The law firm made the suit and all the documentation public and claimed that it represented the first major step in the battle against intellectual property violations in the tech industry arising from artificial intelligence systems.

Despite Microsoft’s protestations to the contrary, it does not have the right to treat source code offered under an open-source license as if it were in the public domain.

However, the judge ruled that the plaintiffs had failed to establish that restitution for any unjust enrichment was available as a measure of damages for their breach of contract claims. The claim for breach of contract of open-source license violations against all defendants was not dismissed.

Software Freedom Conservancy, a non-profit organization that promotes open-source software, has been asking developers to quit GitHub for several years, and the launch of Copilot, an AI coding assistant, was the tipping point. They, too, considered GitHub to have violated its users’ intellectual property by training its models on their code.

In a blog post, the conservancy announced that it was ending all use of GitHub and will be offering a long-term plan to assist FOSS projects in migrating away from it.

The post Lawsuit against GitHub Copilot AI dismissed appeared first on ShiftMag.

If you have been in the open-source community lately, you know what I am talking about. The story goes something like this: There were loads of videos/blogs/events hyping up open-source contributions, mainly as a good gateway to land your dream software engineering job. And to some extent, it is true.

However, this trend has also brought a flood of pull requests (PRs) that contribute little to nothing or, worse, add clutter to the codebase.

And this is why, lately, you can find a wave of blogs and videos on why you should NOT contribute to Open-Source.

This article will show how bad it can get with the latest surge of unsavory PRs.

ExpressJS​

The latest drama has happened in the epxressjs GitHub repo. As you can see, there were loads of “Update Readme. md” pull requests.

This doesn’t immediately sound bad; perhaps the Readme was riddled with typos. It’s a long shot, but let’s investigate. Unfortunately, that wasn’t the case. Looking closely at some of these PRs, we will see the drama’s root cause.

So let us take a look… 

Maybe it’s just one bad apple? Well, let’s look at some others…  

As you can see, these PRs are not trying to improve the projects they contribute to. Although somewhat comedic, having lots and lots of such PRs is a nightmare for the project’s maintainers.

And the last one, I think, tells the bigger picture in this story. It seems that lots of these PRs were a learning experience (assuming “Collage” was a mistype of “College”). Although, that is an assumption made in good faith.

Some of them could have been done as a sort of shortcut for bolstering resumes, which is a far more alarming intent.

The missing puzzle piece​

Newcomers don’t understand that contributing is not all about the code. It is about investing your time in understanding the project and the issues it is trying to solve, being a part of the community and the discussion, and wanting to better the project because you want it to thrive.

And that is what is praised about open source contributions, the will to learn and the will to help. In the process, you demonstrate that you can be proactive and solve complex issues. That is what employers are really looking for.

One look at contributions like these, and you can be sure potential employers will ignore you.

Final thoughts​

Now, there were some external actors in the latest PR nightmare that I won’t be naming here because I doubt that they acted with ill intent. It’s the latest buzz, and I am sure that you can find them with a single Google search if you want to.

It’s important to mention that when considering contributing to open-source, start by looking at the projects you already use and are familiar with.

Alternatively, focus on projects where you have domain expertise, as sharing that knowledge can be a valuable resource for the maintainers.

Have you had any bad experiences contributing to open-source?

The post How promoting open-source can become problematic appeared first on ShiftMag.

These cases vary, but they all share a common thread: Flutter, an open-source framework created by Google in 2017, can be a better choice than native development and other cross-development frameworks. Let’s explore when and why.

Building high-performance, visually appealing applications with ease

A rapid development cycle becomes paramount for effective iteration during the development phase. Leveraging Dart’s compiler technology, Dart can be compiled, and by extension, Flutter, for multiple architectures. When an app is ready for production deployment, the Dart ahead-of-time (AOT) compiler stands prepared to compile them into native ARM or x64 machine code. 

The outcome? Excellent performance, ensuring the best possible user experience. On the other side, there is a just-in-time (JIT) compiler used during development which provides incremental recompilation (enabling hot reload), live metrics collection (powering DevTools), and robust debugging support.

Flutter’s hot reload feature empowers engineers to view the effects of their code changes instantly. Gone are the days of needing to restart the entire application with every code modification. This immediate update capability enables engineers to rapidly experiment with and refine their code, resulting in a more efficient and iterative development process.

In addition, Flutter distinguishes itself from other cross-platform solutions by not relying on web browser technology or native UI components specific to each operating system. Instead, it employs Skia/Impeller for rendering. In this regard, Flutter shares more in common with game engines like Unity than other cross-platform development frameworks. The diligent Flutter team has painstakingly recreated all Material and iOS (Cupertino) UI components for engineers to employ within Flutter. This is particularly beneficial for crafting custom UI.

Finally, Flutter proudly boasts its status as an open-source framework. This means that its complete source code is freely accessible to the public. Engineers can explore and contribute to the continuous improvement of the framework without incurring any cost. This openness fosters transparency, collaboration, and community engagement. 

Speaking of community engagement – the Flutter community of over 2 million engineers is thriving. Countless resources are readily available to assist engineers in mastering the full potential of Flutter. This growth is also evident in the increasing number of stars Flutter has garnered on GitHub and its popularity in Google search trends. In fact, Flutter has overtaken React-Native to establish itself as the most popular cross-platform development framework.

When to use Flutter and when not to

Flutter is well-suited for applications where there is no requirement for interactions with highly specialized native functionalities. It shines in applications heavily relying on networking and highly customized user interfaces (UI).

For example, Flutter is an efficient solution for building financial and health/fitness applications. It is chosen for its ability to create secure, visually appealing experiences across mobile and web platforms. It offers benefits such as the convenience of a single codebase for efficient development, quicker market entry, and easier creation of polished user interfaces, complete with interactive graphs and charts.

Flutter is also becoming a suitable choice for IoT projects because it’s starting to integrate better with platform-specific features like Bluetooth Low Energy (BLE). As the IoT space keeps growing, there’s a higher demand for IoT apps. We’ve noticed that more Flutter BLE libraries are emerging, making connecting and working with IoT devices easier. This was a big drawback for Flutter in the past, but it’s not so much of an issue anymore.

Also, perhaps a more curious use case for Flutter is using it for Minimum Viable Product (MVP) development. Its hot reload feature offers a rapid and cost-effective solution, enabling quick iterations and reducing time-to-market.

Deciding between Flutter and native development

If you want to streamline development and reduce the workload, Flutter is an excellent choice for small and large teams alike. If you prioritize fine-tuning and taking full advantage of platform-specific tools and features, native development is the way to go. It provides greater control over the user experience.

Deciding between Flutter and React Native

If your project has special design needs, pick Flutter. If it needs to look like typical iOS or Android, go with React Native.

Enhancing Flutter is a constant work in progress

Flutter has undergone a significant transformation over the years, evolving into a more mature and stable framework. This progress has been driven by a collaborative effort from the community, which has actively identified and addressed issues, resulting in a more robust framework. Google’s commitment to Flutter’s growth is evident through the consistent introduction of new features and capabilities, including improved performance, new widgets, enhanced tooling, and seamless integration with various platforms, to name a few.

For example, in recent notable updates, Flutter has introduced support for WebAssembly (Wasm), enabling more efficient code execution and enhanced performance. Additionally, Impeller now precompiles essential shaders during the Flutter Engine’s build, resulting in faster and more stable animations and improving the user experience. Also worth a mention is Flutter Add to App, which simplifies the integration of Flutter into existing applications, allowing for seamless cross-platform operation, albeit with potential development overhead in complex integrations between native components and Flutter.

More significantly, although it initially offered support exclusively for iOS and Android, Flutter has since expanded its reach to include web, Windows, Linux, macOS, and even embedded systems, as noted in the regularly updated Flutter release notes.

However, so far, our primary focus with Flutter at Infinum has been on mobile development. Our position is that while Flutter has made significant strides, there are areas in which it still has to catch up with web development frameworks like React or Angular. This discrepancy is expected, given their long-established presence, Flutter’s reliance on CanvaseKit, as well as Flutter’s limitations, like the absence of SEO optimization, occasional issues with hot reload functionality, and an overall mobile-oriented look and feel.

Tailoring the tool to fit the task

In the ever-uncertain future, especially within the AI app development landscape currently taking shape, our approach at Infinum remains – business as usual. We continue utilizing whatever tool best suits the job to develop high-performance, eye-catching applications for clients across various industries.

Resources for learning Flutter

• https://flutter.dev/
• https://www.youtube.com/@flutterdev
• https://flutter.dev/showcase
• https://github.com/flutter/flutter
• https://infinum.com/services/engineering/flutter/
• https://infinum.com/handbook/flutter
• https://pub.dev/publishers/infinum.com/packages
• https://infinum.com/blog/flutter-vs-native/
• https://infinum.com/blog/chatgpt-flutter-app/
• https://infinum.com/blog/charts-in-flutter/
• https://infinum.com/blog/flutter-embedded-device/
• https://infinum.com/blog/flutter-might-be-your-technology-of-choice-for-mobile-in-2020/
• https://infinum.com/blog/flutter-color-schemes

The post Why use Flutter in 2024 appeared first on ShiftMag.

Maximum customizability, data ownership, and prevention of vendor lock-in are the usual benefits of WordPress and are among the main reasons for web development agencies to pick it as their tech of choice.

However, these valid arguments miss two crucial points, according to Krešimir Končić, co-founder of web development and design agency Neuralab. The agency recently participated in WordCamp Europe (one of the many celebrations of WordPress’s 20th birthday) and brought home one of the “Open-Source Champions” awards.

All great reasons to catch Krešimir and hear his opinions on the impact WordPress has had so far, what lies ahead, the ins and outs of creating award-winning open-source communities, and, of course, the opportunities and challenges of open-source software in general.

OS code is rigorously tested across various use cases

The first often missed point, he believes, is that describing WordPress, or any other open-source software, as free is a significant misdirection and undersells its actual value. In his view, the real advantage of a system without hefty perpetual licensing costs is the ability to allocate the entire planned IT budget towards one critical aspect: creating a polished and meaningful user experience. Krešimir emphasized investing in high-quality copywriting, custom user interfaces, content architecture, proper user flows, and any necessary custom frontend or backend code.

In his opinion, open-source projects provide an “architectural peace of mind,” allowing teams to concentrate on user-centric challenges and building solutions that genuinely meet users’ needs.

The second one, Krešimir pointed out that open-source code has undergone rigorous testing across various servers, deployment processes, implementations, agencies, freelancers, enterprises, and volunteers. He believes that this extensive testing and collaboration are something that proprietary software solutions can only dream of achieving:

Take Gutenberg editor, for example – it’s currently written, optimized, and maintained by over 1,060 developers or contributors. That’s a lot of quality assurance eyeballs, and this is the production power of open source.
Clients and investors usually don’t care about this argument, which is ironic because they later always shout, “Hey, our new web admin is awesome. It just works.”

How to build and foster a community?

In 2010, when WordPress’s market share was significantly smaller, Neuralab embraced the platform’s potential. During this era, Neuralab passionately championed WordPress as a viable solution during this formative period. Agencies, product developers, and freelancers, like Neuralab, played pivotal roles in educating clients about the benefits of open-source solutions.

The widespread adoption of WordPress in both enterprise and SMB contexts was essential for attracting meaningful contributors, as projects needing more active contributors often faced abandonment. As time progressed, Neuralab expanded its involvement in the WordPress community by organizing conferences and meetups and hosting a series of WooCommerce and WordPress meetups.

Krešimir also shared his company expertise through lectures on various web development topics, contributing valuable knowledge to the WordPress community.

Winning Automattic’s Open Source Champion award represents a significant achievement for Neuralab.

One notable community-building initiative for Neuralab is their e-commerce podcast, Nominis. Another significant community pillar for Neuralab is its involvement in local WooCommerce meetups. Furthermore, Neuralab actively contributes to the open-source community by regularly publishing essays and columns across various media outlets. They tackle industry-related issues head-on and emphasize self-criticism while advocating for how the broader web community should address civic matters. Accordingly, Krešimir especially points out:

We don’t shy away from problems, so we try to double down on self-criticism and present how the web community should address civic issues. This has piled into a small library of topics, so I’m writing a book titled “Coding is the Easier Part” with a similar tone.

The importance of owning and controlling your data stack

WordPress has undergone significant evolution over the years. When considering the future of WordPress as a content management system and its role within the broader tech ecosystem, Krešimir says it’s an understatement to label WordPress as merely a web-building platform. In his view, the WordPress community plays a pivotal role in shaping and advancing the web industry.

WordPress’s influence is undeniable, with a remarkable content management system (CMS) market share of 65% and an overall web market share of approximately 42%. Krešimir believes WordPress has effectively democratized publishing, enabling individuals and businesses to function as media outlets. Furthermore, he anticipates that WordPress will continue to “democratize creation” as Generative AI models seamlessly integrate into existing content publishing workflows.

Moreover, he points out that the WordPress community has been instrumental in educating the entire market about the importance of actual ownership and control over one’s data stack. WordPress was among the early adopters of integrating privacy controls directly into the native admin experience. While WordPress has made many other contributions to the tech world, Krešimir emphasizes some critical aspects:

Matt Mullenweg famously touted in 2015. that JavaScript is the future of the web and WordPress. He was spot on, as we now observe that JS is running under the hood of most modern applications and tools. This opened the world for headless web projects for React, Angular, Vue, etc. While one could spend endless hours weighing the pros and cons of “headless,” WordPress did impact adding these types of architectures into the web industry.

Boring is cool, innovation has to be meaningful

Looking ahead to the future, Krešimir expressed genuine excitement about the upcoming developments in the Gutenberg block editor. He anticipates the implementation of real-time collaborative editing functionality akin to the features found in Google Docs.

This enhancement promises to revolutionize content creation and collaboration within the WordPress ecosystem. Furthermore, Krešimir highlighted the impending overhaul of the entire WordPress admin interface, which he views as a long-overdue and essential update.

There’s a “but”, of course. The problem with large systems like WordPress is that once they get big enough, they must become stable, robust, and backward compatible:

Every engineer knows that this means less experimentation, which hinders developers, especially those who want to work only on the latest hype.
This is the most significant pain that either PHP or WP endures, and it’s one of the reasons why we as a community need to work on educating both ourselves and the market that “boring is cool” and that innovation needs to be meaningful – and not conducted just for the sake of unquestioningly innovating.

Toxic scorekeeping is not fair, nor realistic

From the point of view of the co-founder of the agency that extensively relies on open-source tools, the most pressing challenge of the OS community today is the question of how to sustainably fund and support open-source projects, ensuring they can continue to evolve and thrive. He framed this challenge as the critical issue of “who will pay for all the pipelines?” – financial resources, human capital, attention, and effort required to advance and maintain open-source code effectively.

From an ideological perspective, Krešimir suggested that the community should contribute back to open source. However, he acknowledged that the practical aspects of how and when to give back can be complex. He referenced Matt Mullenweg’s call for community efforts to allocate “five percent” of their energy toward supporting the system. For instance, if a team consists of a hundred developers, five of them should be consistently dedicated to working on WordPress core issues.

Addressing the challenge of sustainable funding and support for open-source projects, in Krešimir’s view, requires a collective effort from the community to allocate resources and actively contribute to the continued development and maintenance of open-source tools:

The problem is that “toxic scorekeeping” – as some authors have called it – is neither realistic nor fair towards open-source contributors. Take Neuralab, for example. We don’t allocate developers to work on WordPress core, BUT we assign developers to work on various integrations and modules that give rise to the whole ecosystem.

Our PM team is working tirelessly on meetups, working with clients, and educating the market – so how do you measure the value of this?

All in all, the problem of budgeting for open source software is one the most pressing concerns for modern society – as you currently have a tremendously extensive IT system that will fall apart unless Jeremy from Ding Dong (Texas) pushes a bug fix on his popular open-source JavaScript library.

Open-source software as a public good

He proposed that society should begin viewing open source projects as public goods, akin to essential infrastructure such as roads, trees, and water. While these public goods are often taken for granted, governments and non-governmental organizations (NGOs) actively manage, fund, and maintain them. Krešimir emphasized that a similar mindset should apply to open-source software to some extent.

This would involve recognizing the importance of these projects to the broader community and providing the necessary resources and support to ensure their sustainability. Secondly, Krešimir highlighted an issue related to budgeting and resource allocation within the open-source community. He mentioned that he closely monitors the Ethereum community’s approaches, particularly quadratic funding and Gitcoin grants, as potential solutions to this problem.

These mechanisms can serve as realistic budgeting tools for future open-source software endeavors. By leveraging these innovative funding models, open-source projects can secure the resources needed to continue development and maintenance while maintaining a fair and decentralized approach to support.

Terraform was sloppy and dishonest

Commenting on the recent controversy surrounding Terraform’s license change, Krešimir highlights that there are alternative strategies if the goal is to limit direct competitors and their commercial use cases. He pointed to Meta’s approach with Llama 2, a large language model, where they chose to open source it while requiring a special license from Meta if the model is used in an application with more than 700 million monthly users. This approach balances open-sourcing the technology and protecting against certain commercial use cases.

The lessons from such incidents revolve around carefully considering licensing strategies that align with the project’s goals and target audience. Open-source software creators should assess their options to protect intellectual property while embracing open-source development’s collaborative and community-driven nature.

The Terraform issue was a sloppy planning operation and a dishonest messaging case. Unity had the same problems, which they corrected based on the massive community outburst. Marc Whitten (Unity Create lead) wrote an apologetic letter toward the ecosystem and offered more granulated and thought-out license distinctions.

Unity crew even provided a calculator for estimating the tooling cost of your project’s success. Other OS projects could pick up this Unity story and learn from it – avoiding future licensing community fires.

Security and reliability: Open-source beats proprietary

In addressing concerns about security and reliability when using WordPress for client projects, Krešimir highlighted the inherent advantages of large open-source projects, which benefit from a vast global community of contributors, providing a high level of quality assurance.

All investors want to make their project as future-proof as possible, but here’s the thing – open source beats proprietary software at this game by a long shot:

Think about it: the worst end-game scenario of using open-source software is that you need to fork it.

The worst end-game scenario of using proprietary software is that you’re de-platformed and need to do a complete project overhaul. And all that on someone else’s dictated timeline.

The post On open-source as a public good, licensing missteps, and community building appeared first on ShiftMag.

Like most open-source enthusiasts, Eddie Jaoude got into the field completely by chance and as a hobby. Now, 15 years later, he first made open-source advocacy his full-time job and then scaled it to be his business as the founder of the open-source community Eddie Hub.

Jaoude’s motto is that there is a place in the open-source community for everyone so, as one of the keynote speakers at Infobip’s Shift conference in Zadar, he shared with developers his thoughts on why open-source is still relevant, how contributing to open-source can help them in their careers and what they (don’t) need to do become recognized and good contributors in the OS community.

Open-source helped me a lot to progress as an engineer, I believe it will help you too.

Collaboration, not code

However, Jaoude pointed out that not everything is about code but about collaboration. That’s why one person really can make a difference with their contribution, even though it often does not seem so from the start. He also stresses that the open-source community is full of amazing engineers, and that’s what meant a lot to him.

You have the opportunity to learn from great mentors and gain exceptional experience, he adds, explaining that the experience is all the richer because you get different perspectives from all over the world. Of course, it is also an opportunity to expand your network and accelerate your career.

Contributing to OSS is like brushing teeth

Eddie admits that onboarding is not the OS community’s strong point, but once you’ve done the basics, you can contribute – it doesn’t matter what level you are, because senior members will jump on board. The only thing important is that you start somewhere. 

That’s why Eddie can’t stress enough that the code is only part of the project and that the context of work and contribution is also very important. You can also make a difference by verifying existing bugs, reviewing pull requests, or opening questions when something is not working.

Jaoude is now a recognized and awarded OS contributor and advocate. Of course, the one question he always gets is how engaged one has to be to achieve that. Or how engaged a developer has to be in the OS to even be able to say they’re an OS contributor.

Eddie compares contributing to open-source to brushing teeth:

You don’t even think about brushing your teeth anymore, it’s become a habit. Although it is short-lived, it is very important and you do it every day…

It’s the same with open source – you participate little and often, but you have to be consistent.

How to choose a good project and start contributing?

Of course, there are challenges that need to be addressed, adds Eddie. He is aware that it is difficult for newcomers in the community to find projects that suit them – to develop at a speed that suits them, to use a tech stack that they know, and, after all, to be legitimate and active. 

Likewise, he notices that newcomers are often afraid of screwing something up, so he advises:

If you broke something in the code, congratulations, you probably found a bug and now someone will solve it.

How to be a good contributor to open source projects?

First and foremost, it is important to choose a good project. Eddie advises starting with projects and tools you have already used and are familiar with and looking for OSS initiatives related to them.
 Of course, GitHub search will be the main tool to do that, and as an additional piece of advice, he says that most first-issue projects are, in fact, not a good choice for a first project. Instead, refine your search and look for projects labeled as “good first issue”.

Getting involved in communities is also a good way to find a good project, be it related to a hobby, some idea, or technology. However, he notes, regardless of what you choose:

When you decide to become an active open-source contributor,  focus on one project and one community.

When deciding on a project, pay attention to several things.

First of all, is it contributor-friendly, or is the community generally friendly? Check if they have set guidelines for behavior and contribution to the project and how well they adhere to them.

A good trick for this is to check the pull requests and see the accepted and rejected ones. Those that are closed, and not accepted – open them and see why they are closed. You will learn a lot from the way someone was rejected: was it done correctly, politely, and with an explanation.

Browse, participate, automate 

There is always something that can be automated in the code, Eddie says. Plus, other project collaborators will love you even more if you get to grips with test automation.

When it comes to reviewing pull requests, Eddie warns against approving them blindly; that’s the fastest way to get you removed from the project. 

And when it comes to his advice on how to be a good and valued open-source contributor is the following:

1. Before you get involved, read the project’s contributor guide
2. Never use the main branch of the project, and do not make large pull requests 
3. Search for existing issues before posting new ones
4. No need to DM those who maintain the project as soon as you have made a pull request 
5. Don’t chase the green squares

The post How to contribute to open-source projects with Eddie Jaoude of EddieHub appeared first on ShiftMag.

We are announcing that HashiCorp is changing its source code license from Mozilla Public License v2.0 (MPL 2.0) to the Business Source License (BSL, also known as BUSL) v1.1 on all future releases of HashiCorp products. HashiCorp APIs, SDKs, and almost all other libraries will remain MPL 2.0, said the company behind the Infrastructure as Code tool Terraform in a blog post. 

Terraform is another one in a long list of developer tools that have started as “pure open-source” products but changed its license to Business Source Licence at some point.

In the blog post announcing the change HashiCorp’s co-founder and CTO Armon Dadgar says they’re just “following a path similar to other companies in recent years. These companies include Couchbase, Cockroach Labs, Sentry, and MariaDB, which developed this license in 2013. Companies, including Confluent, MongoDB, Elastic, Redis Labs, and others, have also adopted alternative licenses that include restrictions on commercial usage.”

Why the change to Business Source Licence?

 As Dadgar explained: 

There are other vendors who take advantage of pure OSS models and the community work on OSS projects, for their own commercial goals, without providing material contributions back. We don’t believe this is in the spirit of open source.

Armon Dadgar, HashiCorp’s co-founder and CTO

 Under the new license, HashiCorp states:

• End users can continue to copy, modify, and redistribute the code for all non-commercial and commercial use, except where providing a competitive offering to HashiCorp.
  
• Partners can continue to build integrations for our joint customers. 
  
• We will continue to work closely with the cloud service providers to ensure deep support for our mutual technologies. Customers of enterprise and cloud-managed HashiCorp products will see no change as well.
  
• Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches contributed to our products.

The OpenTF Manifesto

And just like licensing changes by other companies have done before, this one also prompted a backlash in the open-source community. The OpenTF Manifesto shares their concern that the BUSL license is “a poison pill for Terraform” that will cause the open source ecosystem surrounding Terraform to “dwindle and wither.” The initiative, signed so far by almost a hundred companies and several hundred several individuals, is also not happy about HashiCorp’s lack of communication with the community about the changes. 

They are particularly worried about the lack of a clear definition of what HashiCorp would consider a competitive service:

At every company you ever work at in the future, before starting to use Terraform, the CTO will have to think about whether HashiCorp could possibly consider you a competitor, now or at any time in the future.

( … )

Every developer at that company will have to wonder if they want to contribute back to Terraform, given there’s no certainty they’ll be able to use their own work at a future job.

 Although the BUSL license technically is an open-source license, this change has once again started a debate on the future of open-source software. Terraform would’ve never gotten the adoption it did or all the contributions from the community had it not been open source; they point out and list some of the vendors affected by change that have made significant contributions to the Terraform community.

The OpenTF manifesto stresses once again that every time an open-source company changes their licensing, it affects the whole community: 

Tools like Terraform don’t live in isolation: they are part of a large ecosystem. The same applies to Kubernetes, Linux, Go, or other major infrastructure tools.

Imagine if the creators of Linux or Kubernetes suddenly switched to a non-open-source license that only permitted non-competitive usage.

The CNCF (Cloud Native Computing Foundation) has posted a recommendation to its projects using Terraform to “switch to an alternative component”.

The post Is Terraform still open-source? Yes, but… appeared first on ShiftMag.