[HN Gopher] OpenTF repository is now public
___________________________________________________________________
OpenTF repository is now public
Author : cube2222
Score : 378 points
Date : 2023-09-05 15:00 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| chologrande wrote:
| I'm just skimming, but it looks like the docs are fantastic. I've
| spent some time with terraform internals, and this seems like a
| significant improvement for a dev looking to work with this
| codebase. Gives a great overview to get started. well done!
| cube2222 wrote:
| I'm not sure which docs you mean specifically, but most of the
| docs are fairly unchanged (other than trademark stuff) from the
| original repo, so if any of the docs improved, then to give
| credit where credit's due, the kudos should go to the Terraform
| Core devs.
|
| Disclaimer: Work at Spacelift, and currently temporary
| Technical Lead of the OpenTF Project, until it's committee-
| steered.
| MuffinFlavored wrote:
| Does anybody have a diff of what this code base looks like
| compared to the latest "good acceptable ok to keep using"
| Terraform license commit?
|
| I guess I don't really understand what had to be changed given
| the new license debacle/changes.
| fishnchips wrote:
| GitHub has this "compare" functionality - this gives you a diff
| between where we forked and the current "main" -
| https://github.com/opentffoundation/opentf/compare/8a085b427...
| [deleted]
| andersa wrote:
| This shall serve as a great example for why no reasonable company
| would ever use a permissive license for their main product again.
| JimDabell wrote:
| The whole point of permissive licenses is to permit this kind
| of thing. It sounds like you think every company out there
| choosing permissive licenses doesn't _actually_ want to be
| permissive. Has it not occurred to you that people choosing
| permissive licenses usually _want_ to be permissive?
| fishnchips wrote:
| > main product
|
| Well that's the core problem - what is the product here.
| Terraform Cloud and Terraform Enterprise are products for sure.
| They're not open source, though. Is Terraform a product? Well,
| it doesn't do anything on its own, it requires plugins
| ("providers") for anything it does. Plugins are developed _by_
| or at least _with_ third parties. It 's a gatekeeper of an
| ecosystem that at this point is a common good.
|
| Whether the ecosystem would exist without the permissive
| license and external contributions - really hard to say. But if
| your main play is to foster the growth of an ecosystem and then
| turn it into a product exclusive to your business, then I guess
| you should look for alternatives.
|
| (Marcin from OpenTF, private opinion)
| johannes1234321 wrote:
| > Plugins are developed by or at least with third parties.
| It's a gatekeeper of an ecosystem that at this point is a
| common good.
|
| While I guess that for many vendors they don't care whether
| it's open or not. For instance AWS. I doubt they truly care
| about it being open or not.
| fishnchips wrote:
| AWS probably doesn't care much for it being closed either.
| But the benefit of being open is that folks can
| investigate, report and fix bugs. For example, at Spacelift
| we found a fascinating corner case where an RDS DB could be
| dropped if the call to get its details resulted in a
| transient API error. We wouldn't be able to do it if the
| code wasn't open. I also believe that the AWS provider in
| particular gets quite a bit of attention from the community
| outside Hashi and AWS.
| t-az-f wrote:
| All the providers are still MPL licensed, however. Maybe
| I'm missing something, but what part of the license
| change for Terraform core prevents someone from
| investigating and fixing a bug in the AWS provider in a
| similar manner going forward?
|
| Even Terraform core remains source available and so
| 'community' users can still take a look at the source
| code and identify/report/fix errors.
| fishnchips wrote:
| Oh, the core license change is irrelevant here, and the
| providers are MPL.
|
| I was just responding to a comment on how AWS didn't care
| if the provider was open. IMO there's value for them in
| it being open.
| Pannoniae wrote:
| Although we are not _there_ yet, but if we don 't do something
| to change it, there will be a moment where it will be true that
| "no reasonable person releases anything under a permissive
| licence", sadly.
|
| Just see the latest serde "drama", where everyone disregarded
| the "no warranty" clause in the licence and loudly demanded
| changes/wanted to fork the project/etc.
|
| FOSS has a huge problem of expectations from both upstream and
| downstream. There are very common arguments about "I use this,
| you broke it/made changes I didn't like, so you are a horrible
| maintainer and person and you will have zero credibility
| forever". If anyone uses FOSS dependencies, they also accept
| the risk of future versions being different. No one breaks
| versions already released, this is always about future
| versions. Demanding the maintainers to make specific
| changes/not to make them for _your_ usecase is extremely
| entitled.
| capableweb wrote:
| If a company isn't ready to compete against someone/something
| that is using the code the company has written and published as
| FOSS, then yes, please do not use FOSS licenses for your "Open
| Source" product.
|
| One would think that the companies thought this through before
| publishing FOSS code, but seemingly there is a lot that didn't
| do that.
| sanderjd wrote:
| This is essentially where I have landed. I think these
| companies should have just used a license like BSL from the
| get-go, and I hope that the next generation of product
| companies will learn that lesson.
|
| But unfortunately I think the lesson they will take from this
| instead is "we should just build a SaaS with no source
| availability because that's way easier and source-available
| just makes people mad anyway".
|
| I think that's a shame.
| pknomad wrote:
| > I think these companies should have just used a license
| like BSL from the get-go
|
| I think that's the general attitude the software companies
| will have going in the future. Why even bother dealing with
| negative PR and push back against their ability to make
| money by going with FOSS? In hindsight, TF should have been
| released with BSL from the beginning.
|
| I am not a huge fan of Hashicorp changing its licenses for
| future releases but I am also skeptical of OpenTF's motives
| since their members have big financial stake in that
| decision.
| fishnchips wrote:
| > skeptical of OpenTF's motives
|
| Acknowledged, there are always self-serving motives
| involved. Generally things don't happen without a reason.
| But we donated the project to a foundation, and will over
| time build (and fund) a dedicated independent team who
| will follow their own vision and the community needs, not
| ours. So please judge us by our actions, not assumed
| motives.
|
| > their members have big financial stake in that decision
|
| I can't speak on behalf of others but to us at Spacelift
| it's less about direct financials (we are actually not
| directly affected by the license change!) and more about
| being in charge of our own destiny and product roadmap.
| hotstickyballs wrote:
| It should serve as a warning for companies who want to leverage
| the open source community but then do a rugpull
| ohad1282 wrote:
| I think it is reasonable for a company to start OSS and then
| change its license. But it indeed feels like a rugpull for
| all the contributors.
|
| That is why OpenTF is on its way to CNCF. To ensure it stays
| OSS forever.
|
| There is a difference between "true OSS" like K8s, OPA, etc
| and "temporary OSS" (backed by a company) like what Terraform
| used to be, Pulumi, GitLab ,etc. Those can be changed in the
| future.
|
| When developers chose OSS, they should consider if it is a
| CNCF OSS or a vendor backed OSS. What Hashi did is an
| important example.
|
| (disclaimer - env0 founder here, co-lead the OpenTF
| initiative)
| AaronFriel wrote:
| > Pulumi is true open source, uses the Apache 2.0 license,
| and does not and never will depend on BSL-licensed software
| in any way, HashiCorp owned or otherwise.
|
| https://www.pulumi.com/blog/pulumi-hearts-opensource/
|
| Disclaimer: the following is my own opinion as an engineer
| at Pulumi.
|
| Pulumi is true open source, with a relationship similar to
| git and the many SaaS services that layer on top of git to
| provide meaningful value.
|
| To contrast with our competitor, Pulumi relies on open
| source languages and protocols. We could not, even if we
| wanted to, change the Python license. Nor could we change
| our protocols without breaking our users and our growing
| ecosystem.
|
| That's the value of building on open protocols and standard
| languages.
| res0nat0r wrote:
| I suspect this project is going to consist of a very loud
| minority of folks. I'm working for a very large company right
| now and they've been mandating us to move all of our TF code
| to Terraform Cloud for the last year, and I've not heard a
| peep about this licensing issue. I'm assuming they're going
| full steam ahead and don't care about this issue. As long as
| the TF Cloud service is easy to use, still a SaaS so it's
| TF's problem vs the companies, and they allow a robust login
| / access pattern via OAuth / SAML, all is well.
| waynesonfire wrote:
| Probably a good idea to continue with that initiative.
| OpenTF is new. However, your CTO should contribute to the
| OpenTF effort.
|
| I would like to see more companies that leverage open-
| source contribute back to the very community that enables
| their value creation.
| joshpadnick wrote:
| OpenTF core member here. If you're comfortable opting into
| an ecosystem where most of the key products are offered and
| supported by a single vendor (in this case, Hashicorp),
| then yes, there are no licensing issues to worry about and
| basically nothing needs to change for now.
|
| But our philosophy at OpenTF is that users would rather
| participate in an open ecosystem where multiple vendors
| compete for their business. If you're not happy with one
| vendor, you can easily switch to another; competition works
| to make all vendors better.
|
| When we look back at this comment a year from now, I'll
| wonder how your company will feel about the responsiveness
| and new features they're getting from Terraform Cloud when
| the primary incentive to stay is not because you think it's
| the best product available, but because switching costs are
| so painful.
| res0nat0r wrote:
| Honestly, I think when it comes to the large companies
| I've worked for, they care more than anything else
| revolves around "support". 15+ years ago the my previous
| company was all Sun Microsystems based, owned millions of
| dollars in 880s, 6800s and even an E10K. They said Linux
| was off limits because they couldn't blame/call anyone
| when they needed "support", even when Redhat was already
| around.
|
| Eventually they saw the writing on the wall and moved to
| Linux systems and replaced all of the hardware, and have
| an enterprise RHEL subscription that we could call when
| needed.
|
| I think the story is going to be the same with the
| current company, mainly "who can we blame if there is a
| security incident, or get me a Hashicorp person on the
| phone if we have some kind of Terraform related
| production issue." Having this in place seems to matter
| more than everything else honestly.
| sanderjd wrote:
| I think you're both right?
|
| I have come around to the idea that it's good to firmly
| discourage this kind of late-in-the-game license change.
|
| But I also think that, on net, this episode will lead to
| fewer businesses choosing the open source model for their
| software, from the start. It just seems like playing business
| on hard mode to try to build an open source or source
| available product, when you can just build a SaaS and charge
| for it. I think this is really bad (I have a strong
| preference to not be stuck with opaque SaaSes for most
| things), and I'm not sure what incentive there is to try to
| find new business models, when you risk becoming public enemy
| number one amongst a big chunk of your potential customer
| base.
| [deleted]
| erinnh wrote:
| Would a non-permissible open source license somehow changed
| this?
|
| Not sure what you mean.
| managingahhs wrote:
| I assume that by reasonable you mean not one that will bait and
| switch their userbase.
|
| I'm all for proprietary companies not pretending to be
| opensource companies and actually using proprietary licenses.
| kstrauser wrote:
| It serves as a better example of why it's important to learn
| what FOSS means and implies before using those licenses.
|
| It _doesn't_ mean "everyone does our work for free and then we
| keep the profit".
| Pannoniae wrote:
| It also shouldn't mean "everyone leeches off our software for
| free, they get the profit while we get the maintenance
| burden"
| kstrauser wrote:
| Except you can't say they're "leeching" when they're using
| the software on the terms you offered it to them.
|
| I'd also love to know how much Hashicorp chips in to
| maintain the projects they build upon. For example, I'd bet
| the vast majority of Terraform usage is on Linux. Do they
| support Linux development? Do they support Go language
| development? It seems like the companies complaining about
| "leeches" (eyeroll) aren't the ones actually paying people
| to work on upstream FOSS projects.
| galenmarchetti wrote:
| I get what you're saying, but on a strictly legal
| standpoint, everything Hashicorp is doing is by the
| books...all previous versions of Terraform will remain
| under the old license and everyone can still use
| Terraform without fearing a future lawsuit, as long as
| they stick to those version. So no one made any legal
| missteps here, neither the users nor Hashicorp.
|
| I think its the ethical side, rather than the legal side,
| thats more complicated...the contributions from the
| community contributed to the Terraform "brand" that got
| bigger and bigger, and now Terraform is attempting to
| secure their monopoly on capitalization of the brand when
| previously there was an implicit understanding that the
| "brand" was open-source.
|
| However, you might also argue that there was an implicit
| understanding on Hashicorps side that the community
| wouldn't build directly competitive projects when they
| held the lions share of the funding on the
| contribution/maintenance side...
|
| I think the whole thing is pretty complicated - is
| Hashicorp leeching off of the contributors or are the
| competitive contributors leeching off of Hashicorp?
| Honestly I see both sides.
|
| The beautiful thing is that its totally legal and
| acceptable for OpenTF to do their own thing and continue
| Terraform under their own terms...so either way we get to
| see this play out :)
| kstrauser wrote:
| I agree that it seems to be an ethical issue rather than
| a legal one.
|
| I'm coming down strongly on the side of the users,
| though. Hashicorp chose the original license, and the one
| they picked is perfectly fine with the idea of someone
| else building off it. I mean, it was written by the
| Mozilla folks. They _want_ people to build off their
| projects and make a nicer Internet!
|
| Hashicorp could've used a different license if they
| wanted to. They deliberately chose one that gives users
| the rights to build on Hashicorp's work -- and yes, even
| to profit off it at a competitor. What I don't think HC
| has is the right to act shocked when others use the
| software under the terms they were allowed to use it.
| Pannoniae wrote:
| The major difference here is that they are not making a
| directly competing product to Go, Linux, etc. I find the
| word "leeching" appropriate because here, it's not simply
| someone building on Terraform to sell something else,
| they are selling a direct competitor to hashicorp's
| products.
| dralley wrote:
| In another era "building on X to sell something else"
| would be still considered "embrace, extend, extinguish"
| (in the actual, originally intended sense), depending on
| the market power of the players involved.
|
| At least if the "something else" isn't free software.
| lijok wrote:
| Could you explain how and why Hashicorp "get the
| maintenance burden"?
|
| Surely, if maintaining it was such a burden, Hashicorp
| could just stop maintaining it?
| Pannoniae wrote:
| There is a difference between maintaining something, and
| maintaining something for your competitors. The second
| one can reasonably be described as a burden IMO.
| paxys wrote:
| That's a good thing. Either launch a closed proprietary product
| from the get go or commit to maintaining a real open source
| project. You can't have all the monetary advantages of the
| first while enjoying the goodwill and community support of the
| second.
| sanderjd wrote:
| This attitude will just lead to pretty much every product
| being closed and proprietary. Which sucks for me, because I
| like to be able to read the source and run modified versions
| of tools I use, and have no interest in creating competitive
| derivations of them. So I think it's a shame that people who
| try to make software like that get pilloried for being
| neither proprietary enough (which is apparently fine...) nor
| open enough.
| nexawave-ai wrote:
| [flagged]
| _joel wrote:
| Good to see, waiting on
| https://github.com/opentffoundation/roadmap/issues/8 so can do
| some testing (yes can build from source, but I'd rather use the
| releases)
| bastardoperator wrote:
| Nice, on a total side tangent, the logo looks fairly awkward in
| dark blue against a dark background. The white stroke also isn't
| bold enough so it looks very pixelated when also combined with a
| dark background.
| dentalperson wrote:
| Definitely bikeshedding, but it also kind of looks like the
| TensorFlow logo and for a second I thought there was a group
| breaking the project free from Google.
| razbensimon wrote:
| Great work everybody! Env0 developer here
| wkat4242 wrote:
| Open TeamFortress?
| galenmarchetti wrote:
| I think this whole process has been beautiful. Hashicorp was well
| aware that licenses are tagged to versions of projects rather
| than the "project" itself, and used that to its advantage as a
| business to start maximizing profits to its enterprise offerings.
|
| The community was well aware that once you tag a license to a
| version, you can't undo that. And they're well aware that they
| can fork from that license forwards and build their own "new"
| project, version by version, that stays open source.
|
| This is going to be fascinating to see play out, and I think a
| case study in software licensing going forwards...can't wait to
| see how OpenTF does down the road.
| paxys wrote:
| There is no distinction between licenses tagged to "versions of
| projects" (whatever that means) vs the project itself.
| Hashicorp was well within their rights to change the license
| moving forward, and you or I or anyone else are within their
| rights to continue using an older version and fork it - which
| is exactly what happened here.
| hiatus wrote:
| The fact that you can continue to use an older version and
| fork it supports your parent's statement that the license is
| tied to a specific version. The new license only affects
| newer versions and can't be retroactively applied.
| paulddraper wrote:
| Yeah, but that's a weird way to put it. Meaningless truism.
|
| Copyrights are never not tied to a "version." There is no
| concept of "version."
|
| Copyright applies to a bunch of data. You have a copyright
| on a song. If you create a second song you can call it a
| new "version" of the original or not, none of this matters
| for copyright.
| paxys wrote:
| This is how all copyright and licensing works. There's
| nothing unique about Terraform. You can't go back and
| retroactively take away a permission that you granted
| someone.
| geerlingguy wrote:
| It seems closest to Hudson vs Jenkins split, in terms of
| community impact / response (though not on the licensing
| front): https://en.wikipedia.org/wiki/Hudson_(software)
|
| Oracle almost always seems to be involved in these things, but
| surprisingly not with Terraform :D
| arwineap wrote:
| Historically it may be interesting to look at the hudson /
| jenkins codebases
| mschuster91 wrote:
| Thanks! I'd ask for two things:
|
| The first is, please provide a standalone registry package for
| both modules and providers - the only I'm aware of is
| Artifactory, and I don't really feel like running _another_ big
| repository software in a Nexus shop.
|
| The second is related: please allow for easier forking of
| provider modules. The current workflow of either building locally
| and distributing binaries with collaborators that are manually
| copied _sucks_ or waiting for upstream to accept PRs,
| particularly if upstream wants CLAs signed.
| cube2222 wrote:
| Hey!
|
| > The first is, please provide a standalone registry package
| for both modules and providers - the only I'm aware of is
| Artifactory, and I don't really feel like running another big
| repository software in a Nexus shop.
|
| Could you expand on this? Do you mean you'd like a self-
| contained binary to run a private provider/modules registry? If
| that's the case, then there are some open source projects for
| that, and we've done a proof of concept of an approach in which
| you can distribute providers via OCI registries like DockerHub
| or the GitHub Container Registry[0] as those are actually
| perfect for the use-case.
|
| This PoC will be followed by a public RFC soon.
|
| > The second is related: please allow for easier forking of
| provider modules. The current workflow of either building
| locally and distributing binaries with collaborators that are
| manually copied sucks or waiting for upstream to accept PRs,
| particularly if upstream wants CLAs signed.
|
| Do you possibly have an ideal workflow in mind?
|
| [0]: https://twitter.com/opentforg/status/1696913055576387599
|
| Disclaimer: Work at Spacelift, and currently temporary
| Technical Lead of the OpenTF Project, until it's committee-
| steered.
| OJFord wrote:
| Btw, unless you mean to say '... But I'm commenting here in a
| personal capacity, not necessarily representative of the
| views/policy of the organisation', that's a claim, not
| something you're _dis_ claiming.
|
| It's sort of a disclosure (which is almost an antonym) but
| you're not acknowledging a potential bias, you're saying this
| is why you should listen to me/care to reply, so even that
| doesn't really fit IMO.
| mschuster91 wrote:
| > Do you mean you'd like a self-contained binary to run a
| private provider/modules registry?
|
| Yes, indeed. But it seems the problem more was _something_
| with Google 's algorithm, I swear a month ago this here [1]
| wasn't on the first page when searching for "terraform
| private provider registry".
|
| That also answered the second question.
|
| [1] https://github.com/outsideris/citizen
| daniel_ciaglia wrote:
| Here's another one for modules and providers
| https://github.com/TierMobility/boring-registry
|
| Disclaimer: I worked for TIER before
| Coryodaniel wrote:
| Citizen is great. Definitely recommend it. Really easy to
| get up and running locally for PoC w/ ngrok.
| tuyguntn wrote:
| why only Terraform? for some reason I was under impression that
| other offerings of HashiCorp will be supported by OpenTF
| foundation
| Bilal_io wrote:
| From the name OpenTF (Open Terraform) I assumed it's specific
| to Terraform
| capableweb wrote:
| The "TF" part could be anything! :)
|
| Open Technology Foundation is one suggestion.
|
| Backronyms are a thing people.
| joshpadnick wrote:
| OpenTF core member from Gruntwork here. All great products
| require focus, and right now our sole focus for OpenTF is
| creating the best possible truly open source and community-
| driven successor to legacy Terraform.
|
| I'd personally love to see an open source path forward on other
| products that Hashicorp re-licensed like Packer, but those will
| need to be a separate project and initiative.
| merb wrote:
| I doubt that there will be such things. Vault for example.
| Its unlikely that it gets a big backer or will be a cncf
| project.
| notpushkin wrote:
| I think Packer is a reasonable candidate for a CNCF
| project.
| Pet_Ant wrote:
| Presumably this: https://www.cncf.io/
|
| Cloud Native Computing Foundation
| thecosmicfrog wrote:
| > We're consulting with a couple of legal experts regarding the
| name, and it seems that even OpenTF won't be the final name due
| to use of "TF" in it.
|
| Interesting that having "TF" in the name could cause issues.
|
| Source:
| https://github.com/opentffoundation/opentf/issues/273#issuec...
| sluongng wrote:
| Isn't Tensorflow logo "TF"?
| jonfw wrote:
| Tensorflow isn't a direct competitor. My understanding (and I
| am not a lawyer) is that enforcing trademarks is based around
| whether or not a consumer could reasonably confuse the
| product with the trademark owners. A user wouldn't reasonably
| confuse tensorflow with terraform, but might confuse openTF
| with terraform
| blowski wrote:
| Tensorflow isn't competing with TerraForm.
| capableweb wrote:
| I'm guessing the issue is that it's obviously "inspired" by
| "Terraform" which shorthand is TF.
|
| My second guess is that using "Open" together with something
| that implies "Terraform" is also a problem, as Hashicorp
| might sue them for defamation, as that name would imply that
| Terraform is not "Open". I'm not personally against that, I
| wouldn't consider Terraform "Open" anymore, but I'm not sure
| a court would see it the same way.
| toyg wrote:
| The criteria for trademarks is not defamation, but
| confusion.
|
| Given a product TerraForm, known also as TF, how likely is
| it that a consumer would be confused into thinking "OpenTF"
| is made by the same people who make TF?
|
| That's the bar to clear. In the past, some trademark owners
| have been fairly lax, allowing unrelated "Open" versions of
| their software to be established. The classic case was "SUN
| OpenOffice", but I suspect they got away with it because
| "office" was not a wordmark - the trademark was for
| "Microsoft Office", which is very different. In a lot of
| cases, the "Open" versions emerged once the software was
| not sold anymore, so it was impossible to be confused.
|
| In this case, though, the software is still sold and likely
| carries trademarks and wordmarks. Unless OpenTF's pockets
| are deep enough for some serious lawyerin', it will be
| easier to rebrand.
| cstejerean wrote:
| I'm not seeing any trademark registrations by Hashicorp
| on TF, nor any mentions of TF in any of the Terraform
| marketing pages. Not to say that Hashicorp couldn't try
| to be difficult anyway, but it feels like at this point
| doing this would just raise the visibility of the OpenTF
| project.
| throwawayapples wrote:
| Terror Form has a nice ring to it.
| toyg wrote:
| Too similar to the original.
|
| On the other hand, _Terror Fort_...
| justsomehnguy wrote:
| Open Terror Front then, komrade!
| ohad1282 wrote:
| We learned that Word Mark is the potential issue here.
|
| Read https://en.wikipedia.org/wiki/Wordmark for more details
|
| (disclaimer - env0 founder here, co-lead the OpenTF initiative)
| halostatue wrote:
| Since this started, I've thought that they should probably be
| using xenoform instead of terraform (e.g., OpenXenoform and xf
| command).
| comprev wrote:
| OpenPC aka Open Planet Change
|
| "planet change" being an alternative to "terra form"
| paulddraper wrote:
| Kinda suspected this.
|
| AWS created OpenSearch, not OpenES.
| comradesmith wrote:
| OpenForme maybe?
| aidenn0 wrote:
| For a similar reason YP becane NIS[1].
|
| 1: https://en.wikipedia.org/wiki/Network_Information_Service
| dzogchen wrote:
| https://www.isopentfopenyet.dev/ is out of date! You had one job!
| Philpax wrote:
| ...why does a presumably static page need to store cookies?
| managingahhs wrote:
| Can Terraform become a CNCF project itself and that be the
| foundation it's tied to?
| lijok wrote:
| Unlikely to get accepted by CNCF (I would think). There's big
| movement by the cloud vendors to create IAC-first APIs. Once
| those APIs gain traction and the industry as a whole signals
| that that's the direction to go, we'll see a standard emerge,
| and a new general purpose tool get built that will replace
| Terraform and all of its providers. That's a few years away
| however, assuming that effort doesn't die down.
| cube2222 wrote:
| Hey!
|
| As many of you asked for, we've finally made the repository
| public and will continue developing it in public from now on.
|
| This took us some time, but you can now read our announcement for
| more details[0].
|
| Thanks everybody for the support so far, and I welcome you all to
| interact with the repo, join the discussion, or even contribute.
|
| A possibly noteworthy detail as it's been discussed on HN here a
| bunch, we've settled with the DCO[1] for contributions.
|
| Also, happy to answer any questions!
|
| [0]: https://opentf.org/fork
|
| [1]: https://developercertificate.org
|
| Disclaimer: Work at Spacelift, and currently temporary Technical
| Lead of the OpenTF Project, until it's committee-steered.
| Foxboron wrote:
| As technical lead for the OpenTF project, how does things like
| this get merged?
|
| https://github.com/opentffoundation/opentf/pull/36/commits
| lucasyvas wrote:
| Give them some time to figure out what merge strategy they
| want to enforce - it was probably overlooked as a repository
| setting and they probably clicked Merge instead of Squash and
| Merge by accident.
| Foxboron wrote:
| How does the merge setting solve the complete lack of any
| useful information in the pull request?
| sanderjd wrote:
| Your comments here should go in the textbook for "why
| people often prefer to work in private for awhile while
| zeroing in on their processes for a new endeavor".
|
| There will always be someone who will gleefully jump down
| your throat for imperfections.
|
| But on balance it's probably better to work in public
| anyway and ignore the haters (while also continuously
| improving processes).
| Foxboron wrote:
| Most people don't spend this much time on PR before
| releasing their fork though.
|
| If they had worked on this publicly from the start I'm
| sure a lot of the current PRs would have generally been
| of better quality as they could get community input
| earlier.
| sanderjd wrote:
| Oh I see now! Your comments about the merits of the pull
| requests are just bad faith; you're actually making this
| totally different point about the project that has
| absolutely nothing to do with squashing or commit
| messages. Thanks for clearing that up.
| Conan_Kudo wrote:
| It was definitely not bad faith. They're pointing out
| that OpenTF isn't bothering to hold to quality standards
| that Hashicorp had for Terraform before the fork and they
| aren't trying to raise beyond those standards to reach
| the levels common in higher quality community projects
| like Linux, Kubernetes, LibreOffice, and OBS Studio.
|
| A project being run by professional developers who have a
| lot of experience working with the Terraform code should
| be capable of doing this.
| sanderjd wrote:
| Well, I disagree that it's not bad faith.
|
| If your problem with a project is that it advertised
| itself to its target audience prior to releasing a
| repository, then a good faith comment would say something
| like, "My problem with this project is that they have
| spent more time writing manifestos and blog posts and
| social media comments so far than they have spent
| developing strong processes and working on publishing a
| repository for the project".
|
| But if that's your real problem with a project, then a
| bad faith comment might look like "This is a bad pull
| request, how could you let it get merged?". The reason
| that is in bad faith is that it says nothing about your
| actual problem with the project, it's just a totally
| random swipe that you don't even actually care about. If
| there turns out to be a good answer to the question, like
| "Oh you're right, we forgot to require squashing pull
| requests when merging, I've fixed it now!", then instead
| of recognizing that your complaint has been spoken to,
| you are likely to simply find further things to
| criticize, because the first thing wasn't actually your
| real criticism, it was just a smokescreen.
|
| Now, if _you_ are making this other, better, point that
| the OpenTF project should have more mature software
| development practices, at least equivalent to and ideally
| exceeding the better-known project they have forked from,
| then yep, I agree with that criticism and do not think it
| is necessarily being made in bad faith.
|
| _However_ , I would be significantly more sympathetic to
| that criticism if it were a comment on an article
| entitled "OpenTF project celebrates one full year since
| its conception" rather than one entitled "OpenTF
| repository is now public".
|
| The project is brand new, and they clearly rushed to get
| out a public repository because of _other_ haters who
| were giving them crap about taking too long to publish
| the repository, and their processes clearly haven 't
| matured yet. (Or I dunno, maybe it was even many of the
| _same_ haters, because again, this is the tendency with
| people who criticize in bad faith, to just move on to the
| next random criticism that they don 't actually care
| about.)
|
| So if we get to a year from now and their processes
| remain immature, then yep, I'm right there with you on
| your criticism. But I think it's crazy (and, sorry to
| keep repeating myself: likely in bad faith) to make this
| criticism of such a new project. There is absolutely no
| indication that the developers running the project are
| _incapable_ of having mature processes for the project,
| from the tiny amount of data available from the tiny
| amount of time that has elapsed since they announced the
| project.
| yjftsjthsd-h wrote:
| Things like what? That looks like a straightforward rename
| Reventlov wrote:
| Commit messages like "more", "rollback", "missed that" are
| not really what you expect from such an organization, so,
| yeah, that should've been squashed with a descriptive and
| useful commit message. My repos look like this but... I'm
| not a professional developer.
| linuxdude314 wrote:
| They are from this organization.
|
| The whole thing is a massive farce that's primarily a
| marketing push for a few companies that were too lazy or
| hostile to negotiate a deal with Hashicorp.
|
| I strongly recommend anyone relying on on "OpenTF"
| ecosystem project get back to mainline and ASAP.
|
| These groups have clearly demonstrated a lack of
| competency in execution, planning, strategy, and software
| engineering.
|
| If you take your production environment seriously, now is
| the time to run.
| fishnchips wrote:
| > were too lazy or hostile to negotiate a deal with
| Hashicorp
|
| And how do you know about any dealings any of us did or
| didn't have with them, now or in the past? Are you privy
| to any of that?
|
| > lack of competency in execution, planning, strategy,
| and software engineering
|
| One of my old bosses taught me a lesson. Any time you
| criticize something, you spend your capital. This capital
| is earned by building value, by being constructive. If
| you have any constructive feedback, now is the time to
| speak up or remain silent forever.
| OJFord wrote:
| I think that's exactly it, a 'straightforward rename'
| shouldn't consist of 20 commits with crap messages
| including 'missed that' (+ merge commit).
|
| But tonnes of people don't care about git hygiene or using
| tools well in general, GP's in for an exhausting time
| caring about it much in projects they're not in control of.
| yjftsjthsd-h wrote:
| I mean, I guess? Some people like small commits, and most
| of them looked reasonable to me (renaming one thing at a
| time); criticizing commit style seems like bike-shedding,
| anyways.
| fishnchips wrote:
| Good point, we should enforce squash merging.
| Foxboron wrote:
| It would be trivial to at least _continue_ the standards
| set by the terraform project. Now there are commits messing
| with `internal /backend` that breaks tests with the commit
| message "more".
|
| _Someone_ is going to hit this with `git bisect` and it
| wont be their lucky day.
| Groxx wrote:
| Anyone bisecting with a repo that uses merges should be
| aware of the `--first-parent` flag by this point.
|
| Or if not: you're welcome!
| fishnchips wrote:
| Fair point, I think we can fix that. Thanks for
| highlighting that.
| linuxdude314 wrote:
| [flagged]
| jefftk wrote:
| Be nice! They're just taking this on, and not already
| having sorted out whether they'll work with "all PR
| commits must have good messages and pass tests" vs "all
| PRs must be squashed" is the kind of minor issue you see
| with teams starting this sort of thing.
| joshmanders wrote:
| Ah yes, not having a compatible license that won't cause
| you legal troubles isn't why people pay for software
| its... _checks notes_ the commit messages used in a PR.
| laurels-marts wrote:
| There's a difference between constructive feedback and
| toxic. Your comment falls in the latter category.
| fishnchips wrote:
| I know that you're commenting in bad faith and if it
| weren't for commit messages, you'd have found some other
| reason to spew hate. But I know that your comment will be
| read by people who don't come with an agenda, so I'll
| give it a try.
|
| > Do you not see how it's problematic that you have these
| oversights?
|
| I do. We do. Note that none of the OpenTF folks
| downplayed it. We acknowledged. We will fix the process.
| We will move on. In my book, that's how mature people and
| organizations react. Mistakes are unavoidable, important
| is how you deal with them.
|
| The alternative I suppose would be to collectively fall
| on our swords because some committers from one company
| had a different style of working, and the tech lead from
| another company took his way of working for granted. I
| don't think we can continue living with this shame.
|
| > What reason would anyone ever trust your organization
| over Hashicorp?
|
| NONE! Don't trust us - watch us. Point out mistakes, too.
| Be a part of it, help us get better.
|
| > focused on PR (...) actual substance
|
| Like commits not squashed? What other substance are you
| missing from a spontaneously formed group that's been
| working together for a little over two weeks?
| cube2222 wrote:
| Even though you're being downvoted I do agree that this
| should've been squashed (I don't see any other problems here,
| if that's not it).
|
| I've made sure via repo config that only squash commits are
| enabled from now on, so this will not happen again. Thanks
| for the feedback!
| Keyframe wrote:
| Don't sweat much over it yet. Default / point people to
| something like merge into PRs, squash PRs when bringing
| them to main branches, and keep everyone follow
| https://www.conventionalcommits.org/en/v1.0.0/ for commits
| untill you find your way / more edge cases crop up and
| you're set.
| Faaak wrote:
| I'm sorry, but making only "squash commits" is also a bad
| idea. You can have a MR with multiple independent, atomic,
| commits.
|
| The "real" solution is making the developers aware of the
| issue and cleanup up their history before doing an MR.
| orra wrote:
| Absolutely this. A series of commits dealing with
| different aspects (e.g. whitespace fix, minor related bug
| fix, necessary refactor, then the feature) is ideal.
|
| For a start, it's easy to review, and easier to disect if
| something breaks.
|
| When messy git history is provided (i.e. a history of the
| developer fixing their own code that they missed),
| squashing can be a reasonable fallback. But it's never
| the best option, IMHO.
| timost wrote:
| I've found `git commit --fixup` and `git rebase
| --autosquash` to be very useful when accumulating fixes
| of previous commits.
| jenadine wrote:
| git-absorb is nice too
| alexchamberlain wrote:
| I couldn't agree more, but this is a discipline that is
| rare in my experience. With GitHub lacking fast forward
| merges, I've struggled to articulate why it's important.
| [deleted]
| Conan_Kudo wrote:
| GitHub projects can be configured to force fast-forward
| merges.
| alexchamberlain wrote:
| I just re-checked github.com, and the only options are
| merge commit, squash commit and rebase commit. Rebase
| comes the closest, but none of these are fast-forward
| merges. Worst of all: you can't disable the green button
| if you don't like any of them.
| mcpeepants wrote:
| The "rebase" option combined with the branch protection
| rule of "require branch to be up-to-date" gets even
| closer, in my experience
| jenadine wrote:
| Rebase don't work if the branch you want to merge
| contains itself merges (that potentially fixes conflicts)
| Foxboron wrote:
| The squash merge is not going to solve the lack of proper
| commit messages and the fact that things are breaking the
| test suite left, and right.
|
| Figuring out bugs with `git bisect` is not going to be a
| fun endeavour for people trying to understand incompatible
| changes.
| cube2222 wrote:
| > and the fact that things are breaking the test suite
| left, and right
|
| Branch protection doesn't allow merging without a passing
| test-suite.
|
| > The squash merge is not going to solve the lack of
| proper commit messages
|
| Could you expand? You choose a sensible commit message on
| squash, while the PR's commits become fairly irrelevant
| at that point.
| Foxboron wrote:
| > Branch protection doesn't allow merging without a
| passing test-suite.
|
| https://github.com/opentffoundation/opentf/pull/243
|
| EDIT: and just to point out. If you have 1 PR with 19
| commits that break the test suite. The last commit fixing
| it doesn't matter as you will be hitting one of those 19
| commits at some point during a bisect.
|
| >Could you expand? You choose a sensible commit message
| on squash, while the PR's commits become fairly
| irrelevant at that point.
|
| It's optional. Nothing prevents you from just adopting
| whatever the PR said initially. Turning it on doesn't
| automatically make it better.
| jefftk wrote:
| _> you will be hitting one of those 19 commits at some
| point during a bisect_
|
| But not if you merge the PR as a squash-merge, which
| turns those 19 "development" commits into a single
| "permanent" commit.
|
| Using PRs as the unit of development, with all intra-PR
| work squashed into a single atomic test-passing commit,
| is a well functioning process that many teams use.
| jen20 wrote:
| This would be true if and only if GitHub allowed you to
| collaboratively review and modify the squashed commit
| message _as part of the approval_ process, a feature
| which I have been requesting from them ever since "squash
| and merge" became an option.
| jefftk wrote:
| The teams I've worked on generally use a "copy the PR
| description into the commit message", which works well.
| And if there are oversights, the PR number is in the
| commit ID which is a link to the larger context.
| Volundr wrote:
| > EDIT: and just to point out. If you have 1 PR with 19
| commits that break the test suite. The last commit fixing
| it doesn't matter as you will be hitting one of those 19
| commits at some point during a bisect.
|
| Then I'll `git bisect --first-parent`, and either isolate
| it to your merge, or mark to merge OK. `git bisect`
| doesn't have to walk your branch.
| Foxboron wrote:
| --first-parent is a nice option I wasn't aware of. But it
| would still depend on upstream not merging PRs failing
| the test suite.
| starttoaster wrote:
| The other 19 commits are also not the current state of
| the code, and if the test suite is all currently passing,
| and nobody is using a version of the code in production
| from the other 19 commits, then none of that matters
| anyway. So I'm still confused why anyone should care.
|
| The test suite did its job by alerting you to make
| changes before merging your work to the trunk branch, I
| don't see this as anything anybody could possibly pick a
| fight over.
|
| And to be clear, I still use mainline terraform because I
| never really wanted a wrapper around terraform. It's just
| silly to me to take issue with the terraform wrappers for
| this non-issue.
| Foxboron wrote:
| Right.
|
| Imagine you are a terraform provider developer that is
| working on making sure their code is working with
| `opentf`.
|
| Lets imagine opentf does an initial `v1.0.0` release of
| their code and your provider doesn't work. But you _know_
| it worked with the last FOSS release of `terraform`.
|
| What do you do?
|
| You find the common ancestor between these two projects,
| lets say 8a085b427b74ce3829500a59508b77465f1bbef0 (as
| that is the last commit `opentf` has from `terraform`).
|
| You will now run `git bisect` on the history between
| `8a085b427b74ce3829500a59508b77465f1bbef0` and `v1.0.0`.
|
| You will do a binary search on the 100-200 commits here,
| and everytime the source fails to build, or the test
| suite doesn't pass for whatever reason, you are making it
| _much_ harder for the downstream provider to figure out
| why their code doesn 't work.
|
| You can easily just try do this today and see what
| happens. Does the current untidy git history cause you
| any problems?
| starttoaster wrote:
| My bias here is that I don't tend to use commits the same
| way you do. I would look through each PR that had been
| merged between now and then. Specifically looking for PRs
| that look like they might change the thing that I'm
| having issues with. Untidy git histories are so common
| that it's not really worth counting on, to me. A PR is a
| body of work that I find actually seems to matter. I
| wouldn't reach the same hangup you had. On the flipside,
| when people overload their PRs with 3-4+ deliverable
| items, that tends to irk me.
| Foxboron wrote:
| Bisecting to find the root cause is always going to be a
| better strategy if you _know_ there is a good version.
|
| I really recommend adopting this strategy.
| starttoaster wrote:
| Bisecting can be a good strategy. But you need to look
| through 100 commits. I need to look through 5-8 PR diffs.
| Everyone thinks they have the best strategy because they
| get results with it. Anyway, I'll try your strategy if
| mine is failing.
| lijok wrote:
| You should play around with git bisect - seems like
| you've not used it much. It's a life changer when it
| comes to finding what broke.
|
| Don't forget, a project like Terraform is too big. No one
| person can know how the whole system works. Trying to
| look through PRs as a means of debugging is a fools
| errand. You have to take on a different mindset when
| working on these large codebases.
| Foxboron wrote:
| No, it does a binary search over the 100 commits. You
| would probably hit the issue before you hit 7 or 10
| commits depending on how lucky you are.
| bradleybuda wrote:
| Should have factored out the project name into a build step
| to make things easier for the next fork
| gray_-_wolf wrote:
| They should have go with "terrafork"...
| stephenr wrote:
| Lunarspoon.
| olalonde wrote:
| Moonform has a nice ring to it.
| Pet_Ant wrote:
| Moonspoon
| lawik wrote:
| Airshape
| swyx wrote:
| perhaps opencorp, because terraform is only product 1...
| https://news.ycombinator.com/item?id=37393844
___________________________________________________________________
(page generated 2023-09-05 23:01 UTC)