Well, that's certainly a feature that serves to expand the usage of the Go language, but I'm not so certain I like the spirit of it. Until now, sharing Go functionality meant sharing the source. And I like the idea that you pretty much have to open up your full source if you want people to use your work.
Maybe it's just fanciful and impractical, but I'd sort of hoped this would be the kind of decision that Go could take a stand against, in favor of incentivizing openness.
Of course they're not. I just had hoped that this would be something that the Go team/community would purposefully decide not to support, as they've tended to lean toward open solutions and processes like most modern projects.
The whole rationale given in the proposal [1] is that some users have worked with vendors who do not want to share their source code, since they've purchased some sort of library product. In my opinion, that's likely more harmful than beneficial for software as a whole.
That's true. In my company we are basically living from licensing libraries and frameworks to commercial customers. Complete applications often make no sense in our domain (and SAAS even less). It's good to see that we could now also offer Go libraries to our customers (which means they could build Go applications) instead of being limited to the old C/C++ choices.
> The whole rationale given in the proposal [1] is that some users have worked with vendors who do not want to share their source code, since they've purchased some sort of library product. In my opinion, that's likely more harmful than beneficial for software as a whole.
I'm not sure why that's "likely more harmful". If you're purchasing enterprise software or specialized hardware that comes with libraries that interact with them I can understand companies not wanting to simply hand over the source code to such things (this is how it's done with many existing products outside of the GO ecosystem).
There is nothing wrong with giving people the option to deploy either way and it will help the GO ecosystem gain more enterprise like users.
Alternatively, if companies know they can't use Go for libraries unless they're willing to make their source readable, and there's customer demand for Go, maybe they'll give in.
A decade or three ago, it was common for all software not to come with source code. If you bought some server software, the client library was closed-source as a rule, if it even existed, regardless of how enterprise or non-enterprise it was. Now it's not uncommon to see even closed-source services have client libraries on GitHub because that's where they're expected and that's how people expect to publish client libraries. That change seems to have been good for the industry and good for the world.
The enterprise users will come along eventually. They always have; you can find articles as recently as a decade ago debating whether your company should allow the use of open source software internally, or have a blanket rule against it. The second option is now inconceivable for almost all companies, because you put yourself at such a competitive disadvantage. All Go needs to do is deliver a technically attractive product, and people will figure out how to be comfortable using it.
Strings attached is fine. This PR is about making it technically possible to not ship source with a library. If the policy is "Here's the source, but you can't do anything with it," you don't need this PR; you only need it for "You can't see the source at all."
This PR is also not required for executables without source, which Go has supported forever, just for libraries without source.
I'm talking about things like client libraries for closed-source servers, since that's the context where you're most likely to have a library and care about what language it's implemented in. I'm not talking about the core product itself having source available.
A number of software-as-a-service companies are making extremely successful businesses with completely proprietary servers and open libraries. Amazon AWS and Slack both come to mind without thinking very hard, but there are a lot of others.
If you want to reject software-as-a-service, there are a good number of companies selling proprietary (or at most "open core") desktop/server applications with open-source client libraries. VMware, a bunch of NoSQL companies, a couple of network monitoring tools, etc. also come to mind. Those sorts of companies would have given you a closed-source C library 10-30 years ago.
And, of course, there are people who sell hardware (graphics cards, network cards, RAIDs, etc.) who would have released proprietary tools and drivers in the past and are now releasing both as open-source because that's a competitive advantage because their stuff works better.
Would it do what you are saying or would it hinder growth? I mean would a company say well we don't want to ship source code with it so let's choose another language that doesn't force us to do that. I am not saying either way is correct, but I can see a company that was thinking about going with Go use another language because they have to ship source with their binary in Go. Which would actually hinder the growth of the language.
For the Go team it is beneficial if more people/companies are using Go and possibly contributing back. Trying to force someone into a specific usage pattern (here, open sourcing of all components) can be detrimental to it. Even if parts of your product might be open sourced, there often are good reasons for commercial software providers (either by selling software or the software being part of a sold product) not to open source their whole stack. Even GCC clearly states that programs compiled with it are not covered automatically by the GPL.
"Various users have reported working with companies that want to provide them with binary but not source forms of purchased packages. We want to define an explicit way to do that instead of fielding bug reports each time the go command gets smarter about detecting source-vs-binary mismatches."
That has completely different performance characteristics. And for sane usage you need then some code again in the main program that encapsulates away the IPC basics. And it won't work for all use cases, e.g. moving parts of the GUI into a different process will most likely not work.
> It is common in C for a code author to provide a C header file and the compiled form of a library but not the complete source code. The go command has never supported this officially.
Practically, I like source libraries, because It was so easy find if there were any bugs in the libraries and fix them. I found it refreshing from other eco-systems and saved myself a lot of time. May be when eco-system matures more it wouldn't be such a problem.
I have found bugs in almost every major library I have worked with in my professional career. Being able to fix an issue myself and submit a PR is invaluable and honestly often the difference between shipping on time vs the library authors time. The industry as a whole should demand source even if it has to come with an NDA.
It's not compiler's job to shape community or enforce ethical values (unless it's GCC, haha). If people don't want to share binaries, they are free to share sources.
From a utilitarian perspective this will cause more harm than good to golang. Enabling users to ship binary blobs instead of open source openly audible code will decrease the over all quality of golang libs. Its the job of those who write the compiler to move the project in a direction which is best for golang, and this direction arguably is not good for golang.
I think OPs point is that commercial vendors will now stop providing the source code, which deprecates the overall quality (I don't like working with code I don't have the source code to. Once you find a bug, this all blows up on you).
It think it is a big win that proprietary software needs to ship source code with them in order to sell the library. Just because there is source code doesn't mean, it is open source or free software. It can still have the same licenses (not share the source/bin, etc) but source code that is visible (even proprietary) is better then a binary.
After all, not all libraries are OS and those that aren't would suffer from that change (although marketing guys would probably argue differently).
Exactly, which is why it's great for community! This means that open source packages will be more valuable than commercial binary blobs due to the ability to audit source code.
Theoretically, yes, but commercial libraries will always be there – no matter what language they're written in. So we can either make the best out of our situation and have commercial libraries with source code access or have it like every other language out there.
It is fanciful. The feature is a pragmatic one, and what's more I don't think it will have the negative impact you imagine.
Look at the C/C++ ecosystem which has many commercial libraries, as well as open source ones. Boost is an excellent, source-code included library. No harm is helping commercial vendors of libraries making their, say, C++ quantitive finance library available to Go devs too.
> Maybe it's just fanciful and impractical, but I'd sort of hoped this would be the kind of decision that Go could take a stand against, in favor of incentivizing openness.
FWIW: This doesn't enable you to do anything you couldn't do before; it just makes it less annoying.
Yet you still have to statically link all your Go code in one single big binary... the Go team doesn't have their priority straight. People who want to sell closed source, commercial software in Go can already do that by selling exécutables.
What, the advantage that Go doesn't give the choice to compile and link dynamically? Oh yeah, the advantage to treat the developer like an idiot who doesn't know what he is doing.
This is odd. Mind you, lots of things about Go made me think "this is odd" the first time I saw it.
I like the fact that we can now sell libraries more easily if we want to. There was a reasonable indie industry for years selling stuff out of the back of Dr Dobbs back in the 1990s, and being able to support that community is good. If you don't want that community to exist, fine, write better code and release it open-source and kill the market. I would be happy to try and sell a library and see sales dry up because I was unable to out-compete the wider market.
I suspect there might be the rise of people selling packages that are in essence tweaks of open source packages, but that's a problem the industry has irrespective of language. It is after all the business model of several firms.
I also think this might help with the quest on compile times. We're really keen on getting compile times down, and being able to build a package over there and as I'm working over here, it can pull in the binary is actually really quite nice. I think it'll be a while before that becomes a default thing for Go to do, but you can now see it as a possibility.
The package source code itself must be present in some form,
or else we can't tell if the package was deleted entirely
(see background above). The implication is that it will
simply not be the actual source code for the package. A
special comment is a natural way to signal this situation,
especially since the go command is already reading the source
code for package name, import information, and build tag
comments. Having a “fake” version of the source code also
provides a way to supply documentation compatible with “go
doc” and “godoc” even though the complete source code is
missing.
That, you have to admit, is different.
Also, perhaps making it less useful for commercial purposes was the last paragraph:
The compiled form of the package does contain information
about the source code, for example source file names, type
definitions for data structures used in the public API, and
inlined function bodies. It is assumed that the distributors
of binary-only packages understand that they include this
information.
"I also think this might help with the quest on compile times."
It should have next to no effect. Opening source files for hashing them is still dirt cheap even compared to go compilation, since you are almost certainly pulling them out of OS cache in a pure-memory operation. Make sure you're using either "go install" or "go build -i" if you aren't already, and you'll get the benefit of precompiled binaries where possible. The result should be that on average, most of the time is spent linking.
"Also, perhaps making it less useful for commercial purposes was the last paragraph:"
No, that's normal. You always have to expose the public API, because otherwise you can't use it. This has nothing to do with Go, this is a general rule. There's no (useful) such thing as a library with a hidden public interface. (I suppose in some languages you could provide one and require users to reflect their way in, but this would be a coding challenge sort of thing, not something you'd buy.)
42 comments
[ 5.0 ms ] story [ 94.5 ms ] threadMaybe it's just fanciful and impractical, but I'd sort of hoped this would be the kind of decision that Go could take a stand against, in favor of incentivizing openness.
The whole rationale given in the proposal [1] is that some users have worked with vendors who do not want to share their source code, since they've purchased some sort of library product. In my opinion, that's likely more harmful than beneficial for software as a whole.
[1] https://github.com/golang/proposal/blob/master/design/2775-b...
Those vendors will just keep using tools whose vendors are more understanding of businesses needs, like C and C++.
I'm not sure why that's "likely more harmful". If you're purchasing enterprise software or specialized hardware that comes with libraries that interact with them I can understand companies not wanting to simply hand over the source code to such things (this is how it's done with many existing products outside of the GO ecosystem).
There is nothing wrong with giving people the option to deploy either way and it will help the GO ecosystem gain more enterprise like users.
A decade or three ago, it was common for all software not to come with source code. If you bought some server software, the client library was closed-source as a rule, if it even existed, regardless of how enterprise or non-enterprise it was. Now it's not uncommon to see even closed-source services have client libraries on GitHub because that's where they're expected and that's how people expect to publish client libraries. That change seems to have been good for the industry and good for the world.
The enterprise users will come along eventually. They always have; you can find articles as recently as a decade ago debating whether your company should allow the use of open source software internally, or have a blanket rule against it. The second option is now inconceivable for almost all companies, because you put yourself at such a competitive disadvantage. All Go needs to do is deliver a technically attractive product, and people will figure out how to be comfortable using it.
But they do so, by delivering it encrypted and decrypting it on the fly when it gets used.
Or they hide it on a server that their customers never get to see, besides an incomprehensible junk of minified and encrypted JavaScript.
Which companies are doing successful business selling software for embedded, desktop and mobile platforms with source code available?
https://en.wikipedia.org/wiki/Unreal_Engine#Unreal_Engine_4
Also the commercial games that are sold with it surely don't come with source code.
This PR is also not required for executables without source, which Go has supported forever, just for libraries without source.
A number of software-as-a-service companies are making extremely successful businesses with completely proprietary servers and open libraries. Amazon AWS and Slack both come to mind without thinking very hard, but there are a lot of others.
If you want to reject software-as-a-service, there are a good number of companies selling proprietary (or at most "open core") desktop/server applications with open-source client libraries. VMware, a bunch of NoSQL companies, a couple of network monitoring tools, etc. also come to mind. Those sorts of companies would have given you a closed-source C library 10-30 years ago.
And, of course, there are people who sell hardware (graphics cards, network cards, RAIDs, etc.) who would have released proprietary tools and drivers in the past and are now releasing both as open-source because that's a competitive advantage because their stuff works better.
https://github.com/golang/proposal/blob/master/design/2775-b...
Is it? I've never heard of this or seen this.
Really? How exactly this will decrease the quality of open source libraries?
It think it is a big win that proprietary software needs to ship source code with them in order to sell the library. Just because there is source code doesn't mean, it is open source or free software. It can still have the same licenses (not share the source/bin, etc) but source code that is visible (even proprietary) is better then a binary.
After all, not all libraries are OS and those that aren't would suffer from that change (although marketing guys would probably argue differently).
Look at the C/C++ ecosystem which has many commercial libraries, as well as open source ones. Boost is an excellent, source-code included library. No harm is helping commercial vendors of libraries making their, say, C++ quantitive finance library available to Go devs too.
FWIW: This doesn't enable you to do anything you couldn't do before; it just makes it less annoying.
This isn't inherent. Dynamic linking works today on linux amd64.
What, the advantage that Go doesn't give the choice to compile and link dynamically? Oh yeah, the advantage to treat the developer like an idiot who doesn't know what he is doing.
I like the fact that we can now sell libraries more easily if we want to. There was a reasonable indie industry for years selling stuff out of the back of Dr Dobbs back in the 1990s, and being able to support that community is good. If you don't want that community to exist, fine, write better code and release it open-source and kill the market. I would be happy to try and sell a library and see sales dry up because I was unable to out-compete the wider market.
I suspect there might be the rise of people selling packages that are in essence tweaks of open source packages, but that's a problem the industry has irrespective of language. It is after all the business model of several firms.
I also think this might help with the quest on compile times. We're really keen on getting compile times down, and being able to build a package over there and as I'm working over here, it can pull in the binary is actually really quite nice. I think it'll be a while before that becomes a default thing for Go to do, but you can now see it as a possibility.
What is a little odd though is to make this work, you still need "a" source file, even if it's not "the" source file. From the bottom of https://github.com/golang/proposal/blob/master/design/2775-b...
That, you have to admit, is different.Also, perhaps making it less useful for commercial purposes was the last paragraph:
It should have next to no effect. Opening source files for hashing them is still dirt cheap even compared to go compilation, since you are almost certainly pulling them out of OS cache in a pure-memory operation. Make sure you're using either "go install" or "go build -i" if you aren't already, and you'll get the benefit of precompiled binaries where possible. The result should be that on average, most of the time is spent linking.
"Also, perhaps making it less useful for commercial purposes was the last paragraph:"
No, that's normal. You always have to expose the public API, because otherwise you can't use it. This has nothing to do with Go, this is a general rule. There's no (useful) such thing as a library with a hidden public interface. (I suppose in some languages you could provide one and require users to reflect their way in, but this would be a coding challenge sort of thing, not something you'd buy.)