Project governance

[jpbourgeon]

It's a bit early in the project lifecycle, and techies aren't always keen on these topics so feel free to close this thread 😉. However, I find it best to talk about them quickly to avoid the complexities of migration, if we find success later.

• License
• Website and social network
• Github organization

[jpbourgeon]

License

To make the project sustainable, we must define its limits from the beginning, including on a legal level. I think we want to maximize useful contribution and limit non-contributing forks or the temptation to plunder our code. I suggest changing the MIT license to a less permissive one. This will be an added incentive for code feedback (AWS uses Apache v2 for its SDKs, and if we're looking for systematic PR of improvements, GNU GPLv3 is a good choice).

[sam-goodwin]

Not sure what's wrong with MIT. What's the harm in being maximally permissive?

[jpbourgeon]

• One should use the MIT license if they want to make it easy for others to use and contribute to their project. This is the most suitable for small projects and pieces of reusable code / POCs, etc.
• One should use the Apache v2 license if they want MIT advantages, and at the same time to ensure that their project remains open-source and free while also protecting themselves from potential patent lawsuits.
• One should use the GNU GPLv3 license if they want to ensure that any derivative works of their project remain open-source and free.

I personally think that Apache v2 is better suited than MIT in the specific case of itty-aws.
Adopting the Apache v2 license does not change the freedom granted to the library users but it provides legal safety to the maintainers and contributors. It also requires that anyone who uses the software acknowledges its origins and cannot claim it as their own. Both statements are good for growing the project community, at no cost.

Ultimately, the license states our intention toward the community. Is it "take this code away" (MIT) or "let's build this code together" (Apache v2)? MIT harms in a sense that it doesn't encourage people to contribute.

[sam-goodwin]

I'm not against using Apache 2.0. My understanding was that MIT was just as good and didn't think anyone would worry about the lib because of its license. It's not really something worth copying - the value is there being one library.

[jpbourgeon]

I hope I have succeeded in conveying the key points that justify going beyond the MIT license.
It's not that MIT is inherently bad; I find it very valid. Rather, it is a matter of considering, which is best for this project, should it be successful.
In any case, the subject is certainly not a priority at this stage :-)

[jpbourgeon]

Website and social network

We need contributors. Let's build a very basic communication strategy to attract them:

• a github landing page and a blog to tell our discoveries
• a simple social network strategy: dev.to/twitter/mastodon

[sam-goodwin]

For this, we can start with my twitter at least. That's where I was originally pumping it :).

What I think we need most is a short list of features that matter most. E.g. S3 is a big one. SQS, SNS. These are kind of difficult as we'll have to hand write some code for their protocols.

It would be worth pushing once we at least cover the majority of use-cases.

Or, if the goal is to attract contributors to help build those pieces, let's start by blogging about your performance benchmark. Show the benefits!

[jpbourgeon]

Github organization

To create a sense of belonging, to gather a strong community of reliable contributors and maintainers, it is good to create a common banner. In this concern, it would be a good complement to host the project in its own Github organization to attract volunteers. It's a little early to talk about it, and at the same time migrating a repo after it's been widely released is tedious...