I have three main concerns - one is that the original package authors get credit... Right now it looks like you're obscuring that by totally replacing the original import path with your own (leaving out the github username).
Second is that I worry that bugs won't get filled against the original repos for people using your version.
Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with. And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault.
Your concerns apply equally to software aggregations generally -- e.g. every Linux distribution.
Import paths are not the appropriate method of providing "credit". That's the sort of thing that is handled by copyright notices, documentation, and metadata.
It's generally preferred that if you're using a software distribution, you either test bugs against a "pure" upstream version before reporting them, or report them to the maintainers of the distribution, who can triage and, when appropriate, forward bug reports upstream (possibly with patches).
I have three main concerns - one is that the original package authors get credit... Right now it looks like you're obscuring that by totally replacing the original import path with your own (leaving out the github username).
They get credit in README (the upstream path is there), on the website description of package, and, of course, their LICENSE, AUTHORS, CONTRIBUTORS files are all there. We do not want to take any credit from them.
Second is that I worry that bugs won't get filled against the original repos for people using your version.
We'll do it for them! When a StableLib subscriber reports a bug to us, after confirming it, we will file the bug upstream (possibly even a pull request fixing it), and: a) if the bug is critical or security related, and the patch is available — it gets applied to StableLib immediately, b) if the bug is minor or we couldn't figure out how to fix it ourselves, we wait until the upstream fixes it, and backport the fix to our version.
In fact, we will recommend ourselves as the first point of contact in case of a bug instead of upstream, and do all the upstream bug reporting/relations ourselves. This way upstream package authors won't be bothered if the bug report is invalid, or if the bug doesn't apply to their version.
Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with.
I'd prefer to keep the package as close to the original as possible — it's in our best interest, as merges/backports are easier if it's so. In any debate, the author always wins (if their view won't damage security of package).
And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault.
That's why StableLib subscribers would first report bug to us.
Thank you for your great points! This will help us with creating a FAQ.
Sounds like an interesting project, I can see it being appealing for some companies, here are some thoughts which popped into my head when reading your page:
Do you have a provisional list of packages you're planning to include?
How will you make money, or is this a labour of love?
One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language.
Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it?
Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time? EDIT - oh I see you do suggest you might do this on your page lower down.
Are you planning managing patches/bug fixes yourself for packages which fall into disuse?
Do you have a provisional list of packages you're planning to include?
I do, but it's currently not published yet.
How will you make money, or is this a labour of love?
Red Hat-like subscription model. I will provide support, security advisories, etc.
One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language.
Indeed.
Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it?
I didn't ask for permission, but I agree with you about involvement. The ultimate goal is to hire/sponsor as many package authors as possible :-)
BTW, after doing code reviews of some packages, I already submitted a few pull requests to them, so even thought right now there are no financial contributions to package authors, there are some benefits for being included in StableLib :-)
Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time?
This is a great idea, thank you!
Are you planning managing patches/bug fixes yourself for packages which fall into disuse?
Is the purpose of this project just to guarantee that bug fixes will be supported with projects? For example, I use martini, negroni, gorm and mgo on a daily basis. If I switch to your repos, is it that there are no concerns that the repo will ever disappear, or if there are critical bugs you will help fix them if the project developer disappears?
I think the issue I can't get my head wrapped around is, at what point does your service become relevant? What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you?
> What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you?
Details about versioning are still in development, but here's the rough idea:
If it's a small reviewable feature that can be applied without breaking anything, then yes, it will probably go into a dot release of the package.
For example, you use "github.com/dchest/siphash" package. In StableLib it's version v1.0.0 (vX.Y.Z), available via "stablelib.com/v1/crypto/siphash". Notice v1 in import path — this is the major version of the whole StableLib release (X). All version within v1.Y.Z are guaranteed to have the same API, so you can upgrade v1.0.0 to v1.0.1 or v1.1.0 and your application won't break. Now, if dchest/siphash fixes a bug, it will be releases as v1.0.1 in StableLib. If it introduces a new feature, which doesn't break API, say, additional function to calculate 128-bit hash, it will be v1.1.0 in StableLib. In general, you will be on the latest release within the major StableLib release.
Sometime in the far feature we will release StableLib v2, which will break API, and will be available at stablelib.com/v2/..., so your v1 packages will still work.
Maintaining a stable set of libraries for a complex project is incredibly time consuming. I would imagine many organizations would be interested in this, much like they purchase RHEL.
I still worry that devs who say, "oh crap we can't build because of this library" are doing something wrong. I'm curious why I must depend on complexities like this or godeps to write effective go either by myself or in a team. Can't you just take a snapshot of the source including third party libs and keep it somewhere safe?
Edit: stablelibs is an inviting idea if you believe you must vendor, and plenty of people do believe that.
Can't you just take a snapshot of the source including third party libs and keep it somewhere safe?
That's what vendoring is for — freezing your dependency on some version. What StableLib provides is a guarantee that the API of package remains stable, but also that all the latest major/security bugs are always fixed (by backporting them). Also, that you're always notified about any critical/security fixes. Of course, you can also do vendoring with StableLib-provided packages, and we plan to make it easy via the command-line tool.
The first thing that came to mind was that this is similar to ActiveState's PyPm [0] for Python but it seems this might be offering a bit more by way of bug fixes etc... All in all seems like a great product/idea!
I'm confused, is this a curated set of existing Go libraries, or a brand-new set of libraries? If the former, how are they going to guarantee their "3 years of bug fixes"? If the latter, why should I trust them to produce higher-quality code than the community has already?
> I'm confused, is this a curated set of existing Go libraries, or a brand-new set of libraries?
Toward the bottom of the page they talk about contributing back to open source projects and sponsoring the development of some packages, so it certainly appears to be a curated set of existing Go libraries.
> If the former, how are they going to guarantee their "3 years of bug fixes"?
Red Hat provides 10+ years on the code they ship. What's so shocking about 3?
I've been using Go since its public release (I think I wrote the first public Go project — https://news.ycombinator.com/item?id=938046 :-). I also contributed to Go, mostly /x/crypto stuff such as scrypt and salsa, and wrote lots of open source packages — https://github.com/dchest.
StableLib is an effort to help businesses use third-party Go packages without worry.
The website isn't rendering properly for me .. lettering is borked across all fonts - sort of when a bitmap has been resized without using anti-aliasing. Using Firefox 37.0.1 on Win7.
Readit News
Second is that I worry that bugs won't get filled against the original repos for people using your version.
Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with. And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault.
Import paths are not the appropriate method of providing "credit". That's the sort of thing that is handled by copyright notices, documentation, and metadata.
It's generally preferred that if you're using a software distribution, you either test bugs against a "pure" upstream version before reporting them, or report them to the maintainers of the distribution, who can triage and, when appropriate, forward bug reports upstream (possibly with patches).
They get credit in README (the upstream path is there), on the website description of package, and, of course, their LICENSE, AUTHORS, CONTRIBUTORS files are all there. We do not want to take any credit from them.
Second is that I worry that bugs won't get filled against the original repos for people using your version.
We'll do it for them! When a StableLib subscriber reports a bug to us, after confirming it, we will file the bug upstream (possibly even a pull request fixing it), and: a) if the bug is critical or security related, and the patch is available — it gets applied to StableLib immediately, b) if the bug is minor or we couldn't figure out how to fix it ourselves, we wait until the upstream fixes it, and backport the fix to our version.
In fact, we will recommend ourselves as the first point of contact in case of a bug instead of upstream, and do all the upstream bug reporting/relations ourselves. This way upstream package authors won't be bothered if the bug report is invalid, or if the bug doesn't apply to their version.
Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with.
I'd prefer to keep the package as close to the original as possible — it's in our best interest, as merges/backports are easier if it's so. In any debate, the author always wins (if their view won't damage security of package).
And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault.
That's why StableLib subscribers would first report bug to us.
Thank you for your great points! This will help us with creating a FAQ.
Do you have a provisional list of packages you're planning to include?
How will you make money, or is this a labour of love?
One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language.
Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it?
Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time? EDIT - oh I see you do suggest you might do this on your page lower down.
Are you planning managing patches/bug fixes yourself for packages which fall into disuse?
I do, but it's currently not published yet.
How will you make money, or is this a labour of love?
Red Hat-like subscription model. I will provide support, security advisories, etc.
One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language.
Indeed.
Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it?
I didn't ask for permission, but I agree with you about involvement. The ultimate goal is to hire/sponsor as many package authors as possible :-)
BTW, after doing code reviews of some packages, I already submitted a few pull requests to them, so even thought right now there are no financial contributions to package authors, there are some benefits for being included in StableLib :-)
Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time?
This is a great idea, thank you!
Are you planning managing patches/bug fixes yourself for packages which fall into disuse?
Yes.
I think the issue I can't get my head wrapped around is, at what point does your service become relevant? What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you?
Details about versioning are still in development, but here's the rough idea:
If it's a small reviewable feature that can be applied without breaking anything, then yes, it will probably go into a dot release of the package.
For example, you use "github.com/dchest/siphash" package. In StableLib it's version v1.0.0 (vX.Y.Z), available via "stablelib.com/v1/crypto/siphash". Notice v1 in import path — this is the major version of the whole StableLib release (X). All version within v1.Y.Z are guaranteed to have the same API, so you can upgrade v1.0.0 to v1.0.1 or v1.1.0 and your application won't break. Now, if dchest/siphash fixes a bug, it will be releases as v1.0.1 in StableLib. If it introduces a new feature, which doesn't break API, say, additional function to calculate 128-bit hash, it will be v1.1.0 in StableLib. In general, you will be on the latest release within the major StableLib release.
Sometime in the far feature we will release StableLib v2, which will break API, and will be available at stablelib.com/v2/..., so your v1 packages will still work.
I'm happy to hear any suggestions.
Why say that? Are the bits rotting? Does your build process involve deleting dependencies? Is your disk lossy?
Maintaining a stable set of libraries for a complex project is incredibly time consuming. I would imagine many organizations would be interested in this, much like they purchase RHEL.
Edit: stablelibs is an inviting idea if you believe you must vendor, and plenty of people do believe that.
That's what vendoring is for — freezing your dependency on some version. What StableLib provides is a guarantee that the API of package remains stable, but also that all the latest major/security bugs are always fixed (by backporting them). Also, that you're always notified about any critical/security fixes. Of course, you can also do vendoring with StableLib-provided packages, and we plan to make it easy via the command-line tool.
Toward the bottom of the page they talk about contributing back to open source projects and sponsoring the development of some packages, so it certainly appears to be a curated set of existing Go libraries.
> If the former, how are they going to guarantee their "3 years of bug fixes"?
Red Hat provides 10+ years on the code they ship. What's so shocking about 3?
Does Red Hat ship (and maintain) arbitrary 3rd party code?
I've been using Go since its public release (I think I wrote the first public Go project — https://news.ycombinator.com/item?id=938046 :-). I also contributed to Go, mostly /x/crypto stuff such as scrypt and salsa, and wrote lots of open source packages — https://github.com/dchest.
StableLib is an effort to help businesses use third-party Go packages without worry.
Edit: should be fixed now.