Announcing Rome Tools, Inc.
rome.tools
rome.tools
VCs fund startups which has the potential to 100x their returns right? How is that going to work here? How will they monetize a javascript library? Will we have an IPO for a javascript library? Or are they betting on a big tech company to acquire a Javascript library for 100s of millions of dollars? I am confused.
There are hundreds of open source companies - many making gobs of money. Not all - many fail. This team has name recognition and a few successful projects already - Babel and yarn. I can see it working out.
JavaScript is one of the most popular programming languages. Millions of developers. With solid execution, there are monstrous markets here.
> Eric Raymond, the founder of the Open Source Initiative and one of the authors of the standard-bearing Open Source Definition, said Kyle’s decision violated the fifth clause of the definition, which prohibits discrimination against people or groups.
[citation needed]
It seems there may be many open source companies with tons of users, but they seem to struggle with monetization and turning those users into paying users.
Redhat which used to be the epitome of a company making money from open source got acquired by IBM.
A lot of other open source companies are switching to non-open source licenses.
That being said, a compiler toolchain is not so easily monetized as something like Grafana, which has obvious enterprise features that need filling in and which can be hosted as a cloud service, generating revenue that way.
I imagine the team has ideas for monetization, otherwise they would not have raised $4.5M from some top shelf venture capitalists. I would like to know what those ideas are.
That's true. The market is small and price-sensitive.
People used git because it was mandated for linux kernel work.
http://www.rockstarprogrammer.org/post/2008/apr/06/differenc...
Clearly they have a vision that investors thought was compelling enough to buy into.
Perhaps be patient and see what they announce in the future? This is their day one (zero?)..
If there was an easy answer here, someone else would have already done it.
edit: they (sort of) answer in another thread https://news.ycombinator.com/item?id=27039330
I would like to see that measured.
My suspicion is that many developers are already too reliant on tooling and that reliance harms productivity rather than improves it. Bundling those tooling concerns eliminates some operational costs associated with a plurality of tools but increases dependency upon the tool.
This problem is not a technical problem (as in how do I solve a problem), but a cultural problem (as in what is the proper way to solve a problem). It comes down to the difference between a product focus (what do we ship) versus an operational focus (what do we work on).
On the contrary I would also say that I see a lot of developers not being reliant enough on tooling. A simple example is getting very acquainted with the debugger in your language of choice. It's very common to sprinkle logs everywhere instead of properly learning how to step through code.
GitHub, yeah absolutely, but git makes no money because noone pays for git.
Likewise, noone pays for command line package managers (in fact I doubt anyone pays for a command-line tool at all). So its ok to say it generates value, but if you can't caputre that value its not a sound business model.
like every open source company, they will sell additional services to companies. When you have millions of users you always find a way to monetize it, even if you think you are just a "javascript library". Redis is just a database, Word is just a text processor, ...
Does seem like quite a departure from the original premise of Rome, but it seems like a sensible strategy. FWIW many companies easily spend 6-7 figures on CI/CD per year, so there's definitely room to carve out a niche there.
> Sucrase bypasses most of these steps, and works like this: Tokenize the input source code into a token stream using a trimmed-down fork of the Babel parser. This fork does not produce a full AST, but still produces meaningful token metadata specifically designed for the later transforms.
While this is fine for simple transformations like transpiling JSX, it's not very suitable for full-on AST analysis like some eslint plugins do. Most notoriously, Sucrase is specifically designed to be garbage-in-garbage-out, whereas Babel will throw proper errors on things like early errors.
Tools written in lower level languages like esbuild can take advantage of facilities that aren't well supported in Node, such as cheap concurrent coroutines and greater control over memory layout (Babel ASTs are notoriously megamorphic and can silently fall off perf cliffs depending on how you manipulate them). These caveats are not reflected in Sucrase's benchmark.
Did anyone use Brunch to build and bundle JS projects and manage dependencies? It seemed like the best thing since slice-bread at the time.
I recently had to go back and update a 6-year-old project that had been written using Brunch. It took several days of painful work to extract it all out of the framework and built it using Babel.
All I'd want to know with Rome is, if and when I abandon it or it gets abandoned (whichever happens first), how annoyed am I going to be that I had chosen this framework? How seamless will it be to extract my project?
There is already RSLint and SWC as JavaScript tools written in Rust and I would expect such tools to take over, with a good choice of it happening before Rome is ready.
Of course, perf is only one reason to use a tool, I expect javascript based tooling to stick around for much longer because developers are used to them now. And, of course, if all you know is frontend, everything starts to look like a javascript job.
But rust also has other features that can help prevent bugs regarding concurrency and more. So rust is a feature in my book and not just an implementation detail.
At this point in time, improvement comes from "anything faster than node". Hell, you might even manage to get a performance benefit out of PHP with the way things are right now.
The positives I see are: - No fighting with different versions of different tools when upgrading - Simpler configurations
But I dont see any other reasons to convince people to use Rome.
How many of these people are going to receive an employment opportunity from this company? How many will receive equity?
I suppose the same questions can be asked if any big project, like React, though that had FB’s backing from the get-go.
I understand that OSS needs funding from somewhere, and I am incredibly optimistic about Rome, but I’d think it a bit disheartening to be surprised by this announcement as a contributor.
They certainly deserve any and all success, I just wonder how those decisions will be made.
Emanuele and Yasser both approached us during this period to offer their interest in joining and have stayed actively involved in development.
It's a good question around how to compensate the shoulders of the giants you're standing on, and I don't think anyone has a good answer for that. I think it's important to note that the credits page is meant to be as exhaustive as possible. I am not aware of many other projects that have something similar, and theirs are likely to be even longer.
In the end the community is getting value because we'll now be able to do more to improve the project than we otherwise would have. Babel most notably has struggled for funding and is even currently undergoing a serious funding shortage. It has been used as one of the poster children for the JS community and it's clear that donation-based funding isn't effective, at least on the order of magnitude required to support a team.
This statement reads weird too
> We don’t believe in placing artificial constraints on the tool or having functionality behind a paywall. In order to support the open source project, we’ll be building supplemental products and services. This aligns our incentives with the community and our open source users, with a focus on interoperability, performance, and usability.
Supplemental products and services on top of open source projects often require (down the line) the open source project to adapt because it might hurt the bottom line of these supplemental products and services. Since there is no guarantee this won't happen, if the stake is between the company surviving or a feature being open-source vs "supplemental", the people working at the company might have to chose the option against the wishes of their open source users. I don't see how creating a for-profit company is at all in alignment with open source users. Better would have been a Co-op, a non-profit, OpenCollective, or leverage an existing entity like the Linux foundation, that can actually guarantee it for you in contracts and laws.
VC money is just on another level, although as you said it comes with its own difficulties.
Some of the open source companies have had an easier time monetizing than others. Databases, for example, have a somewhat obvious path nowadays of offering a hosted version. NPM and Docker, on the other hand, developed incredibly popular tools but struggled to monetize. So I'm curious to see what Rome will do.
The other interesting question to me is what Rome will focus on. There's a really wide array of things in the JS toolchain and it's tempting to boil the ocean. How much of it can you really boil? Running a nice JS browser stack of course. Supporting TypeScript I presume. How about Node on the backend? An Electron app? All of those in the same codebase?
Some tough decisions here but I'm glad the team working on them is set to grow and attack this problem. Good luck Romans ;-)
Seems like the author could take it with him when leaving facebook, which is nice.
- License: MIT. Great pragmatic choice. Generally a good fit for not obstructing your users to actually use, copying, modifying, etc. your code. Too many OSS startups play games with this and end up going for something too restrictive. IMHO not having copyright transfers is the key to longevity for any OSS community. It basically progressively removes re-licensing as an option as more contributors would have to agree to such a thing. Most long lived oss projects have long lists of contributors and no history of license changes past an early stage of their development. Also, MIT is very compatible with just about anything in the ecosystem. Given their stated goal of being good OSS citizens, that's a hard requirement.
- Contributing.md: no mention of copyright transfers. Also they have close to twenty contributors. I assume this means the license will stay as it is and there are no plans to change that. Great! This is key to building a successful open source community with people actually contributing as well as using the code. It also ensures the code can survive acquisitions, bankruptcies, mismanagement of the company, etc. Committing to this upfront is important and a big step.
- Community: There are seventeen contributors, most of which are not employees (I assume). And they probably integrate a lot of other libraries/tools.
- Explicit stated goal that affirms the above: "The company exists to support the open source project, not the other way around.".
That does raise a few question marks around valuation and ways to profit from this. I'm curious about their plans for adding value in the form of services on top of this. I assume this means some cloud based services and/or support contracts with consultancy. But then, it's good to remove the nuclear option (relicensing) from the table early on to create clarity for developers and investors that this is just not that sort of company.
It's smart from a business point of view as well because most of what they do will come from outside the company anyway. The nature of the javascript community is people rapidly iterating on tools, libraries, etc. and forking left right and center as needed. So, a lot of value is going to be added through people doing exactly that. You can work with them or against them. With them is the smarter option.
Virtually all open source projects in the web dev community are MIT licensed, especially when it comes tooling. Choosing any other license would cause a lot of friction and prevent adoption.
I was trying to find out how this relates to https://roamresearch.com/
I guess phonetically my mind was flipping things around.
what are Rome's intended policies on OSS licensing and usage by ICE?