rlnorthcutt

We recently added our domains to the "HTTP Strict Transport Security" preload list, and I had no idea this was even a thing. I assumed that the best we could do was to enforce HTTPS at the CDN/network level.

Anyone can add their own site or domain to this list, which enforces HTTPS at the browser level (for supporting browsers).

Honestly, I think that is the key. He didn't just create Git out of thin air... he spent alot of time thinking about what he wanted and using something that gave him a conceptual foundation.

10 days of writing code is impressive, but there would many,many days of thinking that preceded it.

Oh sweet - I added that link. Thank you!

Lol - thanks... this was just something I wrote quickly.

Or, I meant that this was yet _another_ heart attack waiting in line? Kidding...

No kidding

I went down a bit of a rabbit hole the other day, and put together some quotes from Linus and some info on how and why Git was created.

True - but not every project is a product. I run across open source projects all the time where the README is the product page. In those cases, I appreciate some images which can help me figure out if I want to try it out.

Otherwise, I have to install or set it up just to preview it, and I will personally not do that most of the time. So, I appreciate some images when they help me evaluate the project.

I totally agree - moderation is a good thing

My apologies - it was a quick comment between calls :D In full disclosure, I'm the Head of DevRel at Appsmith. I didn't write this article, or contribute to it.

That being said, I do think its helpful, and I like the fact that other projects' READMEs are noted as good examples too.

This really stood out for me: 'We also think it is beneficial to show instead of tell wherever possible. We recommend using icons, images, and GIFs to keep it visually engaging and provide visual signposts — helping readers quickly navigate to the details that are important to them.'

We know that things like bulleted lists, headings, and paragraph structure can have a massive impact on readability... and I think those visual touches go even further.

Of course, just using icons doesn't do anything (And can make it worse), but if they are relevant, then it adds another layer of data. +1 on images and Gifs - I find it much easier to evaluate a project if I have some idea of what it looks like (Assumign it has a UI).

This is something I've always struggled with in my projects - by the time I'm ready to share it, Im' usually mentally tired and it is tough to create a good README.

This is a solid guide that lays out the sections and the thinking behind how to structure it. There is also some analysis of great README files in popular projects like NPM.

One of our team members wanted a better way to track OpenAI usage and costs, and he discovered a "hidden" API that provides this data. So, he wrote up a quick tutorial and created a custom app template to let others quickly test this out and create their own dashboards.

This type of knowledge is far more valuable than many people realize. When you see people who get things done, get more raises, or seem to do great work without working so hard... then they know things about how to operate in the organization.

That's a really good point. Humans generally don't like big changes, so removing friction to a big change makes it more likely. While remote work might make it a bit easier to fire someone, it totally makes it easier to leave.

Factor in that with the boomers retiring, the workforce is much smaller, especially among those with more experience. Unemployment is expected to stay low for some time (in the US at least), which means workers have more power. This is especially true for work that requires more experience or education. Those roles will be harder to fill overall, and the expected outputs are higher.

As a person working in a fully remote, global company... and as a hiring manager, I can attest to the challenges in hiring and maintaining a remote workforce. Hiring is tough, but keeping employees is also tough... because it is so easy to leave in a time of low unemployment.

This is a fun video, but also a really great example of agile development.

The creator shows the stages they go through from creating the domino mechanism and modifying the design with each new stage of development. There is a clear progression from the simple basic idea (domino on a hinge), to the full working model.

Yet another great example of how much of our world is powered by unsustainable practices. These are credit card solutions that provide value today at a much higher price tomorrow. The sad thing is that we already know how to address these issues, and instead of encouraging, educating, and improving those processes we are doubling down on the things that are making the system more brittle.

100% on this. Most startups are limited in resources, and even more so for opensource. Building a business means setting expectations and being clear on the scope of support. This is more than appropriate for a new product.

Personally, I would rather have a warning that FF "may" have issues, than no warning at all. Nothing is stopping a user form using FF if they want, and now they have a heads up.

As a long time open source user and contributor, I find it disappointing when some people can become entitled and complain about free software that doesn't exactly meet their expectations.

As mentioned elsewhere, the fact that it is open source means that anyone can potentially contribute... so if it is a large issue, then there is nothing stopping folks from trying to solve the problem themselves.

One thing that Appsmith does is to offer Google and Github SSO for the open source version, and then SAML, OIDC, OAuth2 for the business edition. It can be very difficult to figure out where to draw the line, but I think looking at the needs of the individual developer vs a business team of devs is a good start.

Can you expand on that a bit more? Do you think that more open source business models will lead to more rehashing of the same code/concepts over an over again?

I'm also curious how you think this may apply to the rise in AI coding projects. In theory, it will become possible to create complex software by simply describing it well, and much of that code from the AI training is open source.

While I think it is important to share new projects and even brag a bit about our own, I'm not clear on how this adds to the conversation? Illa has been mentioned multiple times here, so at this point it feels a bit spammy. As a developer, I feel like a little bit of self-promotion goes a long way. Hope this helps.

I really appreciate you taking the time to share! The inclusion of the Appsmith name and license on the code used is a great example of how we can be more transparent and ensure proper attribution. Clearly, your team has given careful thought to this topic as well.

There are always so many ways to solve problems, and lots of approaches that are optimized for specific users, tech stacks, industries, etc. Personally, I find so much more value in the exploration of new ideas and different decisions (as you have done) than simply being a "clone" of another tool.

As we move more into this new space, the ability to share libraries and integration patterns could be super useful for us all. I'll be sure to highlight that internally!

Open source is open source. There is nothing wrong with using and reusing open source code as long as it is within the bounds of the license. We have a permissive license for Appsmith on purpose - we want to share and inspire!

My question here is more about IF or HOW we, as a community, should improve how we reuse or extend open source code for commercial projects. I am very open to hearing all ideas - thanks.

Wow! It is great to see another low code, open source platform being launched. I’ve been involved with open source for over 25 years, and I am a big believer in the power of open source to accelerate development and empower people all over the world to build amazing things. I have built a career on OSS, and millions of others have as well. It is a game changer.

In full transparency, I am the Head of DevRel at Appsmith, which is an alternative tool to Open Blocks, and a source for some of Open Block’s code (https://github.com/openblocks-dev/openblocks/search?q=appsmi...).

However, that is not really what I want to discuss here.

As long as I have been involved in open source, I have dealt with FUD about OSS from investors, executives, and business people who don’t “get it”. These folks have usually been highly resistant to open sourcing code or making contributions because they think it will hurt the business. “Why would I want to share code that can be used to compete against us?” This could even apply to a young engineer or maintainer of a growing open-source project who’s deciding to startup and thinking whether to build an OSS company.

We have seen a huge boom in open source business models, and this is a GREAT thing. But, what can we do to ensure that we don’t prove the naysayers right?

My concern is that as we see a rise in competition among open source businesses, we will also see a rise in competitive businesses (open source and proprietary) that use previous work to accelerate their advantage… which is one of the central features to open source.

But, in theory, open source also has advantages for those who provide code - attribution, contribution, funding, shared resources, etc. There are also different licensing models that have strengths and weaknesses. We decided to go with a permissive license so that people can use Appsmith in all environments, and sometimes this works against us because competitors can build on top of Appsmith. But hey, that’s the nature of the game right?

So - what can we or should we do as a community to ensure that open source business models can be successful without tarnishing the reputation of open source in general? Should we be more clear with attribution? Should we partner and make shared libraries for common functionality? Maybe do nothing? What do you think?

You have a good point about enterprise requirements and the challenge of wrapping an SLA around open source which is entirely or primarily made from community contributions. I ran into this all the time when I worked at Acquia which provides a platform for Drupal.

One thing to note - proprietary does not necessarily mean it is any safer or more stable than OSS. Superblocks is actually a closed source fork of Appsmith, so the code is very close to the open source version, but now it is not visible.

In my experience, proprietary vs OSS is not the issue, but maturity and support.

Most newer software either has undiscovered bugs, or develops them as they grow and become complex. More mature software tends to be more stable in general, and OSS projects with commercial backing tend to have the resources (and incentive) to focus on security and stability.

This is why I am so interested in the explosion of Open Source business models. In theory, it provides a more stable product and commercial support, while still being transparent about its code and being open to community contributions.