Hi Ashley,

Thanks for the response!

The things needed for rouge right now are:

* Working through the backlog of issues: https://github.com/jneen/rouge/issues
* Releasing rouge 2.0 with the formatter refactor to reduce the amount of duplicated code every user of rouge is currently writing
* Cutting regular releases with contributed lexers and other features that GitLab requires

Right now I'm not able to get to any of this because I'm working a full-time job to do things like pay my mortgage and eat, which doesn't leave nearly enough time for this amount of maintenance. If you all have the budget for it, a full-time sponsorship would be the simplest for me - even for a fixed amount of time.  Otherwise, there could be a number of other viable solutions:

* GitLab sponsors me in conjunction with other organizations, for a total I can live from
* GitLab hires me full-time and splits my time between rouge and GitLab or Tulip work
* GitLab hires me as a part-time contractor and I supplement with other work

Of these, either a set full-time sponsorship period or a full-time hire would be preferable to me, since I wouldn't have to split my attention as much between other projects.

===

As for Tulip, it's a new open-source functional programming language that I'll be introducing at StrangeLoop this year.  It has a semantic similar to Erlang, but with a syntax heavily optimized for repl usage, and with well-designed tooling.  Importantly, its user base is intended to center women users through both branding (which we're still working on) and actual policy and community-building.  The project's community is hosted by snek, a slack network of mostly women to grow emerging languages.

Language projects tend to have a few common needs: the ability to bootstrap with developer time, and package hosting.  I believe there is a way for GitLab to contribute to both of these, while creating a network effect to pull users - particularly women and minorites who are already frustrated with spaces like GitHub - to GitLab.

The architecture I'm planning for package hosting is similar to the Rust language's Cargo index (https://github.com/rust-lang/crates.io-index), where packages are registered in a central repository.  They would be able to point to arbitrary git endpoints, however the default username/project-name could be made to default to GitLab, meaning that the most convenient way to develop Tulip packages ("bulbs") would be on GitLab.

As for me, I have a good deal of experience in web development, but mainly I am a language developer and designer - I have already successfully deployed an internal language at GoodGuide, and I recently gave a well-received talk on language design at Clojure/West.  I have been working on Tulip in my spare time for upwards of 3 years, and I believe a little push of full- or part-time work is all that's needed to get this off the ground.

Anyways, thanks for reading, and I hope to hear back from you soon!
Cheers,
--Jeanine