and in a single moment, the value of software patents to companies is fully restored... the software license by itself is not enough to protect software innovation, a non-trivial implementation can now be (reasonably) trivially re-implemented.
I'm sure most people here would agree patents stifle innovation, but if copyright doesn't work for companies then they will turn to a different tool.
A reply of sorts, and a standard disclaimer that I work at Grafana Labs.
> career-driven development
we don't have this and promote and reward as frequently for "I've done solid operations" as we do for "I've added this feature" (I'm on promotion committees and can state this confidently).
what we do have is high autonomy for engineers. This autonomy means it's a freedom that engineers have to identify problems they feel are important and to work on them, they do not need permission and leadership do not veto this. Some of the best features in the last few years have been a direct result of this autonomy, it's one of the things that makes working here so attractive to many of the engineers. But, with autonomy comes a little chaos, and not everything that is done is going to satisfy every end user of OSS or paid customer (of which these are a small percent of the whole).
a lot of the innovation speed is just in the DNA of the company, even the creation of Grafana can be traced to a desire to get things done; Torkel wanted Kibana to also work for Prometheus, Kibana declined to add this, Torkel didn't stand still and added things to a fork of Kibana now called Grafana and hasn't stopped adding things since.
> They also deprecated Angular within Grafana and switched to React for dashboards. This broke most existing dashboards.
we did, I think the entire journey was 7 years long, communicated many times, over at least 6 major releases. maintaining dashboards in two languages increased complexity, whilst reducing compatibility, and gave a very large security surface to be worried about. we communicated clearly, provided migration tools, put it in release notes, updated docs, repeated it at conferences and on community calls.
arguably we went too slow, and should've ripped the band-aid off, but we were sensitive to the fact that it was a breaking change and so we proceeded with extreme caution. it's done now, it was finally completed in the last version, only a very small number of users reported impact as a result of the time and care taken on this.
> I just hope OTEL settles, gets stable and boring fast
this is distinct from Grafana, but it's a good point... OTel is the product of virtually every vendor at this point, and a hell of a lot of engineers, it now has a lot of momentum and the pace is unlikely to ease up due to the sheer number of contributions and things that OTel as a community wishes to achieve.
the most likely eventuality is that enough stability emerges to allow vendors (including but not limited to Grafana Labs) to abstract away the pace of innovation occurring underneath, but this is in tension with providing the benefits of the innovation to the people that use it.
what I would say is that for most people the boring and slow path does still exist, and it's still good... just use Prometheus, a logging option of your choice, and simple Grafana dashboards and alerts. that combination hasn't varied in years, and those on it today are still immune from caring about the pace of innovation and change in OTel and across the Observability industry. OTel is being used in production at massive scale by lots of companies, but whether your project or company need move to it now reflects your priorities, many are adopting to gain independence from vendors, or just control over their telemetry, but many customers are also saying they're happy to stay on the slow and boring path and for everything to work predictably with low cost to keep pace... it works too.
Literally everywhere... but we've not had that challenged yet. Perhaps there are some countries where for various reasons we might not hire (i.e. North Korea would likely pose a challenge) but we've so far hired everywhere we've found great people to hire... and have employees in South America, South Africa, Australia, India, throughout Europe (too many countries to list), North America. When hiring we do not check a list of countries but do check that the person we are considering has the right to work where they are and that we have the right to hire them (as a direct contractor if it's a country where we do not have a legal entity).
However things aren't as simple as just saying we hire anywhere as some teams are looking to increase the number of engineers across a set of time zones, i.e. if a team has a lot of people in EMEA and APAC already then hiring in the Americas smoothes the on-call burden. So for some roles in some teams we may prefer people to be aligned to some time zones.
You know us, we make the dashboard you use to observe your systems. We also do Prometheus, Cortex, Loki, Tempo, a SaaS offering, an Enterprise offering. We're well-funded and have a long list of customers whose brands your family recognise. We're OSS, and CNCF.
And we are hiring globally in full-time remote roles. Note: The entire company has been remote first forever and our founders are on multiple continents, this is not something we're learning - this is who we are.
We need engineers at all levels, wherever you are.
1. Herding cats is hard, i.e. how to point them in the same direction (as the company strategy - a.k.a how do you communicate "this is what the company thinks is important")
2. How do you spot bad performers (those who are busy but never seem to ship / deliver)
3. How do you provide timely opportunities to learn / grow / improve
Is it the best system? Not by a significant margin, but all better systems have trade-offs or work great in theory but not in practise.
Is it misused / abused by some companies? Absolutely, this is true of all such systems and it's up to each company to seriously ask itself why it wants to do this and whether it does apply to everyone they want to apply it to.
In many ways it is a "least worst" option, whereby you have a degree of alignment around contributing towards the company strategy, are able to have a regular cadence to ask "did you complete that work when you said?", and a regular cadence for "how can the company help you?" (by lining up work that helps with growth, etc).
Is it scientific? Not really... there would have to be a universal scientific application of such processes for them to be comparable and companies will always apply things in a way that fits them.
Edit: I've seen this at my last few employers and I believe it is valuable, but really you get out what you put in. For those looking to advance their position, compensation, etc... this is a great opportunity (4 times per year!) to identify what the company thinks is important and to contribute to that work, and fit the narrative of your progression into the company one. No-one forces you to do this work, you can treat it as a paper-pushing exercise if you want but then it's a wasted opportunity for you to use it for your benefit (profit! including work/life balance, etc)
Well what I'd like to do is establish a stack of budgets against a project, e.g. Kickstarter Goals.
$500 p/m = all hosting and domain costs paid for
$750 p/m = we'll use some paid service that makes the service better in some way
$1k p/m = we'll reward contributors $250 p/m distributed across those who contributed to PRs but exact distribution determined by repo admins
And then to have a budget associated to the lowest one being the means for the project to survive... with a running total on that one, showing deficits (because I do have to still cover raw costs and those end up on my credit card the months I fall short, so future months should help recoup that).
In this way, it would be extremely clear what funds a project needs to survive and how donations and support makes a difference.
NB: My projects do fine... we get enough support to be viable. But damn it would be great to not manage it all manually, it's a chore I'd like to give up so I can code more.
I run community sites for which I am paid donations to cover running costs including writing code, bug fixes, servers, etc.
Today I take donations via PayPal, but the catch with this is that it's hard to provide visibility to donors of how healthy this is (WRT to costs), and whilst I considered Patreon that seemed to be very focused on creative deliverables to donors of a non-code/service nature.
I am trying Browser Attention Tokens, but these feel to be detached from the delivery of code, and still don't provide enough visibility to the donors of the overall health of the projects.
This though... this could be good. If Github sponsorship were attached to projects and people donated to a given org or repo, and then that were visible "this repo receives $500 per month" it would encourage code contribution whilst providing visibility over the health of a project.
I know my donors would appreciate the visibility (as would I, I manually create periodic reports on income and costs - at least this solves the income side).
The only question I have is how easy it would be for those who don't use Github to subscribe to a recurring donation?
Edit: Signed up for the waitlist, received a link to https://help.github.com/en/articles/about-github-sponsors which appears to clarify that you'd be sponsoring a developer not a repo/org... which means popularity/celebrity is everything. Oh well.
The fact that Meteor wish to call this Rockdown suggests to me it is to change it.
By creating a specification and tests, they will be modifying Markdown even if just subtly enough to remove bugs and ambiguity. Doing even that is to create something that isn't Markdown, existing Markdown parsers may do something different with the same text... so clearly this isn't Markdown.
It may share 90% (or more, or less) similarity with Markdown, but some areas would certainly need tweaking and changing to make the goal (specification, testability, consistent implementations) possible.
To my understanding this means that Rockdown is Markdown inspired/derived.
And as such, that there is a hope that a good specification and the ability to be implemented in a testable and consistent way... will, by mass use (on the sites mentioned), eventually result in Rockdown superseding Markdown.
In my universe, I'm simply looking to get rid of bbcode as the markup syntax of choice. And if you were at the support end of trying to tell people how to insert images on forums then you'd understand that the Markdown syntax is a real difficulty for a lot of people.
The path that I prefer is to use Markdown, but the areas that cause the greatest difficulty in usability testing, to modify those to make things more implicit and frictionless. Worrying about []() (or vice versa) is an obstacle to the user that shouldn't exist. But if everything else is good from a user perspective then I definitely want to keep that stuff.
I'd also like to note that some parts of Markdown from the user perspective are non-intuitive and clumsy.
Such as links and images (inline).
Markdown works so well because it is intuitive and appeals to those who once saw old word processors. They don't have to worry about syntax, and can just enter their text into a textarea (free from JavaScript WYSIWYG interference and the inherent troubles of running that on old and new mobile phones, their playstation, web browsers, etc)... and it just works.
Yet some parts of markdown are simply not intuitive. Links and images are two places where I see in usability testing that the end user will constantly refer to help documentation to figure out how to do it.
Beyond getting the code consistent, maintainable, and testable I'd love to see the language itself solve some of the papercuts that trouble the lay end user.
Realising that what I was planning to do for my project (discussion forums, tumblr for forums) was to create an alternative to markdown that would resolve some of these user issues as well as parser issues, I had already decided that I would not call it markdown and that I would educate my users in something new that hopefully solves their and my needs and would remain very stable due to a well-thought out and documented design in the first place. If what you're proposing is in this vein then consider my hat thrown in, what help I can give I will... take me to your git repository.
I'm sure most people here would agree patents stifle innovation, but if copyright doesn't work for companies then they will turn to a different tool.